UX and product design have become relatively interchangeable today as there’s undoubtedly plenty of overlap between the two. That said, last week, I recognized a key difference between them and how it affects the way we approach a problem.
The Interaction Design Foundation defines users experience design as:
The process design teams use to create products that provide meaningful and relevant experiences to users. This involves the design of the entire process of acquiring and integrating the product, including aspects of branding, design, usability, and function.
Under this definition, UX design can apply to everything from a simple corporate website to complex web apps or SaaS products.
Product design, in my experience, tends to be hyper-focused on individual features or functionalities of the product that users will interact with. In other words, we could define a holistic user experience across all parts of the product, but strictly speaking, product designers will be focusing their efforts on one specific slice of that larger experience at a time.
Last week I was doing this very thing - prototyping an onboarding experience for one part of a larger product. The goal was to reduce the friction and overall time spent completing this onboarding process.
Along the way, I noticed several design and interaction patterns that I felt could benefit from minor tweaks. As the experience came together, I thought I was on a roll and was convinced that I had come up with a better way to handle numerous elements of the interface. Soon enough, my prototype began to look and behave quite differently from other areas of the product. It went something like this:
The client team I was working with was excited. They loved the newly proposed patterns I was bringing forward, and everyone agreed that I “was onto something.” Great, right?
I was feeling confident and optimistic about my prototype bringing it into Product Design Forum. This is an internal working group that reviewed product features and enhancements made up of product managers, engineers, designers, and senior leadership.
It didn’t go so well. And here’s why: my prototype was attempting to solve too many problems. In fact, many of the UI elements I had reimagined in my prototype weren’t even problems at all.
In the context of my own prototype, it was easy for me to make suggestions about how a specific pattern could be improved, or, for example, how introducing icons or illustrations would make the experience more accessible.
But that’s not what this project was about. It was merely to make the onboarding process simpler and faster. All of the other suggestions I had brought forward with the prototype, even if they were valid ideas, weren’t directly addressing this core problem.
As product designers, asking ourselves, “What problem are we trying to solve?” is about more than just setting objectives. It forces us to dig deep and truly appreciate where our efforts should be focused. Drop the ego. Don't set out to be the hero that will "fix" everything just because you feel they should be doe differently. When we do this, we spend our energy in the right places. We make it much easier to achieve buy-in from stakeholders and - most importantly - deliver the most meaningful solutions to the end-user.
Steve Coppola is a user experience & digital marketing professional - and founder of Input UX. With over 25 years of agency experience, he has worked with many of the world's most respected brands in various capacities including UI/UX design, customer research, usability testing, and front end development.
Find out more about Input UX
If you’re developing a new product, app, or software, then you’re probably familiar with prototyping - building out and creating a visual and interactive representation of what you’re going to build. While design teams, developers, and marketers will love the nitty-gritty of a product’s design, before you even get that far, there's another step you need to take - visiontyping.
The largest, most talented and well-funded product teams don’t amount to much unless the work they do is informed and directed by input from users of the product themselves.