Feature Flagging Addition For A Commercial 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
Project:
Professional
Timeline:
~1 week for design
The Problem
A flawed development strategy
The current development process at Ardent Mills required big bang releases which increases risk. The solution architects decided to implement canary releases and feature flagging to separate deployment from code releases. This would allow the team to test code more efficiently and allow for quicker, more frequent releases.
My Role
Establish a method for turning features on/off
The solution architects approached the design team to develop a UI solution for feature flagging within our sales application specifically. Their ask was straightforward: users needed to be able to toggle features on and off, and they needed a visual indicator of how many flags were enabled.
Discovery
Refining the problem & identifying constraints
To better understand the problem, I reached out to the solution architects to refine details that were not spelled out in the original acceptance criteria. This included questions like, would this feature be available to all users, and would it be available in the production environment? I learned that Feature flagging would only be accessible by users with special permissions, and it would be accessible all of our software environments.
In addition, I identified potential challenges, which in this case were development resources and time. This helped me assess how far I could push my design.
Solution
Thinking through multiple approaches
There were three parts to this problem: where to place the new feature, how the user will control the feature, and how the feature will trigger a global indicator.
I brainstormed various ways of approaching this problem. I ended up with two wireframed solutions to present: one that did not change existing page or component structure, and a second that focused on future growth through bigger changes.
Both designs were presented to the solution architects for discussion so they could decide which best meet 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. Through design reviews of the development work, these designs have been implemented and are already in use.
Impact
A more efficient pipeline
Although it was a smaller project, the benefits this change held for our software development process was huge. This included increased productivity, smaller and more frequent releases, and less risk. I could see the direct link these changes would have for the design team as our designs feed directly into the development process.
Also, I was able to make slight tweaks to the information architecture that created a better home for permissions-based pages.
Takeaways
Communicate and refine
An issue may seem straightforward at first, but alignment between team members is almost always necessary. Good communication is crucial to refine the details of an issue and weed out assumptions. This holds true when handing off designs to developers as well. As a designer, establishing clarity in the designs helps communicate to the developer the way we expect elements to behave.
Some other projects
Creating clarity through improved alert messaging.
Enhancing independent language learning through stories.
Creating a seamless appointment booking experience.