Lots of mobile apps start out as simple sketches on a piece of paper. Those sketches are then transferred to digital wireframes with the help of wireframing tools. Some projects and companies stop here and give static wireframes to the design team, while others create prototypes and iterate with the customer. Omitting all of the important steps can lead to incomplete wireframes or flows.

At Five, we create all wireframes in Balsamiq, arrange them into user flows and create prototypes in InVision. Each of these steps is necessary to produce a high quality app, and here is why.

(In)complete wireframes

Incomplete wireframes can cause issues in the app development from the early preparation stages to the project end. Developers will usually try to patch up parts of app with missing screens or states, thus lowering the overall quality. As a result, those undefined screens stand out from the rest of the app by using slightly different (and we might call them simply – wrong) patterns and layout.

Here are the usual 5 cases, and their consequences:

Missing screens

Most obvious case of incomplete wireframes is when there are actual screens missing. Sometimes these are screen of lesser importance (settings screen, help screen, forgot password), other times these are screens already seen in some other part of the app. In the world of apps, not important and already seen do not exist. Every screen should be defined to ensure app quality and good consistent UX.

Missing screen states

Not as severe as missing screens, but it`s another common mistake designers make. When developers stumble upon missing states, they will try to fill out the parts of missing information, and improvise when working on those screens. This usually results in bad experience and lower quality of the application.

No error messages

It is very important not to leave the user that stumbles upon an error without a notification or available action. Such UX can cause the user to be frustrated and blame the app, or think they did something wrong, while in reality it could easily be a connectivity issue.

Isn`t that curious? Because if you tasted some food that you didn`t think tasted right, you would assume that the food was wrong. But for some reason, it`s part of the human condition that if we struggle to use something, we assume that the problem resides with us. -Jony Ive

No flows

You have all the wireframes, but no flows and visible connections between screens. This causes issues mostly in the development phase. Developers can`t create apps without visible interaction between screens, without a marking where to tap or perform an action to move forward in the flow and to a new screen.

Missing platform specifics

Using native iOS controls on Android applications and viceversa. Developers end up developing complex controls that are not part of the native platform, which not only causes higher development costs, but the users end up with apps that they are unfamiliar with and they can`t use easily. In a nutshell, you are getting a more expensive app with worse user experience.

Which flows to cover?

The easiest way to define which user flows to cover is to focus on creating user stories. When you have all the user stories, you can define which screens are needed inside the app and how to connect them in a user flow.

Here are five flow types that you shouldn`t miss:

User decisions

Don`t think that one flow needs to be linear just because it follows a specific user story. All possible outcomes and user decisions should be marked and visible in the flow.

Edge cases

What happens when the user doesn`t add any content? What happens when the user tries to access a screen available only to registered users? These two and other similar questions should be answered inside of the flows. There should be no cases left which aren`t covered in the flows.

First start, resume

First start flow shows how the application will greet the user or explain its functionality on the first start. It should be optimized for the user in a way that there isn`t lot of traction, but still gives user necessary options/information to use the application. Resume flows show how the application will behave if the user left the application in the middle of an longer lasting action, or how the screen will update if data has changed in the meantime.

Platform specific

It is important to have platform specific flows if you use different navigation or interaction platforms.

Automatic flows

Flows that do not happen with the interaction of user, for example, if you want to animate loading or syncing of the data on the screen, you should create a flow which explains how it is done. Other example is how to update content, when the user is in the app and the app fetches refreshes the data every 30 seconds.

Addition checklist that could help you discover if anything is missing in your flows and wireframes:

• Do all screens have required screen states? Including empty states?
• Are all possible actions on all screens shown in the flows?
• How is the content updated?
• Is the validation shown for entry fields?
• Do you have a settings screen, terms of usage or privacy policy?
• If you have timestamps or sorting, is it localized?
• How are changes in the item details shown when you go back to a list overview?
• What if you have sorting by name and user just edited the name or deleted the item?
• How to handle pagination, or swiping with lazy load?

Prototypes as a development input?

Prototypes are great, don`t get me wrong, but they aren`t and can`t be 100% of the input handed to the development. Complete development inputs include wireframes, flows and prototype.

Pros of prototypes:

• Easiest way to see and feel the app before actual development
• Helps locate a lot of UX issues that aren`t visible on static wireframes (e.g. too small action areas, too much screen depth)
• It is easier for the client to understand the project scope and give feedback using prototypes, than what is the case with wireframes. Without prototypes this feedback usually comes within the development phase, which is too late, and can be rather costly.

Cons:

• Edge cases and error messages can not be displayed because they confuse the user in understanding the app and the flows.
• Animations and gestures are limited at this point and can not provide 100% accurate visual experience of the real app
• Due to the complexity that rises with the number of screens, it is sometimes hard to provide completely accurate flows, which can lead to confusing flows. One case is when you can get to one screen from multiple screens, but when you press back you can only go to on exact screen. Behaviour like that could confuse the user.

During the development, wireframes and user flows are the main input, but prototype is extremely useful if the developers want to quickly view the behaviour of an app without diving into large sheets of wireframes and flows. Process like that allows us to have lean and mean development process while maintaining attention to detail.