AgDesignSystemTM

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

The Problem

Legacy in Transition - AgriLogic 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.

Miscommunication and Rework - The disparity between requirements, pages, elements and code created an adversarial environment between BAs, Devs and QAs. Requirements referenced everything from legacy elements to new code elements. Devs had a hard time building to the inconsistencies and often went back and forth with BAs for additional clarification. QAs would then kickback ticket items for various inconsistencies and descrepencies, creating a round-robin rework effect.

The Strategy

A Design System - A design system was needed to keep UX, UI, code, components and standards consistent across the application. Likewise, we needed to devise a plan to implement and make the changes without disrupting the current production flow.

Collaboration - 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.

Hypothesis - We felt confident that BAs would be able to build requirements with standards and design patterns easily referenced, thereby improving the clarity of their requirements. Developers could build quicker without having to reinvent the wheel for every project, which would result in increased productivity and sprint velocity. It would also allow QA's to have a referenceable pattern library and component standards with which to aid in testing.

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. We interviewed users from each discipline to get their feedback, discover what they felt was slowing them down and confirm our hypothesis that a design system would solve the majority of their issues.

The Solution

Pattern Library - 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.

Code Repository and Standards - We created the code repository and standards together with clear usage for BAs and QAs and copy to clipboard capabilities for Devs. We used Bootstrap 3 as the base and customized the CSS for the controls.

The Results

ROI Metrics Around 50% - The end results were remarkable. 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.

Challenges - 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