[UX] How to solve the problem as a UX designer
I have encountered situations to solve problems that didn’t seem like UX problems. Furthermore, the directions were sometimes wrong to UX, and I struggled to explain what it was wrong. I want to introduce how I approach situations after many trials and errors.
1. Prologue
When we talked about solving the problem in the project as a UX designer, that was not always clear or simple for me. The big question in my mind was,
‘How come the process of solving the problem is not not simple as a UX designer?’
I wanted to think about the reason for this, and thought about how I can approach the process clearer.
2. What is the UX problem?
We may encounter problems not really related to the UX in the project.
For example, let’s think about a mission to increase the user traffic or more income from the product. Is this a UX problem or not?
When we are pushed into the situation, there may not be a way out from that kind of mission.
Nevertheless, we may have to design the product to the goal whatever users expect of the product.
2.1. Case: Booking ferry
When I booked the ferry one day, I found out a weird case. My task was pretty clear to just make a reservation for the ferry.
When I took a look at the steps, there were a lot of things to do like choosing round trip or one-way trip, departure and destination, the number of vehicles, type of vehicle, the number of passengers, date of the trip, and so on.
After all the steps, I thought I finally met the last one on this page, and later I noticed something weird.
I didn’t pay attention to clicking the button, “NEXT: xxxxx”, to move to the next page, and I noticed that was not what I wanted to see.
It shows me the booking page for hotels even if that was not my task. Furthermore, I barely found a small-size text, “Back”, to go back to the previous one under the booking page for hotels.
In this case, the UX designer may achieve the mission to increase the traffic in the hotel booking page, and they may believe the data is obviously supporting their success.
By the way, can we really think this is user-friendly and user-centric design because the data shows obviously more traffic that users entered the hotel booking page?
3. Approach to solve the problem
I wanted to define how I usually approached the problems, and I distinguished some cases by the condition.
Grey conditional processes in the flowchart are the critical processes that I think of as above.
3.1. Check the type of problem
Firstly, I make sure what the UX problem is in the project. I know the case for booking a ferry is not a UX problem, but that can be the problems in the business that I have to solve or trade off the design of the product in the project.
This demonstrates one of the major flows in the chart.
Recognizing the type of problem is very important to me because it shows me the direction when I look for the solution of the problem.
2. Additional feature, Audio book, of Minerva for a business problem
This is an example which I define it is not a UX problem when I designed the product, Minerva, which is an anonymous online debating product.
When I designed the product, I was asked to achieve a mission to increase the traffic because the main business model of the product was an advertisement, so the the traffic could be the one of critical success factors for the business.
The structure of the product is a kind of bulletin, so users can participate in debating based on reading and writing in the image as above.
However, the interface for reading and writing is pretty effective and friendly to show their opinions in debating, but this may have had the limitation that they only enjoy the content during eyes-free or hands-free time.
I discussed the problem with co-workers and decided to add another feature to enjoy the contents by listening as well.
For this, we decided to add audio book contents to read the comment thread that was going on by others while they were not participating in.
The feature was not only making traffic, but it would also give users more accessibility to catch up the history of the debate that they missed during other free time like exercising or commuting.
When I considered the feature, one of the most important thing was how this feature could impact the user task because I knew there would be the worst case like in the booking ferry case study as above.
In this example, users could still enjoy the content by text, and I clarified the audio book feature is additional in the product, so I designed new pages for the features and applied them in the product without concern.
3.2. Distinguish the type of solution
Secondly, if the problem is related to UX problems, I distinguish between the solution with UI design aspect and solution with any further features or specifications.
If I can solve the problem with just UI design, I may not need to consult the solution with other co-workers unless I suggest impossibly hard alternatives.
In this case, I generally need to estimate which alternative is better than the others by design principles and guidelines.
This is an example which I define it is UX problem capable of solution by UI design aspect when I designed the sign-in page for Minerva.
I considered how I consisted of the credentials input components in the page and how I defined the behavior of the components for the interaction with users.
I came up with two different typical alternatives for the page after benchmarking, and estimated them, and then decided one of them for the page finally.
2. Alternative b for Sign in
I picked the left one in the above image after the consideration because the alternative had more advantages of the validation expression, ease of development without dynamic layout consideration for the validation, and security.
if the problem is related to UX problems, I distinguish between the solution with UI design aspect and solution with any further features or specifications.
Thirdly, if the problem is related to UX problems and I can’t solve the problem with just UI design aspect, that means I may not need to think about something else like features or specifications aspect as well.
When I designed the sign in page for Minerva, I had to consider the security issue to block the suspicious sign-in trials.
Even if users can enjoy the product with anonymity, but we should still think about keeping the users’ data safe.
I communicated with co-workers for the problem, and we decided to adapt the further process and policy.
2. Alternative b, blocking the trials, for security
As you can see above, we could suggest alternatives, CAPTCHA and blocking the trial for a short time.
I estimated which one would be better for UX in the example. I knew blocking trials might be stronger than the other one for security.
However, I chose the alternative, CAPTCHA, for that because I knew too much strong security policy might be more frustrating to users as well.
In addition, the product basically guaranteed anonymity in use at least, so I could decide to choose that for the requirement.
That is not a decision making for design aspect so much, but it is pretty considerable for user’s aspect. UX problem can’t be explained by just UI design aspect, so I want to introduce the example as well.
4. Epilogue
When I tried to solve the problem in a project as a UX designer, I understood there are many people who have different ideas.
That’s why we should share the ideas and talk about where we are not in the process to solve the problem.
I am sure that leads us to the reasonable direction, and makes people have consensus about the problem solving process.
I believe It is the most important thing when we approach the problem together in the project.
댓글
댓글 쓰기