Setting goals is a major part of the mobile app design process. It’s where you determine your priorities and set your course for the foreseeable future. If you don’t know where you want to end up, how are you supposed to know where to start?
Process is important, but it isn’t everything. Design sprints won’t help if you don’t have the right destination, and agile design doesn’t automatically lead to good design. Before you try out the newest product development strategy, here’s how to make sure you’re setting the right design goals.
Learn How to (Not) Listen to Your Users
“Listen to your users.”
They’re probably the safest four words for any design guru to say. Our users understand their needs better than designers do, we’re told. And the difference between tech titans and also-rans is having the humility to get over yourself and listen to what the users want.
Yet at the same time, we constantly praise innovations that had nothing to do with user requests. Were users clamoring for Steve Jobs to get rid of all those pesky buttons on their phones? Were bookstore customers complaining to Jeff Bezos that they’d rather get their books at home? Were Excel users calling up Eric Michelman at Microsoft to tell him their computer needed a wheel?
No. Designers should be able to solve problems better than users can. That’s our job. The role of the user isn’t to tell us what they need — it’s to tell us about the problems they’re having. As interaction designer Ivan Tolmachev puts it, ”Don’t think about what your users want — avoid treating symptoms.”
Referring to the (probably apocryphal) Henry Ford quote, “If I had asked people what they wanted, they would have said faster horses,” Tolmachev asks:
“How do we improve our product when all we have are requests to make our horses faster? We break those down. How you do that varies based on how much information you have: a user’s activities, environment, interactions, objects she interacts with and then the user herself… regardless of the research you do, you should end up with the essential problem the user is experiencing.”
Tolmachev recommend reducing user requests to the formula, “X can’t Y when Z (because W).”
For example, let’s say a user sends this request:
“At our company, we constantly have to send repeated requests for access on collaborative documents, because our owners miss them. Could you put requests for access in bold letters and have them stick on the screen until the document owner clicks them?”
From the user’s perspective, this seems like a good solution, but it may not be feasible for that particular app for a variety of reasons:
- The owner needs to check with their manager before sharing access.
- The proposed solution blocks functions the owner needs to access.
- The sticky notification would seriously disrupt user flow.
However, what happens if you break it down to the core problem?
Owners don’t know they’ve received an access request.
Now you have a worthwhile design goal: ensuring users can see and respond to access requests. At the very least, it’s worth brainstorming, and it might be a good topic for a design sprint. By looking beyond the feature request to identify the actual problem, you can give users something better than what they want — you can give them what they need.
Accentuate the Negative
The Fluid Design Handbook has a great section on setting design goals:
“Design goals help us stay focused on what we’ve determined to be most important in a project. They can serve as a quality check by making sure the designs meet the intended goals.”
But what’s really interesting is how many of their examples are negative:
- “Don’t change the display of information between editing and displaying edited information (i.e. WYSIWYG),” meaning don’t mess with the way new information is laid out — it’s too much change at once.
- “Don’t require users to leave or change their context to edit information.”
- “Give users tools that make sense for their specific context. Don’t clutter their UX with every possible tool.”
- “Allow users to easily see and use the tools they need (as opposed to giving them many tools that aren’t relevant or useful most of the time).”
Early in the design process, you often know more about what you need to avoid than what you need to do. Making the negatives part of how you articulate design goals can help keep you on track as you investigate solutions and refine your goals.
For example, “Allow users to easily see and use the editing tools they need,” could mean a lot of things. Should you pack all the tools a user might need into the screen so they can “easily see” them? Should you organize all your tools under separate screens so they’re all very visible and relatively easy to find?
It’s the negative statement that makes this a well-defined design goal. “As opposed to giving them many tools that aren’t relevant or useful most of the time,” puts the emphasis on making a smaller set of crucial tools extremely accessible, rather than packing in all the functions you can.
Don’t settle for vague mobile app design goals just because they sound good and laudable. It’s okay to admit you don’t know exactly what you want early in the process — provided you know what you don’t want.
Consider Broader Business Goals
What the user wants to do and what you want your business to do are often two different things. As a designer, it’s your job to figure out how they can work together. At UI Patterns, Anders Toxboe goes into detail, describing how to do just that.
So for example, let’s say your business’ goal is, “We want more people to use our photo manipulation app.” You might focus on a user goal like, “I want to receive positive feedback and acknowledgement.” To address that goal, you could add commenting or sharing features, or enable users to submit their favorite photos to be highlighted across the app.
The ultimate goal is to achieve and measure SMART (specific, measurable, achievable, realistic, and time-bound) goals. You might set a goal for 5,000 downloads in the first three months, monitor it, and tweak your app or promotion strategy based on the outcome.
This is a paradigm that’s more common in web design than it is in app design. In this framework, the purpose of promoting an app isn’t usually adoption or even paid downloads, but affecting user behavior in some way for a broader business goal — for example, increasing brand recognition or persuading users to make a purchase.
And yet, this framework is extremely relevant for app designers and developers. Most obviously, apps and websites serve overlapping purposes. For example, apps often are created as tools to improve brand image and visibility, or to get a user to purchase products or services they could alternatively buy through the website.
But what about apps with a profit model that doesn’t generally apply to web design? What if your app is your product, either as a paid download or a way to sell upgrades, advertisements, or in-app purchases? Even for those apps, business goals need to play a bigger role in defining app design goals.
For example, let’s say you’re part of a development team building a brand new game. Some business goals for that product are obvious: you want users to download it, play it, share it, and perhaps make in-app purchases depending on your profit model. Those all lead to conventional and important app design goals, like making the game user-friendly, challenging and addictive, incentivizing purchases, signing up friends, and so on.
But all those goals only relate to the app as a single product. How does that app fit in with wider business goals? Does the app create the image you’d like users to form of your company? Does it motivate them to seek out other apps you’ve made?
A business goal like “I want users to try other games made by our company” could inspire designers and developers to make all sorts of interesting decisions, such as:
- Making in-game references to plots or characters from other games.
- Including hidden mini-games or bonus levels referencing previous projects.
- Adopting layout conventions, visual cues, or color schemes from other games.
- Rewarding players with a currency that can be used for purchases across multiple games.
- Allowing users to use skins, gestures, or conventions from other games.
We’re not saying these concerns will always be major factors in app design decisions. There may be no way to connect your new platformer with your old puzzler without making a mess of both. But you’ll never know until you investigate. If you’re still looking at each app as an isolated product, it’s time to look at broader business priorities.
Keep Experimenting
A lot of people believe that the best way to design something amazing is to set very specific design goals from the beginning and stick with them until the end. We’re going to assume most of those people aren’t successful app designers.
Things change too quickly in our industry. Technology, user needs, product offerings, and development tools are constantly in flux. If you want to stay on the cutting edge, you have to stay flexible, iterate, and adjust your goals when it’s appropriate. That means you need to take risks and try new experiments to find out what works.
The right mobile app prototyping tool can help you do that. You can quickly turn your ideas into designs, and your designs into functional prototypes. And functional prototypes let you gather better user feedback earlier in the process. That means you’ll be able to throw out bad designs and rework flawed goals until you hit on the perfect solution for your app.
Proto.io lets anyone build mobile app prototypes that feel real. No coding or design skills required. Bring your ideas to life quickly! Sign up for a free 15-day trial of Proto.io today and get started on your next mobile app design.
Have any great tips for setting design goals? Let us know by tweeting us @Protoio!
