A story about UX scenario
How I designed the scenario for Wheeshing App
Andrea Mecenero is a freelance UI designer.
Appendix: I’m telling a new story for you. This is connected with one of my case study. You can see here.
Introduction
A long time ago, human beings invented the wheel. We didn’t know precisely when this happened, but we know how useful it is today. Nowadays, every type of transport uses this tool, and sometimes it breaks. And here starts my job!
Some time ago, I began to work on a new mobile App associated with wheels. A company asked me to process an idea and to build it. I met the client, a funny guy middle-age, marketing manager of a tyre company who had an idea in his mind. We set a brainstorming for the same day. We sat around a table with a team of Devs, and he started to present it. Oh, he also brought a few devices from his company, and he explained better all the parts.
During this presentation, we asked questions, doubts, and benefits of his idea. I can say now, this exchange of opinions helped me to understand better how to design, drawing, and subsequently, how to test the App. I sketched on the blackboard a few basic examples of wireframes, to focus better on the features.
The day after with the team of Devs, we started to work on a daily basis with the client, following a scrum methodology. My first assignment was to write down the whole process and sketching a quick wireframe on the paper. By the way, visual after visual, I started to work on the scenario, and in the end, I was able to have a first low fidelity prototype, with simple interactions among the steps.
So, how this scenario was built?
Following the usability test, I tried to identify the main problems related to usability in every single screen. I embodied myself in different types of personas, and I thought which answers I could have formulated while I was using my prototype.
One type of persona? A middle-aged mechanic from a small car garage who fixes the car’s tyres and use some tech every day for his job but also at home.
Part One. So, the first point was the setup of the App. After the splash screen, I found my hypothetical user in front of the registration — nowadays, most of the Internauts subscribe on registration forms thousands of times — it’s a simple process. However, tasks must be described as easy as possible and follow the standards. The screen must be clear and well readable, and another point is to give a fast answer to every problem.
After the usability test, one of these solutions was offering the possibility to log-in by using a social media account or connecting the account with a Google Gmail.
Part two. After registration, you should bypass the log-in step, but how could I test it during my scenario? I simulated that the user had a second phone for his job, and in that case, he should log-in from it. Simple steps the user should correctly interpreting among the available options.
After this, the dashboard is the next challenge. The problem to solve here was how the mechanic should correctly interpret and differentiate elements. The panel presented all the information available.
After the usability test, one of the solutions was showing more pieces of information on the screen, for example, the date of sending notification.
Part Three. Let’s think a new client brought a car to the shop. He or she had to find all the answers quickly and complete the process of registering a new vehicle. The task was to find a way to scan a QR-code generated by a tester, go through the process, subsequently scanning the car’s plate, and get the information from the vehicle.
In a few seconds, all data was processed and presented on the screen with all the test outcomes. How was the quality of the tyres?
After the usability test, one of the solutions was giving an extra choice (e.g. WIN number) if the car didn’t have a registration number or there wasn’t a database in a specific country.
Part four. The tester gave a bad result for the tyres. In this case, the App had to suggest automatically three different tyres divided by the best suited, the most performance, and the cheapest. The mechanic could accept them or should select others suited for the car.
The user on this screen should be able to understand the information about the tyre and the data presented.
After the usability test, one of the solutions was showing visually with colors or icons, which parameters were in the norm and which were incorrect.
Part five. Nevertheless, let’s assume the mechanic wanted a tyre not available in the catalog, so there was a lack of the desired tyres. In such cases, the user had to navigate through the screens, found out where was located this option.
After the usability test, one of the solutions was empathizing more the buttons because some users thought there wasn’t this option available.
Part six. At this point, in our scenario, the user prepared his quotation, and he or she sent it to the client but unfortunately declined.
The task was to find and check whether the mechanic can recognize if the client rejected the agreement for repair terms. What is more, the user should validate the readability of the presented screen and the understanding of the displayed data.
After the usability test, one of the solutions was adding additional information about the problem, whether this defect can cause further flaws.
Part seven. We’re at the end. After using all the features of the App, the mechanic should find a section where he or she can edit his or her data. The final task was to log out of the application.
After the usability test, one of the solutions was removing the edit button and edit the contents immediately.
In the end, I used this scenario for leading a detailed interview connected with the performance of tasks on the application to several mechanics — the representative of a given target group of users — around Europe.