I just gave a presentation at Prairie Dev Con this week on how development teams can apply UX mindsets to their work to stop reacting to mocks and own their products. This talk was well-attended and well-received, and I was asked to share the slides online. Rather than plunk a PDF of the slides themselves somewhere without context, I thought I’d share the presentation here to make it easier to find, share, and discuss.
“I’ve spent the last 5 years working with product teams at several companies to help deliver great experiences to users across the world. While my focus is on user experience strategy and design, I work with developers every day. Today’s topic was inspired by a comment I heard from a developer.
Today, I’d like to talk to you about how you can stop reacting to mocks and, instead, own your product.
Almost everyone in the room is familiar with what it means to be reacting to mocks. You get to work in the morning, and there’s a new feature request in your backlog.
“We’re changing this thing! Mocks attached. Please implement ASAP.”
If you’re lucky, there might be a styleguide that you can follow.
So you build it to spec, and ship it to production.
A week later, you get to work, and there’s another request in your backlog: “We’re changing this thing again because ‘everyone’s complaining.’”
Whether you’re a developer, designer, product lead, or QA, this sucks. Nobody likes sitting around reacting to mocks day in and day out.
When we’re in “react” mode, the product suffers. Each new feature is done in isolation, and it’s easy to end up with a pile of disconnected, bandaid solutions. It becomes harder to implement each new feature.
The product team also suffers. Reacting to mocks means that work is being done on an assembly line: each person adds their own coat of paint and tosses it over the fence. When something doesn’t fit well into the product as a whole, we have to either compromise our own integrity to hack it in, or we have to push back. In the end, we have a product team that’s dealing with conflicts both within the product and within their team.
Instead of reacting to mocks, we should strive to own our product.
Owning your product means everyone on the product team taking responsibility for the product as a whole.
This doesn’t mean “do everything yourself.” We have product teams made up of different disciplines because that’s what they are — disciplines. However, each member of the team can still take responsibility for creating a great product as a whole. We were each hired to specialize in our discipline within the product, but at a high level each person was hired to ship a product.
When everyone on the product team owns your product, you end up with a stronger product. You’ll have a better understanding of the product, the product’s parts will form a better whole, and your users will have a better experience.
And you’ll build a stronger team: people will have more passion for what they’re creating, it’ll be easier to resolve conflicts, and you’ll more easily be able to work together to take the product where you want it to go.
But it can be tricky to get to that point. Product teams are made up of many different disciplines, each with their own unique perspective, background, weight of authority, and understanding of the product. Each individual on the product team is looking at the product through their own lens.
As a UX designer, I’ve found that there’s a number of UX mindsets that product teams can adopt that give us a shared perspective. By thinking about the product with these mindsets, everyone on the product team, no matter the background, can begin look at the product through the same lens.
We’re going to look at these mindsets today. They’re high-level — they aren’t tied specifically to user experience design, and they’re very easy to keep in mind while you’re creating your product. Anyone can learn how to apply these mindsets.
Because I love structure, here’s how we’re going to approach each mindset:
First, we’re going to look at what it is.
Then, we’re going to see why it matters to everyone on the product team.
And to make it “actionable,” we’re going to run through a short checklist that you can follow while you’re developing your products. I’ll be providing a nifty link to this checklist after the talk, so don’t feel pressured to take anything down!
Mindset 1: Know your users.
Let’s jump in with the first mindset: know your users.
The best products are built from the ground-up for their users. Not CEOs, not founders or partners. Products are for users.
This is where you’re thinking I’m beating a dead horse.
However, it’s true. Here’s a completely different way of looking at it.
A great product is one which is viable.
An example would be Slack, the messaging application. It was viable for them to develop Slack because they had the resources: people, time, money.
It’s one which is feasible.
Slack was feasible because from a technical perspective, it was a straight-forward application to build. It wouldn’t require a lot of new technology or innovation.
But, it doesn’t matter how viable or feasible your product is if there’s no desire for it.
Great products are also desirable.
When you truly understand what problems your users are facing, and thus what they need and want, you can look through these three lenses to find the best solution.
Slack hit it on the nose. Funny enough, most of us didn’t realize we needed a better messaging application until we tried it for the first time.
So if we’re starting with the users and their desires, it’s important to remember: you aren’t the user.
Even if we would use this product, ourselves, in real life, we aren’t the end user we’re building for. As members of the product team, we’re too close to it: we have too much context into how the product works, why certain things are the way they are, and the way we think about the product is shaped by how we, as developers or designers, would behave.
We’re creating products for our users, and to do that effectively, we have to be able to see and feel the product from the user’s point of view, not our own. So when we talk about “knowing your users,” it’s really about building empathy for your users.
The first step in building empathy for our users is to change how we think about them.
“Users” sounds sterile — like we’ve rounded up a corral of people that’ll use our product. I prefer to talk about our users as humans. Humans are us: they’re individuals, entirely unique, and filled with their own emotions, preferences, and experiences.
There are real people out there using your product — or there will be. There’s more to them than the need and ability to login and complete a basic task.
We use human-centred design tools to build empathy with these humans — journey maps, interviews, field trips, etc.
The most accessible, and widely-used tool, is personas. They’re like the cliff notes for your humans. They’re a single high-level tool that everyone can understand and use immediately without a deep understanding — unlike journey maps which require a lot more build time and maintenance.
“The artifact is not the important part of creating personas. Shared understanding of user needs is the real deliverable. Focus on that.” —Kim Goodwin
This is the real purpose of user personas. They act as a rallying point for the product team. The act of creating personas is a way for the team to build a shared understanding of their users, together. The artifacts we create — the personas themselves — help us get back into a point of empathy with our users.
In order to do this well, we have to build personas that we can truly empathize with. Some of the best personas are based on people you actually — maybe personally — know.
How many of you have seen, or use, personas that read like this?
“I want a doohickey to help me study more effectively.”
His goals include finding a credible doohickey and buying it.
Does this sound like a real person that you can empathize with?
This persona tells the marketing department that people want to use their product. It’s a pat on the back before they’ve done squat.
Let’s redo Jack’s persona — give it meaning.
Jack’s real goals are passing his next exam, while still finding time to spend with his friends.
He’s feeling pressured and distracted by a poor job market and the weight of his student loans. He wants to find a summer internship that has normal work hours, decent pay, and can give him an in before he finishes school.
A doohickey that helps him study is a means to an end, not the end itself.
Making a persona isn’t about making a well-designed printout. Like we mentioned before, the artifact isn’t the goal, shared understanding of your users is.
Now, how can you make sure “knowing your users” is part of your development process?
First, do you have personas? And are they actually useful?
They might need to be dusted off.
Because personas are meant to give the team a common starting point, it’s helpful to know if the team sees the personas the same way.
Looking at, for example, a reset password process, does each member of your team imagine a similar experience for your persona? Or does one person think the persona will ace it, while another thinks it ends with a call to the helpline?
Was your whole product team involved in creating the user personas? When was the last time you updated them?
Some of us inherited personas from past team members, marketing teams, or conference slide deck. It’s difficult to relate to something that you have no personal connection to, and even more difficult to imagine this person using the product.
When we use personas we often read between the lines of the info provided.
When I read between the lines of “George, a 45-year-old house painter’s” I’m probably coming up with a different answer than the person who wrote it in the first place.
For personas to be a team resource, they need to be owned by the team. Your team, not just marketing.
Are you using these newly created or refined personas to evaluate problems and solutions?
Or are they doing more as wall decor or wiki clutter? To get the use out of resources, you need to take them off the shelf.
To make sure they get the face-time they need, try attaching them to feature requests — this could be identifying which personas are relevant for particular features, or going so far as to write use cases from their perspective.
Have you watched someone use your product?
Even better than personas is, obviously, real people. User testing sounds very formal, and like someone else’s job. This isn’t user testing. This is simply watching someone else use your product. This could be a colleague, someone on another team, someone at home, just someone. No matter how it goes — they ace it or it all falls apart — it puts the product in a different perspective. The simple act of watching someone use a product reminds us that it doesn’t exist on its own, it needs the user — and the user needs it.
Can you hold a field trip?
Even more valuable is getting out into the real world. Scientific studies are skewed everyday for the simple fact that they occurred in a lab, not in the real world. Just like watching people use your product puts it in a different perspective, so does seeing it in the wild. It adds another dimension to your understanding of the problems you’re solving.
Mindset 2: Your product has a job.
Which brings me to the second mindset of the morning: Your product has a job.
Your product exists as a solution to a problem — a problem that users have. It can be high-level, like Facebook’s ability to connect us to friends and family around the world. Or it’s more tangible, like requesting a ride to the airport.
Strong products are those that helps people achieve something. They exist to solve a problem for people, and they do. This requires a strong understanding of the problem in the first place. Only when we truly understand a problem from a human perspective can we visualize the end goal, and build a solution to get us there. And by knowing what our end goal looks like, we can better measure if we’re successful.
At the product level, this can seem like an existential question — “Why am I here?” If you’ve been hired to work on a product, this has probably been defined for you, it’s what spurred the company to exist in the first place.
At the feature level, is each feature contributing to the whole? Features will often solve smaller, individual problems. When each of these individual problems is solved, you’ll often find you’ve also solved the larger product-level problem.
Focusing on the product’s job keeps the product and its features on track and on time.
Because we understand the big picture end goal — the product’s job — we can better plan and build features to keep it moving in the right direction. So we’re solving the right problems, instead of running around with a hammer looking for a nail.
Problem-solving, by nature, makes us happy. Products enable users to solve problems.
In some cases, products have one job, but when they do it, we’re happy campers. For example, Messages on my iPhone sends messages. Find my Phone finds my phone.
For many products, the problems they solve are more complex. And that’s okay — as long as you know what those are.
Here are some tools for defining those problems that inspire your product.
Does everyone on the product team have a clear understanding of the problem the product solves for our users?
This isn’t the company mission or vision statement. And it isn’t just for new hires. In fact, it’s even more important to reiterate for those of us who have been on the team for a while. Clarify what problem you are solving — why are the lights on? Why are all these people gathered here? Why are people paying to use our service?
Can you describe your product in 50 characters or less?
This is something that Y Combinator asks all applicants to do. It’s surprisingly difficult — 50 characters, that’s less than a tweet!
But once you’ve got it, those 50 characters can keep you far more on track than any well-crafted mission statement.
Here’s an example. “Press a button and a car comes to you in minutes.” That’s Uber, obviously. If Uber as a product ever finds itself not doing this, it’s no longer doing its job.
This is Slack. It could also have been Hipchat, but Slack does it better. They’ve put their focus here and it shows.
Does every feature request describe the problem being solved?
Do feature requests have a reason for existence? “It’s on the road map” doesn’t count. What problem are we solving by implementing this feature? Set the standard: before you can create a solution, you need to know the problem.
Does every feature request have a clear way to measure “problem solved?”
When we understand the problem, we can visualize what success looks like. From there, we can pull out how to measure that success. If I create something, even if I understand the problem, if I don’t check to see the problem is solved, I’ve simply put another feature on the pile.
Loop it back to the user again. Just because the interface solves the problem doesn’t mean that the user can. Technically, by providing phone numbers on a website, the company has solved the problem of how to get a hold of them — but what about deaf customers?
Mindset 3: Build a vocabulary.
To better talk about problems and solutions, we need a vocabulary. I don’t mean for everyone to learn my vocabulary as an UX professional, but rather a vocabulary that’s shared by the whole team.
Having the words to talk about things helps us think about them, critically, on our own and within our teams.
Vocabularies will often come into being simply by there being a group of people with a shared interest and understanding of a subject.
For example, sommeliers describing wine.
When I taste a wine, I can tell you if I like it or not. Even though I know what oak and fresh cut flowers smell like, I have trouble connecting those concepts to what I smell or taste.
Pictograms and symbols, on the other hand, begin to form an universal language. They’re one of the earliest — and most persistent — forms of communication, because we can all relate to them. This makes things like travelling easier, when all other forms of communication are failing us.
As developers, everyone will be familiar with the word soup that we use while creating modern web products.
When you’re speaking the same language, the words get out of the way, and we’re able to focus on the meaning. It becomes about the product, the problem, and the solution — not trying to decipher what the other person is saying.
Here are some starting points for building your team’s vocabulary.
First, does your team have a shared vocabulary?
You might already have some common language. Some language is software-specific, such as “onboarding.” Some language is company-specific, even the names of products are part of the vocabulary you should share.
I used to work for a company that developed products that were used internationally, which meant a lot of the company names were in languages other than English:
It’s nonsense to anyone on the outside, especially since almost none of these products existed in North America. Every new hire needed to be briefed on our suite of products.
There are some common terms already in existence to describe parts of the user experience. Here are a few from my world:
The means by which a touchpoint is delivered.
Example: Your mobile app.
A point of interaction involving a specific human need in a specific time and place. A single touchpoint may be supported by multiple channels.
Example: A flight booking app has a “Sign up” touchpoint, which is supported by two channels: the app itself, and the email confirmation.
The specific user activities that a touchpoint supports.
Example: Filling out your user details in your flight booking app’s signup form.
The small details that make up the interaction. (These are the parts that often make you grin.)
Example: The message that appears when the password you enter is strong enough.
The user’s movement between touchpoints over time as they solve their problem.
Example: Your user’s journey on your flight booking app will move through signing up, searching for a flight, selecting a flight, paying for the flight, and going on their trip.
Is there somewhere your team can see and add to this vocabulary?
It’s only a shared vocabulary if everyone knows it. Post it somewhere everyone can reference — and update as necessary.
Do you teach your vocabulary to new members of your team?
One of the hardest parts about getting started at a new job is getting up to speed with the team dynamic. Putting a new hire into a meeting where they don’t speak the language is sabotaging them from the beginning. Give them the tools to understand the problems they were hired to solve.
Are there terms already in use that can be introduced to the product team as a whole?
To better communicate with other teams, share your vocabulary. They may also have terms to add. This can make meetings much smoother, because the language gets out of the way, and you can focus on the matter at hand.
Mindset 4: Understand context.
The next mindset I’d like to talk about is understanding the context that surrounds your product.
Context changes the problems your product is solving (and creates new ones). Problems aren’t clean cut. They’re coloured by many factors, both internal and external.
Our users encounter products in the wild. They’re operating in different contexts, shaped by their own environment, emotions, objectives.
Context that affect use of a feature comes from within your product. Features don’t exist in isolation, but as steps toward a bigger goal. The act of buying something on a website requires the use of multiple features: browsing, adding to cart, logging in, checking out, looking at archived orders, contacting customer service, it goes on.
Context that affects use of a feature also comes from outside of your product. It can come from your user’s environment, the user’s past experience, or the user’s emotional state.
One of my favourite examples is the “hungry human.” The term “hangry” exists for a reason, “you’re not you when you’re hungry.” Anything that seemed simple or straightforward before, now seems to take an eternity, and you’re much more likely to get frustrated. That may mean that while four taps to find a local pizza joint is totally reasonable under normal circumstances, it’s unfathomably annoying when you’re hungry.
The context inside and outside of your product affects the overall experience.
Do you know the situation each feature exists in?
Features are used by people in the real world and often under very different experiences than they’re planned in. If you can identify the context the use case will occur in, you can better plan the solution.
Planning the “help” section of an app is a great example. Providing the most thorough information, while important, isn’t as important as making that information as accessible as possible. People — especially when stressed out — have difficulty defining the problem they’re having, make it easy to find a problem, understand that they may not know the cause, just that this isn’t working.
What context within your product could affect this feature?
Because features are generally not used in isolation, they’re affected by those that come before (and after) them. Take note of where the user is coming from, should you be treating this user differently from users who come from elsewhere?
A user’s first time using an app is a common example. The first time you open a feed — say on Twitter — you’re bombarded with media. This is an opportunity for the app to help the user along — if that’s providing them with coachmarks, acknowledging them when they use features for the first time, or providing more suggested accounts to follow than you normally would. Whereas the next hundred times that same user opens the feed, they’re fine, and the feed can carry on normally.
Are certain contexts common enough to attach to personas?
You’re probably going to run into a few scenarios that come up often. If you’re creating an app for a pizza joint, 99% of your users are going to be hungry. Hangry.
You can flesh out your persona docs with different emotional and mental states, and apply those to feature requests. Then consider those contexts when planning the features. Instead of imagining Jack using a feature, imagine it from the perspective of Jack when he’s already running late and just needs to check one thing while running out the door.
Mindset 5: Find the gaps.
The next mindset I’d like to talk about is finding the gaps in an experience.
We have a lot of expectations. I expect my bus to come on time — no, sorry, I’m in Winnipeg — I expect it to come no more than 10 minutes late. Maybe.
I expect that if I forget my password, you’ll let me reset it online.
I expect if I subscribe to a service, I’ll easily be able to unsubscribe at my leisure.
There’s one app I use that drives me nuts every day that I use it. I expect that when I open a file in this app, it will show it to me in front of all other windows I have open. It doesn’t! It opens files, for some reason, behind the window I currently have open. It’s a bug, but it should’ve been fixed ages ago. That simple gap grates on me. Every day.
When I expect one thing and another happens, my focus is shifted from the task at hand to solving a new problem that I didn’t anticipate nor did I want to solve in the first place. Even if it’s something as simple as moving one window out of the way to get to the file I opened.
These gaps aren’t always your product’s fault. This is where watching people your product in the wild can be eye-opening — external factors, including users themselves, might be affecting how your product is being used.
We were working on a barcode scanner feature that would allow users to scan products in-store to get more information. In usability tests, we found people were easily able to scan items and find the info they were looking for. However, we also found, as an external factor, that people had difficulty holding onto multiple products at once while also using a touch screen. We discovered a potential gap in the in-store experience, if the screens were placed in a cluttered area with nowhere to set items down, customers would have trouble using the feature — leading to a frustrating experience with our product.
We often build feature flows based on the “happy path,” where everything goes as planned and everyone is able to complete each step with ease. But there are almost always edge cases where some of your users will fall through a gap. For example, users with business bank accounts at BMO can log onto the website in a special area to view their banking information. If they’ve forgotten their password, they can… call the bank.
This gap is twofold: Users today expect to simply reset their password online — BMO may have chosen to not allow this for security reasons. The second gap is for customers like my partner, who are hard of hearing. He’s unable to call to ask them to reset his password, and I can’t call on his behalf for security reasons.
When connections aren’t well-mapped out, features can have gaps that occur after their job is technically done. If I’ve gone down a path to find a product on a site, then login so I can purchase it, the login form should drop me off back where I was — not start me over at the home page. Now I’m solving my problem of acquiring this product from the beginning.
Feature planning should consider the circumstances that surround someone using it in the first place. This relates back to understanding context. If we identify the context in which a user needs a feature, we can better find gaps they may encounter using the feature or leaving it.
“There is no point in rendering the perfect nose when you have failed to place it accurately on the face.” —Kyle T Webster
If your plan for this feature doesn’t match up with the surrounding experience, it doesn’t matter how perfect it is, it’ll feel wrong. This quote makes a handy metaphor for this.
When your focus is on perfecting this one feature, it can be easy to lose sight of how it will live in and connect to the overall product landscape. Though your focus is on one feature, you should be aware of what happens around it. This is where your team can help.
We’ve all been in the situation where we’re stuck on something, and it isn’t until someone comes over and points out the obvious that we finally see it ourselves. Sometimes we’re too close to the problem. By having everyone on the team keeping an eye out for gaps, you’re less likely to miss them.
Because everyone brings a different perspective, simply by being a different person or by having a different discipline, they notice different things. They have a different frame of reference, experience, and they’ve also run into gaps in the past that you may never have thought of. Simply by being in business with someone who is hard of hearing, I’ve become infinitely more aware of accessibility issues everywhere.
Here are some ways you better identify gaps before users fall through them:
Are you running potential solutions by many people?
One solution can look 10 different ways to 10 different people. Present the solution — and the problem it aims to solve — to multiple people, from different backgrounds, to check for gaps. Other people also bring experience with other features to the table. They can picture how their work will connect with yours, and let you know ahead of time if things will line up.
Are you keeping track of gaps you know about, and the solutions for them?
Sometimes gaps can’t be immediately addressed — due to timelines, resources, or they’re simply out of your control. Keeping a list of them ensures that when the resources are there, people are aware of problems to be solved.
If you’ve found a gap that can be solved by someone else, make sure they’re aware of it. For the barcode scanner, we put in a recommendations document that space around the screens should be kept clear, so customers could set down products.
This leads me to the next checklist item…
Are you keeping track of gaps that come up often?
When you start keeping track of gaps related to different features, you’ll begin to notice overlaps. Accessibility gaps are a common example. If a company has trouble with accessibility in one area, it probably pops up a couple more times elsewhere. They can choose to address these in one clean sweep, or make an effort to address the feature-by-feature. The solutions to the gaps may also have overlap, and can be reused over time. This brings me to the next mindset …
Mindset 6: Use patterns.
Use patterns. When someone designs something like a coffee mug, soup bowl, or plate, they generally base each one off of an existing design. New designs reuse elements that already work and function as intended. The designer may customize to add unique elements, but just about every coffee mug can be tied back to the same basic design.
We all know how to use coffee mugs. As hard as it is to believe, at one point we didn’t. We learned and now it’s obvious.
In the world of software, users know how to use your app because they’ve used other apps. They understand the language “login” or “connect with Facebook.” They know how to navigate the interface (logo in top left, mobile menus are for some reason related to hamburgers, red circles mean something important needs my attention).
Each new dish-ware set you find in-stores is a riff on the original. There are major and minor changes, but the pattern exists for a reason. Each designer “pilfers” the original pattern for its functionality.
The same is done everyday in the world of software, apps, and websites. Every form I ever laid out is pilfered from forms that came before it. I take form field functionality from general sources — iOS or Android design guidelines — as well as specific ones — the new task form on the Things app — for various reasons. I do it for the sake of my users.
“To learn, you have to have something to grab onto. The next handhold can’t be too far from the last—you might never reach it… your brain instinctively steers away from gaps that are too small, or too large.” —Celeste Kidd, cognitive scientist at the University of Rochester
By reusing patterns, we provide users with a starting point they can do something with.
Gaps like this do exist, and sometimes users persevere. The first time I opened AutoCAD I couldn’t even draw a line.
Photoshop is similar, I know many people who have given up even trying to use the Adobe Creative Suite in favour of something lighter like Sketch because at least Sketch gives them a place to begin.
Users come to your product with a current knowledge point. To achieve what they aim to do they require a target knowledge point. The gap between the two will tell you how “intuitive” your product is.
To close that gap, you can either train the user to provide them with enough knowledge to slide them further down that scale, or you can move the target knowledge point in their direction. The smaller the gap, the more familiar the product will seem to users.
“People who use TurboTax are across the entire spectrum of people in the U.S. It’s not Uber and Airbnb where the design is meant to appeal to Silicon Valley people. This is trying to appeal to people in the Midwest who read USA Today and go to Target.com and Walmart.” —Kurt Walecki
What’s your users’ current knowledge point? If your users aren’t familiar with Facebook, basing your design off of their image upload service won’t necessarily create a narrow knowledge gap.
When you consider something like gmail’s Inbox app, your target knowledge point is different from someone like your dad, and even more so from someone like a grandparent.
(For the sake of comparison, let’s say you were making an interface that looked like IBM’s old punchcard computers. Now Grandma might have the advantage.)
But even across varying demographics, you’re going to come across overlaps in understanding.
Remember shared vocabularies? Patterns are a shared visual vocabulary.
People around the world speak a very similar language when it comes to interface design. As people use more apps, they build their vocabulary, and it shrinks the knowledge gap with each app they use. Just like when your team uses the same vocabulary to describe problems and solutions, when new apps use the same visual vocabulary, people are able to focus on the task at hand, not deciphering the interface.
When I first used Photoshop, I struggled with finding the tools within the software to do anything. I no longer consider it using Photoshop, instead I consider myself painting a picture.
Patterns aren’t just for the users. When we use patterns, we can more quickly and easily solve problems as a product team. The problems we aim to solve are often not new, and have been solved by someone else. By using or adapting their solution to our unique situation, we can save time and energy.
Patterns can also help to communicate the problem and/or solution. I was working on an app design that required a lot of functionality that already exists in the wild. To communicate how I wanted specific pieces to function, I compared them to existing patterns, “upload images like on Facebook,” or “handle project ownership like InVision.” Using existing functionality as a common reference point removes a lot of risk of miscommunication between team members.
How can you incorporate patterns into your development process?
Have we solved this problem before?
Problems are rarely completely unique. Even within your product, you’ll likely find overlap with many of the challenges you face day-to-day. When you’ve found a way to solve it once, don’t reinvent the wheel. It creates more work for your team, and it makes more work for your user.
Has anyone in our organization solved this problem before?
When we want to find gaps in a solution, we have to go outside of our own heads to gather other perspectives. The same goes for patterns, someone else in the company may have come across a similar challenge and has already solved this for you. The solution may not be transferrable 1:1, but the theory behind it is often adaptable.
Have other products solved this problem before?
Your users use other apps, and so should you. Be familiar with what they’re familiar with, and use it to solve your own challenges. If I’m designing a website for hotel booking, and I know my users are avid air-bnb-ers, I should be looking at how they handle accounts, booking, etc. In contrast, if my users are new to booking hotels online, I need to find patterns that they will be familiar with.
Do we have a pattern library?
Because we want to reuse patterns, we need to keep track of them. Keep an inventory of patterns you use so the next time you run into a new problem, you can more easily check if you’ve got the solution already. Common elements that you’ll find yourself reusing are form submission (sign up, login, content, contact), and error handling (for user or site errors).
Instead of reacting to each individual request as its own thing, each person finding a solution to each individual problem, great teams build great products when everyone on the product team owns the product.
The UX mindsets we covered today will help you move towards that ownership of the product:
- Know your users.
- Know your product’s job.
- Build a vocabulary.
- Understand context.
- Find the gaps.
- Use patterns.
Each of these mindsets will shape how you approach problems. They’ll add a new dimension to understanding the problem, and in turn help you create better solutions—and better products.
Nifty checklist cheatsheet:
Interested in chatting more about UX? Email me at email@example.com or get in touch through my strategy and design consultancy, Caribou!