Supporting User Goals Makes Good Apps
Supporting User Goals Makes Good Apps
Join the DZone community and get the full member experience.Join For Free
Microservices. Streaming data. Event Sourcing and CQRS. Concurrency, routing, self-healing, persistence, clustering...learn how Akka enables Java developers to do all this out of the box! Brought to you in partnership with Lightbend.
In Android blogs, especially design related ones, we often get stuck talking about app visuals and if they do follow the Android design guidelines or not etc. While I think that is important I don't think that is the most important issue in design. More important than looks or even following guidelines is that the apps help people to do what they want to do.
User goal oriented designA user goal is something user wants to achieve. It is not related to app functions but instead an end state the user want to make happen. For example, when talking what users want to do saying that "a user wants to press send button to send message" is not true. Pressing a button is not the end goal of the users. Her goal is to send the message, or we might even say that her goal is to inform her friends about something and the message just becomes means to achieve that goal. These are the things we should talk about when we design our apps. Keep the end goal in mind all the time. Personally, I strongly recommend changing your language to reflect that. When you talk about your app don't talk about features, talk about goals. Explain what goals your app allows the users to achieve.
Read more about Goal Oriented (Directed) Design all over the web.
Step one in app design: figure out what users want to doWhen you start an app project start it by figuring out what your users want to do. Without that knowledge you're going to make successful project much more unlikely. I know it is tempting to start drawing the app UI or even writing code but try to resist. Try to describe your app fully without mentioning a single app feature, button or UI component. If you manage to do that you're in a very good place. If you have an abstract definition of what your app can be used for designing the actual app without bloated and confused user interface is much easier and much more likely to succeed.
Step two: figure out which bits your app should supportTalking about bloat. No app should do everything! Decide what your app does and what it doesn't do. It is as important to have a clear picture of the limits of your app as it is to understand the actual content. Don't try to do everything. Apps that focus to a smaller set of goals are genrally much better and have greater user acceptance.
Features are derived from user goalsOnce you understand what your app is going to do in abstract terms you're ready to jump into design. This step is more simple than it might first seem. What you need to do is to take your set of user goals and figure out which features your app needs. Every single one of your app's features must be derived from one or more of the user goals you decided to support. If you end up adding features that aren't directly needed by any of the app's user goals you are either missing a goal that is important or you're building bloat to your app.
|Pic source: Sandra and Woo|
More features != betterFor some reason feature lists have become selling points of apps at least on PCs. All sort of feature comparison matrixes pollute product websites and are supposed to explain why one product is better than another. I couldn't disagree more with this approach. More features don't make an app better. That is not to say that an app that has more features couldn't be better than an app that doesn't. What matters is how these features ended up in an app. Only add features that are needed to support user goals that your app supports.
Listen to your users but don't let them design your appIf your app becomes popular you're likely to get flooded by feature requests. The worst thing you can do is to jump in and try to implement the features you're requested to do or let your users to vote which features they'd like to see implemented and then build them. Remember that your users aren't designers! Don't let them design your app. They would do very poor job at it!
Just to be absolutely clear, I'm not saying that don't listen to your users. Do listen to them. But when you get requests like the one above one, think what is the user goal behind the request. What do the users want to do? Once you figure that out and especially if you get multiple requests pointing to the same user goal it might be worth evaluating if support for that goal should be added. The answer might be no and you should not be afraid to say that this is a goal that your app should not support. Maybe there are other apps that do it better or maybe adding that would make the app less useful for a large portion of other users.
If you end up deciding that the user goal derived from these feature requests is something you want to add to your app don't use the feature requests themselves as starting point. Use the user goal you derived. Start from that and design the best possible solution to suport it. Doing that is likely to make your app better and will also make the users who requested the features happy as the're able to do what they wanted and rest of your app's users wont be bothered by strange out of place features.
Non-optimal UI can be better than beautiful UI
I have two apps that I really, really like on my Nexus 7. Both of them are great examples of sharp focus to user goals. Neither of the apps have great UI from visual point of view and they one of them even breaks one of my rules "never use popups". Still, I love both of these apps. Why? Because they allow me to do exactly what I want to do easily. These apps are Komik Reader and Smart AudioBook Player.
In the Komik Reader app (left) when you reach the end of a comic book you're reading it pop up the popup in the screenshot. While I hate popups and think that there are many ways this could be implemented in a better way without popups this UI is good. This feature directly supports the most likely user goal when a user reaches the end of a comic book: "I want to read the next one". The app is also smart and only shows this when there is a next issue in the same series available. This feature makes me feel like the developer has thought about the users and thought about what users want to do. Now, that said I still wish that the dev would implement this without a popup :)
Another app that I love on the N7 but is probably even better example of non-optimal (maybe even ugly) UI being good is the Smart AudioBook Player (right). The UI could be much more beautiful but as it puts the user needs in the absolute center of the design the app is great even without one. The app automatically forms full audiobooks from multiple MP3s (audiobooks are often distributed as multiple hour long MP3s). To users the files are nearly invisible. User never has to remember where they were the last time they listened the book etc.
That's not all. The app also has smart logic when continuing a book playback. If you pause the book only for a short time the app rewinds the book for few seconds and continues the playback when the user taps the play button. If you, on the other hand, leave the book for longer time it the app will rewind your position in the book for few minutes. Both of these subtle features points to the developer really thinking what the users want to do with an audio app. User goals like "I want to resume listening a book I've been listening yesterday" and "I want to resume book I was listening after a short interruption" are very well supported. While the app could definitely use a bit UI love it still great app even now.
There will always be unhappy usersRemember that you can't please everyone. There will always be users who find your app lacking. Often people like that are very loud in their demands. People with technical background will demand your attention to use cases they find important which nobody else will ever encounter. It is impossible to please everyone. If you're confident that your app does what you designed it to do don't feel pressured to add support to these special cases. Don't be afraid to say that your app is not supposed to do something that you don't want it to do. Apps with focus are better than apps that try to do everything!
Beautiful UI with user focus will gain attention
One of the greatest success stories recently has been Joaquim Verges's Falcon Pro (for Twitter) app launch. The app got tons of attention right after launch and is showing excellent download numbers on the Google Play as well as great reviews. Why did this app get so much attention?
The app looks great. It follows Android UI guidelines and runs smoothly. But what I like to think is the biggest difference between this app and others competing in the same market is the focus Joaquim has put to supporting things that twitter users actually want to do. The most important views are immediately accessible and the information users need most from a twitter client are available to users in a glance. Secondary functions are hidden from view keeping the main UI clean and simple.
Joaquim told me that his approach to development was to use the app constantly himself. He explained that he added features to the app once he felt that he needed them. While we often aren't in a position where we can use this approach as we're writing apps for other people and not to ourselves there are ways we can utilise a very similar approach. This approach is called User-Centered-Design (UCD). UCD goes hand to hand with Goal Directed Design. You could say that GDD is the way you think about the app while UCD is the method you use to build it.
Wan't to be the next Falcon Pro? Build for users!If you want your app to be a success story like the Falcon Pro build for users. Give your app focus. Don't try to please everyone and don't add features to the app unless they're based on user goals. People will like your app if they feel that it helps them to do something the need to get done.
Published at DZone with permission of Juhani Lehtimaki , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.