Well-considered mock-ups or how to foresee a barrage of questions coming from workgroup members

You have already sent your fancy mock-ups to a development team and cannot wait to see them go into production, but developers and QA engineers keep writing to hammer out more and more details. Does it sound familiar to you? Throughout this article, you will learn how to take a deeper approach to designs as well as resolve these type of issues before they arise. Later on, I’m going to share a checklist that will be useful for mobile app designers and help verify their mock-ups before submitting them to a development team.

Screen statuses

When creating concepts, we don’t often take into account the fact that something can go wrong with an application — poor WiFi signal strength, server failure, etc. For example, if there is poor signal, you will experience slow browsing speeds, and data may not be displayed for a long time which will definitely annoy users. Errors do take place. You don’t have to be afraid of them. You just have to try to be ahead in anticipating user’s expectations by steering them in the direction you want them to go.

To do this, apart from successful data reception, it sounds like an excellent idea to think about how your application screen would look if an error occurred. That is going to be great as soon as you figure out how to handle errors in a systematic way. In case of common failures (loss of connectivity, server failure) you can use certain error messages from your arsenal without a necessity to reinvent the wheel. When it comes to some other problems (couldn’t get/transfer data) you should also provide a unified mechanism for these issues and try to use it wherever applicable.

It may fall out that you simply have no data — for example, no products were added to a cart or no message was sent to a chat. It’s absolutely ok. The point is that these cases should be taken into consideration as well.

In general, data that is supposed to be displayed on the screen is loaded. If it fails to happen in the background, it’s a good idea to consider how to display it in the interface, for instance, by showing a skeleton. Similarly to the error situation described above you can build a system which is intended to assist in decision making.

It appears that, generally, screen status can be as follows:

• Data received
• No data available
• Data is loading
• Data reception error

Data display

If you, like me, have a long first and last name, you have probably often found that your data does not always fit the screen. What’s more, data is cropped in the most unexpected places.

Take a look at how your mock-up would look for both names — John Doe and Clinton Elias Eastwood Junior. No matter how long the name is, it shouldn’t be a pain in the neck.

This also applies to the volume of content that you share on your screen. One may provide feedback by simply writing “Cool”. But what if another person is really upset and wants to spill his guts in that little input line?

That’s why it’s a wonderful idea to look at all potential scenarios.

User interface items

There will, most likely, be items in the interface that a user will interact with — a button to click or some words to enter in the input line. Even if your design system or library have all the variations for these items show different options on a mock-up. Perhaps, once you take a look at your final screen templates, you would like to enhance user experience and, for example, to deploy a keyboard once the screen opens.

If your interface enables to submit information, files, etc., please, mind to roll out the following three basic options: uploading process, successful completion of an action and an error. In this context, the error is not fatal, and you should leave it to a user to do the action once again.

If an application downloads certain content (images, videos…) you’d better provide a dummy image for it. This will definitely help to avoid blank spaces in the interface.

Technical device

When I started working as a designer, this aspect used to be my undying pain. I could make all the required mock-ups for both platforms, get an approval from a customer, submit them to a development team and put my mind at rest, and then all of a sudden my colleagues would come up to me and ask, “Is it going to work on a tablet, huh?” If your application functions on both smartphones (iOS and Android) and tablets, it’s worth checking out whether it works seamlessly with the latter.

There is yet another point to bear in mind that I would not call a rule but a particular case. My coworkers and I always create mock-ups for each platform in one and the same size. For example, right now we use iPhone 11 Pro for iOS platform. Many users may have smaller devices. So when making a mock-up just imagine what a person with an iPhone 8 or SE would see. In “particularly worst-case scenario” get ready with an additional mock-up. It won’t require a lot of efforts from you and, for sure, will make developer’s life easier as well.

You may always look into the principal points that I shared with you when creating mock-ups. If any of these aspects escape your notice, you are most likely to be asked a lot of questions by your workgroup members.

Please find below the checklist which you can adjust to your mobile app project and use it both for creating mock-ups (if you’re a designer) and their acceptance (if you’re a developer or analyst).

The checklist is now successfully applied within one of e-Legion projects in terms of collaboration with designers from a third-party company.