AgDesignSystemTM

Pattern Library, Standards and Code Repository
Role: Product Mgmt, UX/UI Design, Research, User Testing

The Problem

AgriLogic, like many mid to large size corporations, had several large enterprise applications used both internally and externally alike. Each application used different code, standards, UI and generally had no consistency between them or even within their own internal sections/pages. It was clear that the need for standards and a consistent UI were paramount, however, with up to 100 ticket daily average and agile projects running in parallel, it was important to get on top of newly created pages and projects before tackling the old ones. We would have to attack the problem in a phased approach.

The Solution

It was clear we needed a design system to keep UX, UI, code, component and standards consistency across the applications. Likewise, we needed to devise a plan to implement and make the changes without disrupting the current production flow. My team and I worked closely with the senior dev staff to build controls that would follow the UX and UI standards, while also allowing the developers to cut and paste code to quickly ramp up new pages, projects and page updates. This resulted in BA's building requirements with standards and design patterns easily referenced. It also allowed QA's to have a reference-able pattern library and component standards with which to aid in testing. Devs increased productivity, as it took less time to complete sprints with all components already developed with a consistent look, feel and interaction.

The Users

The target users of the design system were easy to identify and I knew them all intimately, so there was really no need to build out personas. However, the end users would be:

  • Business Analysts
  • UI and UX Designers
  • Developers
  • Quality Assurance

Research

Much of the research was done hands on before I came up with the solution of building a design system. I saw first hand how the various teams were not working as a cohesive unit to solve problems. BA's and developers were constantly volleying requirements back in forth and blaming one another in the process. QA was constantly producing kickbacks from inconsistent code, elements, behavior or misunderstood requirements.

I interviewed users from each discipline to get their feedback, discover what they felt was slowing them down and confirm my hypothesis that a design system would solve the majority of their issues.

Process

My team and I agreed to build out the design system using atomic design principles. We would work backwards from templates down to individual elements based on common UI patterns, usage and need. That essentially meant developing a one page pattern library that would be the basis of the rest of the system.

Information Architecture

My team and I agreed to build out the design system using atomic design principles. We would work backwards from templates down to individual elements based on common UI patterns, usage and need. That essentially meant developing a one page pattern library that would be the basis of the rest of the system.

The Results

The end results were profound. Overall, rework and QA kickbacks were cut by more than 50%. Development efficiency and accuracy improved across the board and the time required to ramp up a new project was reduced considerably. Likewise, BA requirements were cleaner and more clear as well. Everyone had a standard to go by, making each of the disciplines more efficient and productive.

I would like to say it was all roses, but it wasn't. There were a few iterations along the way that had to be made, as we ran into issues that we had not accounted for and had to improve various parts of the process. However, because we were able to discover the issues up front confronting the different groups, and because we designed solutions that were tailored to each user type, the overall result was a success. Since it was a living document, it could grow, iterate and morph as required, when required.

Connect With Me