AgriLogic was an agricultural insurance provider (AIP) with two large and complex applications used by internal business users and external partnering agencies for agricultural insurance and reporting — AgAdvantageTM and AgAdvantage MapsTM. Both systems were in the middle of a legacy migration to modern code and architecture.
The development team was struggling between bugs reported by users and modernization efforts. Bug tickets could peak at 100+ per day, and QA regularly kicked back tickets with code, components, and page layout issues. Developers and business analysts were constantly at odds and running in circles trying to communicate clarity in requirements. The process was broken and development costs were high due to unnecessary rework. Likewise, BAs, designers, developers, and QAs were misaligned. More importantly, users were not pleased, their productivity was suffering, and the business stood to lose business over the short-comings of the applications.
How might we streamline design and development processes, align disparate roles, teams, and applications around a single source of truth, and create better outcomes for our users?
After analyzing the implementation process, interviewing developers, BAs, QAs, help desk staff, and product leadership to better understand the issues they were facing, I pitched building a design system as a potential solution to explore. I made a hypothesis regarding the problems it would help to resolve and the residual benefits it would bring to the process. This included:
Design systems as we know them today were still quite new to many in the industry, so there was some hesitation, but the team agreed to test my hypothesis in a phased approach. The processing application was already being migrated to modern code, so we needed to move quickly and work iteratively. This included:
Our "test" of the hypothesis would start by creating controls for primary components and patterns. I worked with the lead architect to design and build the controls. We then tested the controls with a few developers to validate their efficacy, learn, and iterate. Initial tests, though not perfect, had a measurable impact on development speed and efficiency. This was enough validation to gain the support needed to continue the effort.
It took little time to see the benefits from the initial changes. Developers were implementing new features in record time due to the speed and ease of the new components, and this meant fewer kickbacks from QA, as well. It wasn’t all perfect, however. We learned as we progressed, understanding the need for greater flexibility in the patterns to account for variable usage. We also had to deal with some front-end developers displeased with not writing code from scratch. However, these were all issues we could overcome and work through as a team.
In the end, development productivity went up, bugs went down, and releases were more consistent and stable as a result. BAs had a better understanding of the standards and guidelines they needed to incorporate into their requirements, designers could maintain a consistent look and feel which was easily updated across the application, and QAs had a reference from which to test UI and standards consistency. Likewise, the business was pleased with the improved team performance and users started to see real value in the changes we were delivering.