Designing for invisible UX
A framework for creating search and personalization experiences — and how to apply it
This piece was co-written with Kay Jorgensen.
Content discovery is a big deal right now. For many of us, powerful search experiences and refined recommendations help us plan and move through much of our day.
The tools that power this content discovery are evolving. For product teams, a user’s experience of these tools is becoming synonymous with their experience of their products. As a result, there’s a growing call to design these tools the same way we design the products they’re embedded in.
As content designers, we’ve got lots of practice designing intentional user experiences. The content designers at Shopify have an amazing toolkit of tactics to do this. Typically we talk about using these tactics to build things that merchants control, or at least know they’re using. But we often don’t want merchants to focus on the content discovery tools we embed in products because we want them to focus on the product itself. As two content designers working on search and personalization problems, we struggled to understand how to apply familiar tactics to design the less tangible products that we work on. We refer to our work on these products as invisible UX.
Understanding invisible UX
We developed a framework based on systems thinking principles to break invisible UX projects into pieces that we could define and understand. The framework outlines components that, when combined, form the basis of invisible experiences. The framework is made up of four components: inputs, structure, output, and the interface. Design thinking can be applied to each of them.
Input
The input is the data the system uses to accomplish its intended function. The data could be anything: metrics like sales, visits, or availability of products; or content attributes like product tags and descriptions. The data might also come from an action or behavior, like the act of selecting or creating something, entering information, or abandoning flows. Systems are often built around multiple inputs. In more complex systems, logic and conditions are applied to make meaning out of different kinds of inputs.
Deciding what to use as the input for a system will be dependent on the goals of the project. UX can help identify and define which inputs are relevant by exploring the problem space using UX tactics such as audits.
Structure
The input is organized according to a structure. Structures are principles for organizing your inputs. Designing the structure for a system involves things like defining the sorting logic or conditions. The structure might sort inputs programmatically, like through an algorithm, or manually.
Defining the structure is often a key deliverable for content designers involved on these projects. Articulating how decisions about the structure of a system affect an overall experience is another important UX opportunity. Think about the data used and what you want the feature or product to do. This will help you make decisions about how to organize the inputs you’re working with. It also makes it easier to plan how you might help people understand how these systems work.
Output
Ultimately, the structure results in an output that should solve a user problem. At Shopify, we define outputs to do things like:
- Help a merchant find apps
- Recommend actions
- Provide business insights about their store
We should be mindful of how well our outputs help people solve the problem we’re focusing on. Think about how to create a flexible structure that can respond to feedback about the quality of the outputs.
Part of our UX practice is thinking about the different possible paths through an experience. For invisible UX, that includes accounting for the different responses people might have to the output they receive. It also includes accounting for the different kinds of output that a system will define. Documenting and preparing for both of these helps us plan for how to represent the outputs on the UI.
Interface
Usually, people use an output by interacting with it on the UI. How the output gets represented on the interface depends on what problem is being solved. If the output helps someone find something they’re searching for, then it will likely look different from an output that’s recommended to someone because it’s related to their interests. The same output could be represented in different places throughout a product. The context for where the output is being shown also affects how we represent it in the UI.
How and where an output is represented depends on what the system and product are designed to do. Applying UX thinking to every component in a system helps us to frame those systems on the interface.
Working on an invisible UX project
To explain what this looks like when it’s applied, let’s talk about Shopify’s native search. This is offered to all merchants on Shopify with an online store.
Over a year ago, we started with a search experience that didn’t accommodate for errors or spelling mistakes. Customers had to use exact terms to get results — which is a near impossible task for a user who might not know what they’re searching for, or is visiting a store for the first time.
We were also dealing with a search system that doesn’t really have a taxonomy. Our fields for product titles, tags, product type, and collections are free form and merchants use these fields in different ways, depending on their industry, size, and needs.
We started with trying to understand what users expect from search. We audited everything from library searching to different ecommerce platforms, as well as segmenting different types of searchers. We learned that merchants interact with search in so many different ways, depending on where they are in their purchase journey. This helped set some of the foundational UX guidelines for
- What inputs need to be part of the structure
- How flexible this structure needs to be in terms of relationships and logic
- What that structure should output
As with any project, scope was important. We needed to define what the system should and shouldn’t support — Do we need to include all the available store data? Should it display recommendations or alternatives? These UX questions helped establish what the feature needs to do and what needs to be part of the system.
Experimentation can begin
Once we’d mapped out the current system, we were ready to start exploring and experimenting.
We experimented with a few different things:
- Logic
- Resources
- Attributes
- Hierarchy
- Ranking
- Relationships
What should the relationship between attributes and search functionalities be? Do we need to create different relationships for different attributes? In what conditions do these relationships apply?
Because we had broken down the system into our framework, we were able to pinpoint where in the system we needed to tweak something when the interface didn’t produce the experience that we wanted. Without this it would have made these different layers, conditions, and functions really confusing to keep track of.
All of these questions were answered by the UX team — but the answers didn’t impact the interface as noticeable design elements. As you see we haven’t mentioned field size, or buttons, or labels. Our solutions were — invisible.
Last but not least, one of the most important tasks that we did as a team was to align on definitions and terminology. We sat together with data and development, mapping out the important parts of the system, identifying the terms, aligning on what they meant, and where they would affect the user journey, UI, and related user tasks. By doing this, we were able to find more merchant-friendly terms and communicate more efficiently as a team.
Familiar tactics for new problems
Invisible UX projects often address a new kind of problem. But even for new problems, design thinking can contribute to crafted solutions through structure, definition, and establishing context. Using a framework helped us understand our contributions as designers working on invisible UX because it made the work more tangible. Thinking about our product as a system made of pieces with names and functions gives us a better way to communicate and collaborate with our teammates, and it helps us connect our decisions to the problems and user experience we’re working on. Frameworks are another familiar design tactic that works to make sense of these new problems too. Try it out. Find the invisible UX in your products and use a framework to help you understand how you might contribute to designing the user experience in these often overlooked spaces.
