Background
Launchdarkly feature workflows
Background
Launchdarkly feature workflows
Feature Workflows
Product
Launchdarkly’s Feature Workflows enable development teams to automate, deliver, and control software with speed, safety, and consistency. Feature Workflows Released (takes you to company site).
Schedule Changes
Schedule the rollout of feature flags based on your criteria or using integrated tools.
Approve Changes
Allow for more control over flag changes, either manually or using our integrated tools.
Metric-triggered Changes
Assign safeguards that can pause feature rollouts when necessary.
Mission
We want to enable automated feature workflows so that our users can easily define custom release strategies and make LaunchDarkly an integral part of their delivery process.
Team and Responsibilities
I acted as a design lead and researcher and partnered with a PM and lead developer to form the team tripod. I worked on the team for 1.5 years.
My Key Responsibilities were to:
Provide designs, strategy, and user research throughout the development process
Partner with product management to organize and prioritize feature work
Facilitate collaborative discussions involving designers, developers, and managers
Communicate design rationale with executive and product teams during demo trusts
Manage design specs and requirements
Conduct discovery research and usability research throughout the project
Challenges
Understanding developers’ workstreams and needs
Setting a clear design vision to work toward
Prioritizing and managing user experience requirements for a large-scale project
Designing for short-term and long-term solutions
Scheduled Changes
Schuduled Changes
Scheduled Changes
Schuduled Changes
Scheduled Changes
The first feature workflow that we worked on was enabling our users to schedule their flag updates. This was the first feature because:
Scheduled changes were the most requested feature from our customers.
We needed to build the ‘simplest’ thing first and scheduled changes could be broken down into simpler iterations.
Scheduled changes would lay the technical foundation for future workflows.
User Persona and goals
Understanding our users’ needs.
One of the biggest unmet needs for our users was the ability to schedule their feature releases. Through user research we found that:
Users would log on to LaunchDarkly outside of work hours to turn a feature on; in some cases, it was in the middle of the night.
Users, specifically product managers, had feature rollout plans that they wished to automate.
Product managers found creative ways to schedule their own changes using hacked together workarounds.
User research and feedback requests were used to uncover user needs and pain.
Our users would set reminders to turn flags on/off. They also found their own hacky workarounds using unintentional features to schedule flag changes.
Design explorations
What do we need to design for?
As I approached the design for this feature I had to keep in mind that scheduled changes was the first of many workflows that could be put together. Initial sketches were explorations of ways to:
Define the change a user wants to make to a flag.
Set a condition for the change (scheduled date, approval, external metric),
Review and build.
See all pending changes.
Designing Iteratively
Starting with an end goal in mind helped us break-down the work to be done across the timeline. As a team we decided that starting with a work-flow builder would be too much to take on at once and the best way to release the new feature was to start smaller.
The next question to solve was what is the smallest step we can take to release scheduled changes?
The process to update a change is go to flag > make changes > save changes. We thought the best way to introduce scheduled changes was to keep this process the same and add ‘schedule changes’ as part of the ‘save changes’ flow.
Review and schedule Changes
After a user selects ‘schedule changes’ they can
Set the desired scheduled date to push the changes.
Review and edit the changes within the modal.
Add comments for audit history.
Describing changes in a new way
As part of the groundwork for feature workflows we needed a way to define flag changes outside of the flag details page. This meant describing each type of change in a modular fashion.
Empty state of the pending change drawer. We wanted to show users how to schedule changes (or build workflows) if they happened to open the pending drawer.
Viewing pending changes from the flag details page. All pending changes would appear here. Each card had the option to edit, remove, or link to the pending change.
Designing for edge cases
One of the complexities I had to design for was the error state of ‘conflicts’. A scheduled change or any pending workflow could fail if a change tried to modify an entity that no longer existed. We had to be aware of all pending changes and warn users if they were introducing a conflict, the resulting impact of the conflict, and a way to remove or acknowledge the conflict.
Releasing Scheduled Changes
Schedule changes was released as the introduction to feature workflows. The response was overwhelmingly positive and we saw rapid adoption of the feature. The best part was that our users no longer had to wake up at 4 am to turn a flag on.
Approval Requests
Approval Workflows
Approval Requests
Approval Workflows
Approval Workflows
The next feature within feature workflows was approval workflows. Approval workflows enabled teams to request a review and explicit approval before changes could be applied.
User needs and research
Approvals and reviews are an important process for customers who rely on change management systems. Some of our users needed an approval process in order to continue using LaunchDarkly. This feature was a must-have to support.
The two main use cases we need support were:
Make approvals required for any changes to flags or settings within Launchdarkly. This supports customers who need an approval mechanism.
Allow approvals to be opt-in for folks who wanted a review process that is similar to a peer-review.
Much of the designs for approvals leveraged what I designed in scheduled changes. The exceptions to that were the needs specific to approvals such as:
Requesting approval and selecting to notify the reviewers, along with the corresponding email.
The review screen and its multiple states.
Designing for multiple phases
The approvals feature was broken down into multiple release phases. The goal was to release the simplest version, test it, and in the meantime iterate on future versions. The simplest version did not allow users to comment on requests, just approve/deny. I worked with the product manager to set requirements and designs for each phase. Our tech lead helped us determine what would be feasible for each phase as well.
Quick User Feedback
As a rule of thumb, if I was stuck or the tripod could not arrive to a consensus on a design direction then I would take the questions to our users. Quick internal surveys and rapid usability testing helped me gather data and insights on how to move forward. When in doubt, test.
Releasing Approvals
Approvals was released incrementally in 2020. For some of our clients, approvals proved to be the sticking factor for LaunchDarkly. While some of the functionality of a more mature approval process was lacking it still proved to be an invaluable piece in the feature workflows world.
Nested Workflows
Nested Workflows
Nested Workflows
Nested Workflows
Nested Workflows
The last piece of the feature workflows that I designed and released during my time at LaunchDarkly was Nested Workflows. Nested workflows enabled users to combine the power of scheduled changes and approvals. This project was foundational in the workflow builder project that followed.
Combining the scheduled changes modal and the approval modal.
When a user went to save their changes they were presented with the modal to the right where they could choose to schedule and/or request approval for their changes.
Users no longer had to explicitly select ‘request approval’, ‘schedule changes’, or ‘save changes’.
Reviewing a scheduled change.
Cleaning up the change list
A common theme during user sessions was that the change list could be too long and too dense which made it difficult to review changes quickly. Taking this feedback into consideration I moved forward in exploring ways to condense and clean up the change list.
Changes were now grouped by the change type entity, with collapsable sections, to condense the lists. Icons + colors were added to visually distinguish the changes.
Previous change list
Updated Change list