0

I'm working on a mobile application to help technician to make inspections. They have a lot of question for each task, each question is about an item inspection. When the answer is positive no additional action is required (80% of cases).

enter image description here

But when the answer is No, he has to identify the anomaly so I show a new page with anomaly choice. I choose to represent it as a cards because it needs to have an "on" and "off" statut.

enter image description here

When the technician chose one anomaly it show a new screen because we need some additional informations, my problem appears here. I can not create a classic stepper because the number and type of question will depend of the answers :

  1. First he need to answer if he "fixed", "momentarily fixed" or "can not fix for the moment" the anomaly.
  2. If the technician answer "fixed" or "momentarily fixed" we ask him to let a comment, to explain how he managed that
  3. If the technician answer "can not fix for the moment" we have two additional questions : we have to identify the reason of this failure (choice in a list of 6 items) and the estimated repair time (choice in a list of 2 items)

I don't know how to represent this userflow, this is my headache, but at the end the user need to come back to the anomaly screen, because he can add another anomaly with the same flow..

enter image description here

Thanks for your help !

0

You can change the "x" icon at the top to a "< Back" button. The title can become static, like "Describe Anomaly" and "Anomaly of Third Item" can be moved down to the main content area as a subtitle.

Each level that the technician drills into can slide out with a bottom Save and top "< Back" button returning the user to the previous screen.

  • I'm agree with that, thanks Stacy, but it's not helping me with my issue, how structure the user flow for the responses about the failure. It's a serie of questions with different amount of steps (it depends of the first answer). – Woj Sep 3 at 19:38
  • It sounds like the status ("fixed"/ "momentarily fixed") needs to be separated from a description of the issue; if an item is not working, it's not fixed yet. Maybe the workflow above allows the technician to report items that are not working, and add diagnostic info. Later, on a separate screen, s/he can see the items that need to be resolved, and add if they're resolved (and how that was done.) – Stacy H Sep 3 at 19:59
  • Thanks again Stacy, I will make some test 🙏🏻 – Woj Sep 3 at 20:13
0

There are a number of requirements I'd make sure I would nail down. I have built UI's almost exactly like this for material inspection and process control.

Here are some key CTQs for a UI like this:

  1. Absolutely critical that you minimize 'UI friction' like extra clicks and selections, as this is probably an activity that gets done many times per day, and an extra click or swipe gets really old after you've done it 100 times in an hour.

  2. Context matters. The user may be interrupted, or otherwise lose attention. So any page they are on should have enough context for them to understand what they are working on and what property they are commenting on, etc.

  3. It should not be easy to make errors, and errors should be correctable at least until the entire form is submitted. That goes back to the last item - if you don't provide enough context on the page, the user may enter data for the wrong item, which could be disastrous in manufacturing. Make sure the user is protected from input error, or given an easy way to review or cancel any action.

To that end, have you tried a simple expander under the item? If the user clicks 'No' for not working, expand the section under the question to allow them to answer further questions and enter a comment. Then they just scroll to the next question. At the end, before submitting they could then just review what they've done by scrolling through the list instead of jumping back and forth between different pages. And also, the answers will always be directly under the questions and in context. If you need them to save every time they do an item, you could put the save button in the expander, and when it's clicked leave the answers there, but greyed out to be clear they can no longer be modified. Or if it's absolutely unnecessary for the user to see that information any more after hitting 'save', collapse the expander after saving, and mark the item as finished and grey out the yes/no buttons.

As a general principle, the answer to a question like this depends VERY MUCH on understanding how the user is using this user interface. How often, in what environment, under what constraints. For example, how often does the user actually select NO? If it's rare, and extra field entry is not common, then that will imply a different design than if yes/no is 50/50, or 80/20.

Also, how often is this used? If it's a quality engineer working this UI all day on samples from an assembly line the requirements may be different than if the UI is used by an inspector once a week for an hour or two. Are they wearing gloves? Eye protection? That will have an impact on font sizes, button sizes, etc.

There are very few UIs that can be properly designed without a detailed understanding of how the user will use it and what their goals are.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.