When a UI Update Complicated a Simple Task: How I Restored Search to Its Core Purpose

How a change meant to create order turned a simple process into something especially heavy

In my work at WeDev Technologies, the Shopify Partner Dashboard is a daily tool. The agency manages hundreds of stores, and people in different roles use the interface throughout the day to move between them for development, QA, maintenance, settings, and ongoing management.

Until recently, reaching a specific store was simple: open the Dashboard, type the store name in one search bar, pick a result, and enter.

Recently, with the launch of the new Dev Dashboard, Shopify changed the interface structure and split stores into three categories: Dev, Transfer, and Collaborations. Search was split the same way, so each search only runs inside the active tab.

When I open the Dashboard to reach a specific store, I usually have one piece of information I need: the store name. I do not always know — and should not have to remember — whether it is marked as Dev, Transfer, or Collaboration. So a search with no results no longer means the store does not exist. I may simply have searched in the wrong tab. In that case I have to switch tabs, enter the search again, and if it still does not show up, try the third tab too.

When you work with hundreds of stores, this process quickly becomes trial and error. For me, that is the core gap: the user knows which store they want, but the interface also requires them to know how it is classified first.

Order matters — but not at the cost of another feature

I want to be clear that I do not have the full context, requirements, or constraints that led Shopify’s product team to this change. In my view, splitting stores into categories is not necessarily a problem, and it is not new by itself. When you manage hundreds of stores, that kind of classification can create order and give context to users for whom store type is meaningful information.

After the change, the problem for me was that classification stopped being a tool for organizing and filtering information and became a precondition for search. I think both needs could have been kept: leave a global search that returns all stores, and use the tabs as filters for people who want to narrow results by type.

At first I assumed I might simply be missing something in the new UI. I tried working with it in a few ways, moving between options and checking whether there was a unified search without switching across all three categories every time.

After a few tries I found that Shopify does allow a broader search through a secondary interface, but getting there still takes several extra steps. For an action that repeats throughout the workday, that still did not remove the friction.

In the days that followed I kept hitting the same friction. An action that should feel almost automatic started breaking the work flow and demanding attention it should not need in the first place.

At some point I also heard a colleague on the team dealing with the same frustration. In her case the problem stood out even more, because her work requires frequent moves between many stores during the day.

At that point I stopped treating the friction as something you simply get used to. I realized this was a workflow that repeats dozens of times a day, with an extra step that could be removed. That led me to the question: how do you bring search back to a simple action, without undoing Shopify’s new structure and without making users learn a new interface?

What should the search process look like?

The goal was to keep as much as possible of the flow users already know, and only remove the friction added by the new update — without adding another system or creating a new way to work with Shopify.

From there I defined a few basic principles for the solution: one search bar, search across all three store categories in parallel, results that appear while typing, a clear loading state, and a click that takes the user straight to the store.

Shopify’s dashboard UI is web-based, so I chose to build the solution as a Chrome extension. That let me change the interaction point itself, without creating a separate system and without taking the user out of their existing work environment.

The first extension version I built was fairly simple: a floating search window over the dashboard that allowed a unified search across all stores. Functionally it worked, but after a short period of use it was clear the UX was still not good enough. It added another layer to the interface and created duplication, because Shopify’s split search stayed in place and next to it sat another tool users had to notice and understand.

I realized this did solve the search problem, but it broke the existing mental model. Users were already used to opening the dashboard and searching for a store in a specific place. There was no reason to make them change that habit only because my solution worked differently.

So instead of adding a new flow, I decided to improve the existing one. In the next version I removed the floating window and embedded the unified search directly in place of Shopify’s search. For the user, the action stayed almost the same as before: open the Dashboard, type a store name, and pick a result.

The difference is that behind the scenes the extension now searches all three categories in parallel and shows the results in one list.

In the search results I chose to keep the tag that shows whether the store is Dev, Transfer, or Collaboration. The information itself can still be useful, as long as the user does not need to know it in advance to search. For me, the goal was to remove the unnecessary decision from the flow — not the information itself.

That way the solution became a natural part of the existing UI. Open the dashboard, enter a search term, click the result, and you are in the store you wanted. Same mental model, with less friction.

Flexibility that added complexity

After unified search already worked inside the UI, there was still another decision about how much flexibility I wanted to give the user. At one point I added a switch in the interface to move between unified search and Shopify’s tab-based search. The idea was to let users go back to category search if they needed to.

But when I looked at the flow again, I realized there was no real need I was solving. None of the people around me were looking for a way back to the split search, and the switch itself added another UI element and another decision for the user.

I realized that if this option did not serve a clear use case, it mostly added complexity. So I removed it. That also sharpened an important principle for me: flexibility does not always improve the user experience. Sometimes it just adds another decision that is not needed.

Technically, as noted, I built the solution as a Chrome extension that injects a content script into the Dashboard and replaces the existing search layer. While the user types, the extension sends three search requests in parallel — one for each store category. Then it parses the HTML responses, merges the results, and shows them in one list inside the UI.

For the user, all of that stays behind the scenes. They simply type and see the relevant results in one place.

This solution also has a clear trade-off. It is not an official Shopify integration, and it depends on the current DOM structure and dashboard behavior. If Shopify significantly changes the UI or how results load, the extension may need updates. For me that was still a conscious choice: pick a pragmatic solution that removes real friction here and now, even at the cost of some dependence on an existing interface.

After a few days of using it at work, the CEO came across the extension and asked to use it too. After that I shared it in the company’s main channel, and from there adoption across the agency was fast — for colleagues across the organization.

The strongest validation came from real use: more than 30 employees now use the extension regularly, including developers, Product people, project managers, designers, and QA. I did not need to explain why to use it or convince people to change a habit, because they immediately recognized the same friction and the value the extension brings in removing it.

In terms of time, this is an action that repeats at a very high rate. At an estimate of about 15 store visits per employee per day across about 30 users, that is on the order of about 450 searches a day. In cases where several tabs were needed, the original flow could stretch to about a minute, while unified search usually takes around 10 seconds.

When an action repeats hundreds of times a day, saving tens of seconds each time quickly adds up to several hours of work at the team level. The action became almost invisible again inside the workflow: open, search, pick a store, and keep working.

A single friction point can grow into a big problem

The process reinforced for me that an action of a few tens of seconds does not always look meaningful when you look at it once. But when it repeats throughout the day for dozens of users, the friction builds up very fast. In this case, the frequency of the action mattered no less than the size of the friction in each single interaction. Sometimes it is exactly the small daily actions that are worth examining in depth.

Another insight was that a solution can be right for information architecture and still create friction inside a core flow. Shopify’s split organizes the information, but it does not have to dictate how a user finds a store. A good product decision should account for both the system structure and the way the user actually does the task.

In the end, the main value in this process was the ability to spot friction inside an existing product, understand what in the product decision created it, reduce the problem to a clear user need, and test a real solution quickly. My technical background let me connect product thinking, UX, and execution in this process, and move relatively fast from spotting the problem to a solution I could test, improve, and see adopted in practice.