Choices for users who don't read

Question

I'm building a touch UI for a timesheet program.

Requirements:

1) Record the start and end time of a break.

2) Determine if the user is leaving the work place for their break (for safety reasons we can get an accurate count of who is on site at any time).

3) Make it visual enough for the choices to be inferred (not all employees are able to read)

This is what I have:

enter image description here

That's too much text to satisfy the 3rd requirement. What visual queues could help in this situation?

Are the potential users you're concerned about in #3 low literacy or completely illiterate? — Roddy of the Frozen Peas, Apr 10 '13 at 19:35
Good luck! Years ago we considered something like this for farm workers, and I was introduced to the difficulty by one of our farm unit managers showing me a timeclock punch card with a red lipstick kiss mark on it. The lady couldn't write her name, so she kissed her punch card to know it was hers. — thursdaysgeek, Apr 10 '13 at 22:55

Charles Wesley · Answer 1 · 2013-04-10T19:23:02.743

7

Try to create visual distinction between the choices so it's clear to the user that all of the options aren't the same:

mockup

^{download bmml source – Wireframes created with Balsamiq Mockups}

By making the buttons easily distinguishable, those who do not read will know which button they want with less mental effort.

By giving them a big target to click, the user can quickly select the correct option without exerting fine control over their mouse (desktop) or finger tip (touch screen). This allows for faster time to completion for the task at hand.

edited Apr 10 '13 at 19:23

answered Apr 10 '13 at 19:17

Charles Wesley

12,218
9
48
74

3

I know you know this, but just as a general parental guidance disclaimer: be careful with those icons, a user may not be aware they are usually for "download" and "share". – Koen Lageveen Apr 10 '13 at 19:49
@KoenLageveen Very good general rule. The options available in Balsamiq are limited in that regard, and one could use generic arrows perhaps pointing down and right to communicate the same intent. The specifics of implementation are going to be contextual to the rest of the app, so there may be existing conventions in use that would apply here. The main take away from my answer should be visual distinction between choices beyond the language used in labels. – Charles Wesley Apr 10 '13 at 20:13

score 3 · Accepted Answer · answered Apr 10 '13 at 19:46

Why do you use a modal dialog if there are only two options? Is that triggered by the "Start break" button? I'd suggest smoothing that out like this (get a designer to make some proper icons for you though, only so much you can do in a mockup).

mockup

^{download bmml source – Wireframes created with Balsamiq Mockups}

score 0 · Answer 3 · answered Feb 24 '16 at 23:57

As others mentioned, work more visually. Use colors and different icons to clearly distinguish the buttons. But think beyond regular icons and more towards ideograms and pictograms; visual representations of actual things (☂ ♿ ⛟) rather than purely abstract symbols (☣ ☥ ☤ ).

Here's a very sloppy quickk idea:

Choices for users who don't read

3 Answers3