Terms to know: UX design
What exactly is a design system? How do I write a user story?
If you’re a UX designer, then you’re familiar with a very particular type of feeling. It’s one that we all, eventually, find ourselves confronting at some point or another. Whether that’s at the beginning of a project, or during engineering handoff, this feeling can be difficult to navigate. What is this feeling, you ask? It’s called confusion.
One of the reasons that UX designers face confusion often is because of the structure of our roles. It is our responsibility to ask questions about the problem, the user, the business needs, and the solutions that surface. We are like detectives trying to solve a cold case with only a few scattered puzzle pieces of evidence to go off of. Every time we ask a question, we find another piece of that puzzle. As we search, however, we can easily become confused by the dizzying nature of not having all the answers.
One way to mitigate this confusion is to cut down on any miscommunication mishaps. You can do this by making sure that you’re asking the right questions. This means using the correct terminology to fill in any blank spots in your hypotheses. Since the quality of your answers are only as good as the quality of your questions, it’s important to make sure that you’re aligned on what you’re asking from the people around you.
To help, I’ve created a list of UX design terms that everyone should know. Feel free to share this list of terms with your team to make sure that everyone is aware of these definitions. If your entire team is aligned on what each term means, you’ll be able to frame your questions in a much clearer way. This will help you to find your puzzle pieces even quicker, thus bringing you and your team closer to a well-rounded design solution.
UX design terms
User stories:
User stories are one way that designers communicate with engineers. Writing user stories allows your engineering team to understand what your solutions intend to look like from the user side. An example of this could look like:
As a new user, I will see the welcome modal dialogue when I first log in so that I can be introduced to the product.
The format for writing a user story is pretty straightforward. It looks like this:
As a {type of user}, I will {goal} so that {reason}.
Framing your user stories in this way will help communicate who the user is, what their motivations are, and what they should be experiencing…all in one sentence.
User journey:
User journeys are diagrams or infographics that designers create to help communicate the paths that a user can take. User journeys can be very extensive, including every possible route within an entire website, or they can be simple and only focus on one task at hand. The intricacy of your user journey design depends on what you’re trying to communicate, and to whom.
Empty state:
Empty states are sections of your digital product that do not have any content in them yet. For example, imagine that you’re a new user on Instagram and you have not uploaded any photos. Your profile would show an empty state where your future photo grid would live. Having empty states helps communicate to users that these sections are to be filled in later on. Empty states are usually temporary until users take action to fill them.
Edge case:
Edge cases are the outlier situations within your product. They are possible pathways that a user or a design could take, but are more rare than your typical route. Designing for edge cases allows for preventative flexibility. What I mean by this is that when you design for edge cases, your designs incorporate all possible scenarios into them, making system breaks less likely to happen.
A good example here would be translating text in headers. If your product is available all over the globe, most likely you’ll run into translation edge cases. German, for example, typically forms longer text strings when translated from English. To ensure your designs don’t break when translating, make sure that your text sizes are flexible enough to make room for longer text strings.
Another example happens when users’ names are displayed. Names are very personal, arguably the most precious thing we own as individuals, which makes them important to your users. It is critical to display them correctly. While names typically vary in size from small to medium, every now and then you’ll see a ridiculously long one. These are the types of edge cases that you should be accounting for.
MVP:
MVP stands for Minimum Viable Product. One way to frame an MVP is this: what is the simplest product that you can create that will elucidate the most amount of insight? Creating products at the MVP stage allows you to keep scope and cost low, while still observing how users interact with your product or service. Some insights you can gain by creating an MVP could be user interest in your service, usability testing, or feature validation. One important thing to note is that for many teams, MVPs are step 1 in product or feature creation. Most MVPs are created with the intention of future iterations. Generally speaking, teams will use the insights from their MVPs to add, subtract, or adjust their product accordingly.
Desk check:
Desk checks are quick chats between team members. These typically occur when an engineer wants to show a designer where they’re at with the development of a product. Suppose an engineer is coding up a welcome modal dialog design that a designer has sent over, and they’re at a point where they believe they’re nearly done. That engineer will reach out to the designer and have them look over their work. This moment of communication allows designers to QA their designs and make sure that they’ve translated over into code correctly.
User testing:
When we user test a product, we are looking to see how users react to that product’s interface and functions. We do this by having users perform specific tasks, under realistic conditions, to gain insight into their reactions. Do they understand where a particular button will lead? Can they tell that a specific icon is tappable? We use user testing to validate or adjust our UI/UX decisions.
Iteration:
Iterations refer to the cyclical nature of progressing a product. When we iterate, we go through a process of prototyping, testing, collecting data, analyzing results, and refining our designs. In iterative design, the product is never truly finished because it is constantly being iterated on. This allows products to stay current and ensures that you’re continuing to pay attention to your user needs.
Hierarchy:
Hierarchy often refers to typography, but can also be used to refer to information in general. When we talk about hierarchy, we are often referring to what a user sees first, second, third, and so on. An easy way to describe this is by comparing it to a newspaper. There’s the large, bold headline that draws your attention. Then, there’s a picture that connect to the story. And then, there’s the smaller body copy that dives into the article. If all of these elements were the same size, weight, and prominency, we would have a really hard time knowing what to look at first. This would overload our brain and create a negative experience, something UX designers are constantly trying to avoid. By using hierarchy, you can cut down on cognitive overload and make information processing easier for your users.
Design system:
A design system refers to a set of design standards and repeatable components that can be used in combination as a foundation for your designs. Design systems allow us to design without needing to reinvent the wheel every time. We use a design system when we want to use components that already exist elsewhere in the app. Buttons, for instance, usually have a particular color and shape to them that are consistent across all pages in an app. That button styling is part of the design system. If all of your product’s primary buttons are purple rectangles with white text, you wouldn’t make a blue, circular, primary button with black text. That would mean breaking your design system, something you have to have a good reason for.
If you do have a good reason to break your design system, then that’s okay too. Often times, design systems don’t cover every particular use case because products evolve, which means new use cases arise. Working with your design system to keep it up to date is an integral part of being a designer. Design systems are living documents, intended to be updated whenever the need arises. However, there is an art to design system updates. You wouldn’t want to update your system when another, already existing component could be used. It’s easier to adjust your designs to fit your design system than it is to adjust your design system to fit your designs. If you do the latter, you run the risk of not really having any particular system at all. Rather, a compilation of various disorganized components. The whole point of having a design system is to stay organized, cohesive, and efficient. This, in turn, cuts down on any possible confusion and creates a more seamless experience for your users.
There you have it.
A non-exhaustive list of terms that will help you down the road to discovering your best design solutions. These are the basic, high-level definitions that will create unified understanding among you and your teammates. Often, it helps to refer to these terms when you are advocating for your designs. For example, I use the term ‘hierarchy’ a lot when working with clients to explain why I cannot make the logo bigger or bolder, if it does not need to be. Once I explain what this means, and why we must adhere to these UX rules, clients are able to understand the reasons behind my UX decisions. This helps align us on what our ultimate goals are, and how we can get there together.
