User Experience (UX) is a term that is misunderstood too many times. It’s okay, because UX is a new term, easily turned into a hype. However, UX is not new. It has already existed since the earliest of human civilization. For instance, the UX of cooking our food 2000 years ago is different from the UX of cooking our food today. Consequently, the way we look at UX should be independent of technology. Compare firewood and microwave oven, for instance. They are actually the same products, but they are different because of the underlying technology. The users are the same (people who cook) and have the same goal (getting their food cooked).
How to change our mindset of looking at everyday products and identify what makes better UX despite the use of advanced technology? I write this based on conversations with developers/engineers. If you are a product designer, probably this is not new, but it might help you understand that users and developers/engineers are the two important stakeholders that need to be considered in your design process.
1. Who
The core of UX is the Who of UX, which is clear: the users. Without users, there is no UX, but too many people talk about UX of a product while forgetting the users. Make sure that you clearly understand who the users are, not to confuse between users and other stakeholders. If you are asked to improve a product, go straight away to users. Find out from them. You don’t have to be a psychologist or specially trained user researcher to do this. For example, as a mobile programmer you can simply ask your mother to use the app you developed and watch her use it. Empathize with her. Do not judge her as “gaptek”.
2. Why
When we get to users, we start with Why. Some UX practitioners relate this attitude to Simon Sinek’s golden circle concept as is also in his best-selling book “Start with Why”. When you watch a user interact with your product, take a note. Observe. Their behavior will surprise you. You are there to listen, not to command. Instead of saying “I’ve told you that’s not the right menu item, why you kept choosing that item for this task?”, find out why the user keeps choosing that menu item. Ask why they behave such and such. The answers will also surprise you. Keep the surprises in mind, as they will be useful insights when you define the problem.
3. Context
It’s true that all users are human beings, but users are differentiated by contexts. For instance, you’re building an internship job website for college students. This statement alone can already define the user (college students) and the supported activity (finding internship jobs). Two contextual questions remain: What is the level of support? What is the form of solution? You can easily answer that the level of support required is searching and applying for jobs, and the form of solution needed is a website with free registration. By identifying further into the context, you can detail the level of support: whether college students are familiar with company names, whether they know which jobs suit their education background, etc. You can also detail the form of solution: whether they need a mobile site or not.
4. Problems, before Solutions
Do not jump right away into the solution, if you haven’t found the problem yet. Do not say “we need to improve the interface” without understanding how users use your interface. Maybe the interface does not need any improvement. Maybe the problem lies in a small engineering defect. For example, a product has a very good User Interface (UI) with understandable buttons, but the problem lies in the process triggered by a pressed button. And what if there is really no problem, but you think the user satisfaction can be improved? Start with Why again.
5. Solutions, before Tools
Do not list a number of tools, before you understand how to solve the problem. Do not say “we need to implement adaptive layout” without finding out why it was needed in the first place. For example, we can consult standard documents from an established organization such as ISO JTC1/SC 35 or discuss in an open forum such as @StackUX about UI standards. By making sure that the interface meets the standards, we can look further in order to identify the best solution. For example, your users complain about the mobile interface of your website. You may be surprised to find out that the best solution (for example, in this case) is only to remove pop-up windows instead of wasting time implementing adaptive layout.
While user-centered design philosophy keeps reminding us to involve the users early, let me point out that it’s also very important to involve the developers/engineers early. They are the key to the basic building blocks of a product: without them there will be no product at all! As a developer/engineer, it pays to really think about the Who, Why, Context, and Problems-Solutions-Tools. We don’t want to push new technology into products, but instead we want to utilize familiar technology into products with a new experience.
PS: Let engineers stay engineers, because they’re expert in engineering. Don’t change their name into UX Developer.
Qonita Shahab, a researcher in UX who previously worked in IT. She’s been writing about UX here hoping to see better products and services in Indonesia. Together with two friends, she runs facebook.com/MohonRevisi for increasing the awareness of good UX in Indonesia. For more UX stuffs, follow her on Twitter @uxqonita.
