Util
Case study
Bold Commerce
The work presented in this case study is being completed while the author is employed at Bold Commerce. Bold Commerce owns the rights to this work and its use is solely for the purpose of this case study.
The views and opinions expressed in this case study are those of the author and do not necessarily represent the views of Bold Commerce.
Bold Commerce
Bold Commerce is a SaaS, eCommerce, technology company whose solutions help businesses enhance their online presence and boost revenue.
What is Util?
Util is an internal tool for Bold's merchant success (customer service) team. They use Util to manage their client's accounts and commonly for turning feature flags on/off for shops.
My role
I was the sole designer on the internal tools team at Bold Commerce between March 2021 and January 2022. I collaborated closely with ~6 developers and a product manager.
Context Some background
Many of our clients manage two (or more) stores. Store fronts that are used for testing are known as staging environments. Companies will use staging environments to ensure that changes to their store are tested first and won't cause issues that may result in down time for their customer facing store. The customer facing store is known as their production store which is their main, customer facing, online sales channel.
Assumptions
Due to the fact that this tool is only used within the four walls of Bold, we knew our users and I was able to talk to them on demand. I could confidently infer that all users were technically advanced and could handle a higher degree of change and complexity.
the problem Keeping the shops in sync
Both production and staging stores’ features flags must stay in proper sync with one another when the user attempts to add new feature flags. In order to do so, the system has to know that there was a relationship between the two stores as indicated by the merchant success agent (the user).
Our goal was to allow users to create a relationship between shops (link shops) so the system could enforce rules upon future users when they look to make changes to feature flags.
Our goal was to allow users to create a relationship between shops (link shops) so the system could enforce rules upon future users when they look to make changes to feature flags.
All the feature flags included in the production shop also exist in the staging shops.
Staging environment B is missing the purple feature flag.
Both staging environments are missing the green feature flag.
Staging environment C is missing the orange feature flag and cannot connect to the production shop.
exploration Adding a new feature to Util
In the current layout of the shop's page in Util, all of the actions that can be performed on a shop are grouped near the bottom the page.
To understand what impact the order of the groupings have on the users I asked potential users“what is most important on this page?”. I learned the currency section is less important and that users are most frequently coming to this page to make a change to the shop.
To understand what impact the order of the groupings have on the users I asked potential users“what is most important on this page?”. I learned the currency section is less important and that users are most frequently coming to this page to make a change to the shop.
Util's original shop page
Priotize and reorganize
To bring the action section closer to the top of the page I retained the groupings but created differentiation between “read only” information by putting them in collapsible panels and splitting the page vertically with them. The actions section not only was now available above the fold, but also created more space to add the new shop linking feature.
By putting the informational (non-action based) content in panels, it also allowed me to de-prioritize the currency section by setting it to collapsed by default. Having the information minimized reduced the amount of information being displayed on the page, which allowed more important content to be further highlighted.
The shop page with a new layout
Relationship status: it's complicated
We needed to be able to show the hierarchy each individual store held to the user. I went through several rounds of exploration and critique from both other designers and developers. I quickly understood that linking could get complicated quickly and needed to make it simple to add relationships and also understand them.
Taking inspiration from industry
I looked for ways to simplify the task of creating a relationship between shops when I began to look at JIRA's flow for linking work order tickets. Their use case is even more complex that ours, where tickets can have a relationship based on many factors and be multi-generational. (A child of one can be the parent of another).
JIRA being a tool we use at Bold strengthened the ease of the flow for our users because their mental model was already trained.
JIRA being a tool we use at Bold strengthened the ease of the flow for our users because their mental model was already trained.
Screen grabs taken from the JIRA app
prototype Applying it to our use case
I repeated the dropdown method that JIRA was using to create a sentence-like structure when building the relationship.
The flow for searching for a shop repeats functionality that already exists within the application, so the user is familiar with it.
Double check the connection
Connecting shops isn’t functionality we currently have in Util, however feature flags are. In order to maintain the rules we created for shop connections , we have to check that the shops the user is looking to link have the necessary feature flags in common from the start.
I used the diagram I set out in the beginning to understand the errors that could occur at this stage in the attempted connection. The error message could vary depending on whether it was a child connecting to a parent or vice versa.
A lot of reliance on the user
It was clear after presenting the issue to multiple groups that the diagram was important when visualizing the problem. Unfortunately in the interface we are more constrained to what information we could provide the user in terms of what feature flags are causing the issue.
Ultimately, due to technical and time constraints we had to rely on the sophistication of the user to triage the issue. I went through multiple iterations and testing of error messages to clearly convey the issue the user is facing.
Ultimately, due to technical and time constraints we had to rely on the sophistication of the user to triage the issue. I went through multiple iterations and testing of error messages to clearly convey the issue the user is facing.
Words are hard
Error messages were just the beginning of the struggles I’d face when trying to not only create an intuitive user flow but also convey what the feature is in text. I created definitions for what we’d ultimately end up calling development stores - what I described earlier as staging environments and main stores - what was previously described as production shops. 
When interviewing developers, they believed these titles were the best at describing the relationship that was occurring. It was found that words like production and staging were too closely tied to developer lingo, and parent/child were too vague.
A little more help
The problem statement and acceptance criteria throughout the design process was consistently hard to grasp. In order to add some additional support to the users, I added tooltips in the headers of the linked shops groupings.
Results What was the impact?
Due to the internal nature of Util, there aren't any tracking or metrics associated with it's usage. We only have word of mouth feedback to go off of. Ideally we would have been able to track the number of feature flag related incidents before and after the addition of this feature.
However, the feature was successfully implemented and is currently be used in production. Many of Bold's largest clients have linked shops which has helped keep feature flags from being mishandled.
However, the feature was successfully implemented and is currently be used in production. Many of Bold's largest clients have linked shops which has helped keep feature flags from being mishandled.
A new problem arises
Now that feature flags play a primary role in the ability for shops to link, it became increasingly important that the management of them is easy. In order to support the process of diagnosing feature flag related issues, work to improve the feature flag tab of Util became prioritized. The case study for feature flag tab improvements is part two of this case and is currently being written.
© REAGAN TAKEUCHI | 2025