With some recent studies showing that 26% of mobile apps are opened only once by users it’s becoming even more apparent that mobile application design, whether for a game or other application type, is critical to ensuring your product’s success. You can read a lot about what you have to do to create a successful mobile user interface design but the truth is, each application is unique and the best design is not always a cookie cutter process. Understanding what your users want, are comfortable with and will be doing in your app are the key factors that will help you be successful.
Like with any field, experience helps. But there are things you can do to allow you to overcome a lack of experience and make decisions on how your application should be designed.
Start from Square One
What is the primary purpose of your application and what are all the steps a user will have to do to accomplish that? List them out, create a workflow (I’m a Visio junkie) and focus on that first. For me, I create a visual workflow by mocking up screenshots with basic shapes (I’m no artist!) and placeholder images. It doesn’t have to be too fancy to start but you’d be surprised what you can accomplish in Visio with the appropriate, platform specific, imagery that you can find on the web (buttons, sliders, etc.).
Once you have the basic workflow done, show it to someone else and have them sit down with you and look over the workflow. Usually you’ll be surprised by some of the things they don’t pick up immediately or that you thought were obvious and are not. Update the workflow and show it to the same person again, and then, assuming they think it’s better, show it to a different person. I have found that I don’t usually have to go to more than 2 different people at this stage to get enough feedback to make this level of design good enough to move forward with.
Think about the end result in the beginning
This is a mobile application you are designing. The feature set should be brief enough that you can envision what the application could look like when it’s completed. Strive to update mockups to consider colour schemes, icons, text size and content, etc. as early as possible. You may as well make sure that you can fit everything on your target devices screens now rather than cramming them in later. If you can’t figure out a way for your feature set to work on your screen sizes, cut features now rather than after spending a lot of time implementing them.
The other reason for having reasonably good mockups that could be close to the final look done early, is because no matter how much you tell someone “don’t look at the colours” or “don’t worry, we’ll fix that”, it’s very hard for people to actually look past what their eyes see. Personally for me it’s very difficult and I try to have mockups look as good as possible as early as possible, even if it’s a little more work to maintain them moving forward. Whenever you have a presentation to give, you’ll already be ready with screenshots that look good so you don’t have to rush to your art team late one night either =).
Small focus groups do work
You don’t need 1000 people to get good feedback on your UI and design. Just 10 people who you feel are representative of typical customers giving you feedback is usually enough to get a very customer-friendly UI designed. One or Two people is not enough (and people who work on the team for the application are often not the best choices). Find people who do not have a vested interest in the design (i.e. making it easier to code, advocating for one of their ideas, did the artwork, etc.) and who will give you honest feedback.
Implement your primary workflow first, in a good UI
Putting your workflow into a temporary UI that is functional for the developers to prove a feature works, but does not look like your mockups, is not sufficient for actually testing the workflow. That’s fine for the developers to make sure they have the basics down but make sure you have a UI implemented as you could see working for a final product before giving your app to focus testers. I’d always rather have less functionality done, but the basics (or first few steps) completed closer to what’s envisioned as a final product so that it’s a better demo and makes it easier to pull in a deadline by cutting in-complete features.
Swiss Army knives don’t translate well to mobile
Once you have your core functionality done, work on your accessory features. There are many examples of apps that do a number of things and make them all work together well. These apps generally have feature sets that compliment each other so well that it seems silly to not have them included together. If a feature is “kinda useful”, leave it for an update. Get the “very useful” features in the first release and make sure they are quick, easy and simple for the user to use.
Updates are REQUIRED for a successful app
In mobile, your first release is key, but only the start of a long process. Your small group of testers will (ideally) have caught all the key usability issues with your app and make it pretty easy to use. The 1000s of people who download it will come up with great ideas and suggestions — often highlighting features you didn’t think were important and left out as very important. I try to plan on having developers ready to create v1.0.1 within 2 weeks of the first release. This times v1.0.1 to be on the market usually about a month after the first release. Then, v1.0.2 can take a little longer as you should be fixing the critical issues and ‘most requested easy features’ in the first update, but probably you should be trying to have v1.0.2 live within 8 weeks of v1.0.0 going live.
A book (or many) could be, and probably has been, written about mobile app design. If you keep these few principles in mind, you will probably end up with a good app design. Focus on the core work flow for your users, always keep the end result in mind and in the design, don’t stuff the first release full of features and make sure you get outside feedback on your app before it’s released.
Nothing guarantees that your app will be successful, but a bad design almost guarantees failure.