There are many 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 and , 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 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 things that designers have to consider in a product specification.

An example of the regarding the business-logic. All data is replaced by a fictitious.

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?

What exactly happens when a user presses save button?

Oh, and don’t forget about loader, if the immediate reaction isn’t possible.

Expandable design

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.

If a table can grow, consider an interaction with many objects. Do you need a pagination, a search, filters?

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.

An example of a button that appears when there is no more space for tabs

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.

An example of an adjustable table


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?

A mistake that happens in a table

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.

Text copy

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 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.

Tech side

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.

What coordinates to show: cursor coordinates, coordinates of the nearest point or interpolated graph 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.

Be aware of gestures and a keyboard control


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.

Source link


Please enter your comment!
Please enter your name here