Here at Punchkick Interactive we love working with experienced digital product teams as well as fledgling teams that are just getting started. In both cases, Punchkickers are adept at understanding where our clients are coming from and adjusting our language and approach to suit their needs.
Over the past 11 years we’ve worked with tons of amazing clients who all ask fantastic questions. Here’s the top 3 questions that come up when we have discussions about UX and UX research.
What’s the Difference Between UX and UI?
There’s a wide misconception that the terms user interface (UI) and user experience (UX) are synonyms and interchangeable. Before we go any further let’s take a look at the dictionary definitions of both terms.
The interface features through which users interact with the hardware and software of computers and other electronic devices.
The perception and response of a person toward design elements of software or digital media while interacting with it.
With these definitions in mind, one takeaway is the differentiation that’s made between something that’s tangible (UI) and something that’s intangible (UX). Where UI refers to visual elements that can be manipulated and controlled by a user, the term UX refers to the result of strategic decisions that were made around feature inclusion, the overall flow of events within a digital product, information architecture, copy, and the look and feel of the UI itself.
Here’s a non-digital example:
Think about eating a bowl of cereal. The bowl and the spoon are examples of UI, they’re the tools that facilitate interaction and consumption.Although the bowl and spoon contribute to it, the UX of eating a bowl of cereal also involves the way the that the cereal tastes and smells, how the cereal feels in your mouth, the rate at which the cereal becomes soggy, the mazes and other games that are printed on the box, how satisfied you are after eating it, etc., etc., etc.
Though the definition of UI provided above is adequate, albeit slightly reductive, the dictionary definition of UX is far too short sided and requires a bit more explanation. Here’s a much stronger definition of high-quality UX provided by Don Norman:
“The first requirement for an exemplary user experience is to meet the exact needs of the customer, without fuss or bother. Next comes simplicity and elegance that produce products that are a joy to own, a joy to use. High-quality user experience in a company’s offerings must be a seamless merging of the services of multiple disciplines, including engineering, marketing, graphical and industrial design, and interface design.”
The Norman definition of UX builds on the dictionary definition by including the way that a digital product fits into the larger ecosystem of user interactions with a brand.
Let’s use Starbucks as an example of how a digital product with great UX has the potential to positively augment the overall experience of user interactions with a brand. The popularity of Starbucks has led to a few problems in terms of the brand’s brick-and-mortar experience, namely longer lines and longer wait times. This was a big problem considering that the majority of Starbucks’ target audience members are people on the go, looking to get their coffee quickly before a commute, before their next meeting, or before the kids wake up.
In 2010 Starbucks addressed the long-wait-time-induced UX problem by introducing the first version of their mobile payment app.
The app works well and is aesthetically pleasing, but most importantly it effectively alleviates customer and brand-side pain-points. The wait time problem was alleviated by speeding up point-of-sale (POS) interactions through the use of a quickly accessible, and automatically reloadable payment barcode that can be opened through the app or added to users’ smartphone digital wallets and wearables for even faster transactions. The app also speeds up POS interactions by allowing users to pre-pay for orders that can be picked up without ever interacting with a cashier.
Behaviors are hard to change unless you give people a good reason to put the work in to do so.
Behaviors are hard to change unless you give people a good reason to put the work in to do so. Most likely taking that into account, Starbucks encouraged habitual use, while also increasing perceived customer value, by cyclically rewarding users with free java and treats every time a certain amount of purchases are made through the app.
As of 2016 the Starbucks app facilitated 1 million payments per month. Even if the app eliminates 3 seconds from each POS interaction it still saved about 30,000 hours of wait-time over the course of 1 year. Not to mention that, as of 2017, the app now accounts for around 30% Starbucks overall revenue.
Starbucks sells more coffee. Customers get their caffeine fix faster and they get rewarded for doing so. When effective UI and diligent UX meet, everybody wins.
- UI is what you see and touch
- UX is the result of everything that went into what you see and do
- UI is the tool that facilitates getting a job done
- UX is how and how well the tool gets a job done
- UX isn’t limited to what’s on a screen
- A digital product’s UX should complement the overall experience of interacting with a brand
What immediate suggestions do you have to improve our UX?
It’s always tempting to go after “low hanging fruit” in terms of applying design heuristic reviews and UX best practices to an existing product (it’s especially tempting when the product was created sans user research), but this is somewhat of a trick question.
If you’ve just been introduced to an existing product then the best answer is, “I don’t know. What do your analytics show? What have your users been saying?” Rather than immediately jumping to a solution, the most successful product teams begin with understanding and prioritizing the problems that users need help solving.
The most successful internal (read brandside) design teams spend hours, months, and possibly years engaging with their same user base. In these cases, “low hanging” UX fruit can be more quickly plucked and more confidently corrected. Teams evangelize a culture of research build a robust knowledge of who their users are, what their users need, and how the product fits into their users’ lives.
In the agency world, where teams are typically tasked to create custom and bespoke solutions, we don’t have that luxury. That’s why Punchkick always advocates for the following approach to research and design:
- Personas and generative research in the beginning of a project to understand our audience and unpack the problems they’re trying to solve.
- Design and usability research during production so we can audit our ideas and iteratively evolve UX before committing any code.
- Analytics implementation directly before launch so we can keep an eye on how people are actually using our products once they’re in the wild.
- Repeat item 1 if every few years. People have a tendency to change over time.
- Repeat item 1 if business goals change. New goals often mean new/different audience members.
- Repeat items 2 & 3 before new features are introduced and/or if a rebranding takes place. Even subtle color changes can have an effect on usability.
A key takeaway here is that even with years of experience and tons of talent, without engaging with your users beyond demographic market research, any suggestion that’s made is guesswork and conjecture. Rather than relying solely on instinct, teams should strive to develop a research-fueled product development culture that’s obsessed with learning about their customers. Future road map decisions should always be based on data-driven hypotheses and then tested with real users.
Creating amazing digital products isn’t for the faint of heart. It’s tough to throw away an idea that you love. It’s not always the case that the idea itself is bad, it’s most likely just not the right idea for that particular audience.
At the end of the day it doesn’t matter if you love the idea, what matters is whether or not your users love it. Although it doesn’t happen often there have been times when our team hates the design, our stakeholders hate the design, but our users adore it so we advocate for it.
- Offering UX suggestions before understanding user needs isn’t productive
- UX hypotheses should be based on research not just instinct
- Even when UX hypotheses are rooted in research, they still need to be tested with real users
- Just because you and your team like a design that doesn’t mean your users will too
We already have analytics, why do we need to do more UX research?
First of all, analytics data are fantastically useful. Understanding behavioral patterns, knowing exactly what users are doing within a digital product and how often they’re doing it is one of the only ways to measure success and failure when it comes to the KPIs that VP and C-level folks care about.
Although understanding what users are doing is important, analytics-based quantitative data are only a portion of a much longer and more complex story.
Real UX research should be wholistic. Small scale usability and generative research studies, which are primarily qualitative in nature, compliment quantitative research by providing rich, contextual insight as to why users do what they do.
In isolation, neither approach to research is a guaranteed panacea. But when combined, success becomes much more predictable.
Here’s an example:
Let’s say your analytics team notices that some specific feature is only utilized by a small portion of your users. Based on that finding they hypothesize that users are uninterested in the feature and recommend that it be eliminated in next update. Considering the data that were available, the decision to eliminate the unused feature makes sense. Why bloat a product with something that users don’t want?
Enter qualitative UX research.
Now let’s say a team that’s equipped with quant and qual researchers makes the same finding in their analytics data. Rather than eliminate the feature, and accept that their previous resource investment was wasted, they set up a small 7 person qualitative study with actual users just to make sure.
During the study the researcher asks about the feature in question and finds out that 5 of the 7 participants didn’t know it existed. Maybe they couldn’t find it because it was buried in a hamburger menu or nested under a topic that, according to their mental models, didn’t match with the feature’s purpose.
Now let’s imagine that those 5 participants were ecstatic that the newly discovered feature exists, and they all offer similar advice as to where the feature should live based on similarities in their lexicon or background.
Now we’ve got ourselves a real hypothesis:
H1: Moving [enter feature in question] to the [enter research-prescribed location] will result in an increase of user engagement with [enter feature in question]
Only analytics will tell if H1 is supported. Maybe users really do hate the feature. If so, then spending a few more dollars to make sure you don’t unnecessarily waste the initial $20,000 that went into it seems like a prudent move.
But maybe they don’t hate it. Maybe you were right and users just couldn’t find it. You just spent a few more dollars to preserve a $20,000 investment.
Knowing what happened is useful if you want prove success. Knowing why things happen is useful if you want to create success.
- Analytics research provides quantitative data (numbers/statistics) about what users do and how often they do it
- Interview research provides qualitative data (stories/quotes) about why users do what they do
- Real UX research is wholistic and should include both qual and quant data.
- Predicting the “what” is easier when you know the “why.”