Feature Flagging Addition For A Contract Management Application
Ardent Mills is a leading flour milling company in the US with over 40 mills in operation. Developing features efficiently is crucial to the business. The goal of this project was to improve the development process by allowing key users to enable features in the code for testing purposes.
Client:
Ardent Mills
Timeline:
~1 week for design
The Problem
A flawed development strategy
At Ardent Mills, the existing development process relied on big bang releases, which increased the risk of bugs, challenging troubleshooting, and user disruption. Not to mention it contradicted our commitment to the Agile methodology. Additionally, the development team had to manage user access to features in the backend every time they needed testing.
To address these issues, the solution architects implemented canary releases and feature flagging. This approach separated deployment from code releases, resulting in more frequent releases and more stability. It also empowered key users to manage feature access on their own, removing the burden from the development team.
The Goal
Establish method for controlling features
The solution architects approached the design team with a clear mission: develop a feature flagging solution within our custom contract management application. Users needed the ability to turn features on and off, along with a visual indicator to show how many flags were enabled.
Discovery
Refining the problem & identifying constraints
To gain clarity, I reached out to the solution architects to iron out details that were not specified in the original acceptance criteria. Questions like whether this feature would be available to all users and if would it be accessible in the production environment needed answers. I learned that feature flagging would only be accessible by users with special permissions and would be accessible across all our software environments.
In addition, I identified potential constraints, specifically development resources and time. I kept these in mind as I brainstormed options that were both development-friendly and minimally disruptive.
Solution
Thinking through multiple approaches
This problem had three key components: where to place the new feature within the current architecture, how the user will control the feature, and how the global indicator will function.
I explored various approaches to tackle this problem and came up with two solutions. The first option retained the existing page and component structure. This solution was simple and minimally invasive.
The second solution offered greater precision and potential for growth, albeit with slightly more modification. I introduced a Settings navigation option, creating a home for all current and future special access items. Additionally, a chip component on the top navigation bar provided easy visibility and space to inform the user about the specific features enabled.
Both designs were presented to the solution architects for discussion, allowing them to choose the one that best aligned with their goals.
Final Design
A design that allowed for future growth
The solution architects opted for the design that took a bit more effort but felt it met their needs well. These designs were handed off to the development team, and I am happy to say this solution has been implemented and is in use.
Impact
A more efficient pipeline
Although this was a relatively small change to front-end of the application, the benefits this change held for our software development process was huge. By giving key users control over features that need testing, we streamlined our process of testing and releasing features.
Some other projects
Creating clarity through improved alert messaging.
Enhancing independent language learning through stories.
Creating a seamless appointment booking experience.