There are many UX case studies on the web with a description of user and market research, prototyping and testing. They are nice for a porfolio because clearly demonstrate a work process. But if they were to implement, a designer must do a big job describing all prototypes and layouts, explaining how must work all the unobvious and invisible things. What happens if the server crashes, what mistakes are possible and what to do with it, does an input has some restrictions, what happens if there are too many objects and etc.? If you design for a software there are more. For example, where a dialog window opens or how a keyboard control works. Developers can’t understand these things only from the prototypes and if you didn’t describe that, hope that developers would ask about it (usually, they don’t). Furthermore, it’s hard to test these things before the implementation, so you couldn’t understand something is missing. And let’s be honest, not all the designers have an opportunity to test an implemented product. So today I want to talk about the hidden things that designers have to consider in a product specification.
Feedback on user action
The first one is simple, but important. Don Norman and Jakob Nielsen often talk about it.
Feedback is about sending back information about what action has been done and what has been accomplished, allowing the person to continue with the activity. — Don Norman
If a user can interact with something, there must be a feedback. Always think about all possible interaction. For example, you made a form with a save button. What happens if a user clicks on it? The form disappears, the button disables, the confirmation appears and if so, what confirmation? Or you decided to save an information in the form without any button. How user would know about it? Even if nothing happens, you should write about it. It isn`t obvious, because there are several options possible. And if a user mistakes what should a system do, does it save such information?
Oh, and don’t forget about loader, if the immediate reaction isn’t possible.
Always think about what happens if there are many objects. For example, you designed a table that a user can fill. What happens if there will be 1 000 lines? Do you need a pagination, a search, filters? Consider also, that it’s impossible to immediately filter enormous tables.
Or you design a document oriented application. What happens if a user decides to open too many documents, that either take a lot of time or crash the system. How the system should react? To warn a user, to forbid to open such quantity, to start opening and give an opportunity to cancel it?
Or you have tabs in your app, that opened by a user. What happens if he opens so many, there are no longer place for them? I hope, you get it.
Also consider situations where there might be no objects at all. For example, you design an adjustable table, where user can choose what column he wants to see. Consider that, possibly, you don’t want user to hide all the columns, because it doesn’t make any sense. What is the interaction then? Also, don’t forget about possible empty states.
What happens if a user makes a mistake, when you validate it? For the input for an e-mail it’s quite easy. But what if a mistake happens in a table cell?
For example, in an application, that I worked on, users had to fill in the information about the work they are doing. They had to add some devices they were using in the work. The problem is that the devices had to be checked before the work had started and this information had to be in the app. If a device is not checked before the work it was impossible to use it properly. Maybe, someone just forgot to enter the test date in the app, or maybe there wasn’t any test. So we have to consider that and warn users if a device doesn’t have an appropriate test date.
All error messages have to clearly state a problem and, if possible, suggest a solution. And not only error messages but every dialog has to be appropriate. Consider working on a text copy that appears in your interface. This part sometimes hard to do without a developer, he sees better all possible mistakes. So work together, in a team.
Consider an interaction with your input. For example, time input. Is it a dropdown with possible variations, a spinner, does it allow a keyboard input and if so, how it works? For simple solutions that someone is already implemented it is enough to show an analogue. For unique cases write a description. For example, I had to develop a degree input for some applications.
Be aware of a tech side and be specific. You made a layout, now think about how exactly it must work from the inside. Sometimes, it is you who have to care about it. Sometimes all your brilliant modern ideas just impossible to implement. Be aware of the technical possibilities and be specific. For example, you made a “popular” section on an online store app. What products are popular? Are they selected manualy, or they are most viewed, most commented?
Or another example. It’s not enough to write in a specification “when the cursor is near the graph, coordinates are appearing [somewhere]”. A designer must specify, what coordinates. It might be cursor coordinates, coordinates of the nearest point or interpolated value.
Keyboard control and gestures
If you design a desktop app, be aware of a keyboard control. Experienced users often use it. It’s not only about forms, this one is more a less automatic. Sometimes users need hot keys to quickly operate an app. For modal windows specify a default button or its absence. Also think if you need to specify any gestures. Even for a mouse there are options: click on right or left buttons, click with movement (or drag&drop), scrolling or clicking the mouse wheel, click with a hotkey. For mobiles and touchpad — much more.
Think of a behavior of linked objects. If a user delete or modify one, how does related objects behave?
Always think about “what if” situations. Write good specifications, but don’t be mad about it. Sometimes the best solution is to allow users to do stupid things and to get stupid answers.
UX design of hidden things. A part of interaction that isn’t seen on prototypes and layouts. was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.