Long time ago, we heard a statement: UX is not UI. There’s a website dedicated for that. It elicited different reactions by people who claimed themselves “UX Designers”. Those who learned about users in their work promoted the statement for validating that their work was really UX. They didn’t want to be put in the same box as those who directly created artifacts based on assumptions about humans.
I used to use the same statement, too, but not making UX and UI mutually exclusive. UX is not an element, because it’s a relationship between two elements. The elements are users (human) and UI (artifact), right? In the following diagram, the two arrows are UX. Thus, UX is not UI applies here.
- Top arrow: how we design the UI (to meet user goals, e.g. I use the mobile app to order a pizza)
- Bottom arrow: how the users interact with the UI (usability)
I understood UX that way, because I was a product designer. When I heard the definition of UX by Don Norman for the first time (through my mentors), what came to my mind was the following:
Most of the time, I had to work on the UI of the product I designed. They weren’t software or websites, but tangible technology products where users had to use multiple body parts to use it. That is how I got to understand the difference between the UX of Product and the UX of UI.
What is the UX of a product?
- Top arrow: how we come up with a product (to meet user needs, e.g. I need the mobile app because ordering pizzas over the phone takes too long)
- Bottom arrow: how the users evaluate the product (utility)
Now combine that with the UX of UI. You’ll get a complete picture.
UX has always been about the Why.
As I got into business, I could no longer separate product and service. In a business (not necessarily for-profit), a good product is always complemented by a good service. For a good UX, service needs to be designed, too.
When I got into management, I had to interact with multiple teams and started seeing multiple products and services. Eventually, the business entity (the organization) came into the picture of UX.
That diagram alone isn’t clear enough for explaining UX to everyone in an organization, especially if they’re not designers, engineers, or Product team. It’s rather easy to explain it to HR or People Ops team and Customer Service team, because they already operate using human (not system) perspectives. Marketing team is the toughest, because they have existing performance metrics.
I was told by some Marketing people that “UI” in that diagram is misplaced. They thought, it should be “UX”. However, explaining with UX is not UI doesn’t work for Marketing, because they cannot relate it to their metrics. So we need to start with their favorite word: customer.
- Top arrow: how we market the products (to meet customer’s interest)
- Bottom arrow: how the customers evaluate the products & services (value)
To have a better discussion, use their jargons like acquisition, conversion, and retention. While acquisition is solely Marketing team’s responsibility, conversion and retention are the responsibility of everyone working on the products/services, which subsequently influence acquisition, too.
CX is one big beast to handle by taking care of:
- acquisition (how we attract people to visit the organization for its products and services)
- conversion (how we convert visitors to customers — to buy the product or use the service)
- retention (how we encourage customers to come back for another/more products or services)
While UX alone influences conversion and retention.
Let’s put aside CX and come back to UX! Is there a way to rotate the visual, so we can see UX in an organization? Since I’m a product designer, I can visualize multiple UIs inside a product. The diagram below shows multiple products/services in an organization.
Take the example of a hotel booking service. Customers come to use it because of their need of staying in an affordable hotel during vacation with family members. They come to use the 1st UI, to meet their goal of booking the right room (location, room type, price, etc). After booking, they get the proof of booking from the 2nd UI, which is an email. Close to the date of vacation, they get a reminder of their travel from the 3rd UI, which is a mobile app notification. After the hotel stay, they get an invitation to review the hotel from the 4th UI, which is an email and link to a review form.
If customers are happy with the value of the service (“I was able to find a hotel that I needed easily and it was the right quality of hotel as you informed me”), they will come back for another! Maybe, next time they will have another need: to find a hotel room in the middle of nowhere because of getting tired after a long drive.
There, we just discussed a customer’s story! Considering UX in our work means we talk to people, and listen to their stories in order to understand before designing.
If you’re a UI designer and someone tells you UX is not UI, you can proudly tell them “I’m designing UI by listening to human stories, so there’s no way UX is not part of my work.”
PS: for acronyms and skills, go to How I Explain UX (1): with Plain English
If you want to read more about Design, Innovation, and Human Behavior please follow Design Strat instead of qonita’s profile :)