Project details
My role
UX Design, UI Design
Context
At a company, working on a device that has AIML capabilities
Time period
October 2021
Feedback received from
Head of the company
Problem statement that I was working on
1. Create designs that'll help the user manage and proceed if there is an error on the appliance. Detailing what they need to do.
Some context to the problem
In the previous use of the appliance, the attached display didnt help with error. It was done via directly contacting the team. This was while the device was in its Alpha trials.
Currently for beta trials, the device's display was to have information about errors as well.
There was already a document explaining what were the common errors that people had previously faced
Two types of Errors
There were to be two type of errors, one that was actionable since it could be fixed by the user (with minimal effort)
and second type which informs the user, that the appliance will not be usable for now and that they will have to wait it out
Initial flows
Basic flow detailed out
Type 1 error : Where the user can take action
Showing that their action either worked and the error is resolved (case on the left)
Or the case on the right (Didnt work)
Type 2 : Where the error cant be solved
Low fi wireframes
Some text has been left blank / made Lorem Ipsum for confidentiality purpose
First flow is for error type 1 : That can be resolved with action.
This version shows a successful case
Second flow is for error type 1 : That can be resolved with action.
This version shows an unsuccessful case
Third flow shows type 2 error. This cannot be resolved with action.,
User can attempt to resume action.
Unsuccessful version is show here
When the user is on some other part of the app., they would still have to be notified if there is an error on what is supposed to be happening now. This sort of a minimized screen with an actionable button, would help them navigate to the right screen so they can take action.

This screen was to be common between both types of errors
Feedback received
The feedback I received for the above designs were that

1. Status needs to be shown separately
2. The possible actions need to be separately
3. Don't distinguish between them as error 1 and error 2, from a user's point of view : all are errors that need to be dealt with. The separate errors were explained that way, for just an understanding perspective.

Implementing feedback + Inspiration
I was browsing for inspiration and found it interesting how Swiggy etc. show the genie delivery status and how it moves forward 

While this wasn't an order delivery but rather a machine showing the progress of its work, the idea of a record could be interesting.
My work supervisor approved of the idea, so I went ahead with it
Task flow
I understood that what I made previously, were flows for me to make screens (or almost tasks for me)

Whereas for a user, it is that
1. she is going to see a certain error
2. Take action for it as indicated
3. If it works, great. If not, then wait for support team.

Updated wireframes
In the frames below, I separate out
1. The action the machine was performing when the error occurred
2. What the error message is
3. What action the user has to take
4. Section where they've to press resume once the recipes are done
While the above screens required multi-step action from the user; the screens below require the user to just resume the recipe.
However the structure of information has been kept the similar (except for the lack of user action card).
Moving to visual designs
These are the colours that are part of the application
Below are the text styles
On the basis of the above, we have high fidelity screens
High-fidelity screens
High fidelity screens for errors with multi-step user action
High fidelity screens for errors with single step user action
Reflection
Have worked on other flows, but mentioning the device that does this, would give away information. Do get in touch with me, if you're interested in finding out more.

You may also like

Back to Top