There are stark contrasts in the design processes employed for a social media app and an enterprise mobile app. An enterprise app relies heavily on research before design. The design team for a social media app could — arguably — cut more corners in the research and ideation stages if they wish.
However, the repercussions of skipping contextual inquiry for a field enablement app would have a far greater impact on usability than skipping the same steps when designing a social media app. Enterprise field enablement apps, like the ones we design here at ChaiOne, depend heavily on seamless integration with existing workflows and established systems that would cost quite a bit of time and money to change. The easier, softer way is to do your research and design the app to fit into the existing environments.
So, to that point, the process starts long before wireframes are drawn or screens are comped. We start by asking questions to accurately assess the problems we need to solve. Whether for the healthcare or oil and gas industry, context is everything for mobile enterprise applications.
What you’ll need to know going in:
Who is the user?
If you’ve set out to design an app for use in the field, you’ll likely be focusing on a limited number of user groups or personas. You’ll need to answer questions like these:
- How comfortable are they with technology?
- How old are they?
- How much do they know about existing mobile platforms?
- What does their work day look like?
- What is their work flow and what specific tasks must they complete to perform their job?
Answers to questions like these will help set the stage and establish context to inform your design later on. For example: Truck drivers at a shipping company may desperately need a team communication tool to reduce unnecessary mileage, but for an oil field worker, team communication may be less important; they may care more about data visualization and statistics from their wells.
You can see how the two user groups will have different expectations of mobile technology and unique needs that will need to be addressed in the design to help them perform their jobs. Knowing the scope of their employment will help you design a solution that aligns with the already existing business objectives you’re trying to satisfy.
How might their physical environment impact usability?
The user’s physical environment can greatly affect the way they interact with the app. Consider these questions:
- Where do they spend their time?
- Will they use the app at night or during the day? While driving? While on a ladder?
- What safety hazards are there?
- Do they have to wear gloves in their daily work environment?
These questions will present design opportunities that can prove your design’s viability. Or not.
Here are some insights they might lead to:
If the users wear gloves while they work, they may require a stylus which means, as the designer, you can’t rely on gestures as heavily and some otherwise easily discoverable behaviors could be lost to the user.
Whether they’re working in bright sunlight or none at all, brightness and contrast are important factors to consider — as is the color palette. 10% of men are color blind. If the majority of users are male, you’ll need to account for color blindness in your designs as well. That may mean adjusting the color palette or line patterns, increasing contrast, or a myriad of other options you can choose from.
Other questions you’ll need to ask:
Based on what you know about the user, what problems do they face and which of them can be solved with technology? How do they use their current technology? What are their frustrations and pain points?
The insights gained from this discovery stage should give you enough to start ideation on design.
Put pencil to paper (or marker to whiteboard)
Once you understand the context, it’s time to start drawing out the app map.
Start with big, broad strokes that help you feel out the major sections of the architecture. A well-thought-out app map will cut down on design time and maybe, magically, reveal navigation themes and interactions that might have taken weeks or months of iteration to come up with.
Again, start with broad strokes – lay out the main sections according to your app map and then ask questions:
- What is the most important info to display here?
- How does the user move from A to B?
- How does he move back?
The more questions you ask during the ideation phase, the better your solution will be. Asking questions helps to flesh out the details in navigation, prompts you to consider what visual cues might be needed, and presents opportunities for innovation.
My favorite question is “What if…?” Taking the app “from good to great” is sometimes the result of answering “what-if” questions: “What if we didn’t have this standard menu?” “What if we tried it this way…?” Then of course, because we’re visual thinkers, you would sketch out an example and see if it’s a viable option.
When you’re designing your wireframes, be sure to consider the interactions, animations, and transitions between the screens. The beauty of mobile is that you don’t always have to use a button that will take up valuable real estate on the screen – lots of features can be discovered with gestures. So imagine how the user can get from A to B without a button and how you might guide them in a way that’s both practical and artful.
Once there are a few wireframes to choose from and your interactions are considered you can build prototypes and test them with real users.
Put your research cap on
Participating in usability evaluations
During this phase it’s incredibly useful, as the designer, for you to be present during the test sessions because you’ll gain firsthand knowledge of how users interact with the design.
Sometimes interactions are so nuanced it’s difficult for the user to state why something isn’t working so when they interact with the app, pay close attention to their non-verbal cues: their mood, their body language, breathing, etc. You’re looking for qualitative data that will help fill in the blanks between the quantitative data. This is all implicit user feedback and can shed light on UI and IA pain points that weren’t explicitly stated but still need your attention.
Note physical differences in users that may impact the design. You may notice that the test subjects that fit “Persona A” all have large hands, have trouble seeing or don’t understand the “light-touch” interactions. You’ll need to account for this by increasing the size of key hit areas.
One of the quantitative measurements a researcher will take is the SUS score, which measures perceived ease of use. This score (and other quantitative data) paired with the qualitative data and quotes you’ll be observing help immensely with stakeholder buy-in.
Please note that while any testing is better than no testing, the “quick and dirty” sessions we might do on our own, as designers, may suffice for a social media app but, when it’s an enterprise app, I recommend testing with an experienced researcher who can collect, analyze and synthesize the qualitative data appropriately.
Moreover, a trained scientific researcher will be more adept at limiting feedback and creating test environments that make the user feel like they’re not being tested.
Go back and change it
Now is the time to take the usability test results and go back to iterate on the design, making it better and more intuitive. You’ll make changes to the design after each test so don’t get married to any of it. After your first round of usability testing, you should have a list of wrinkles that need ironing out and a good idea of what is working and what isn’t.
Maybe you learned some things you didn’t know going into the design phase; some extra info about the user’s workflow, for example, and this additional info has given you new ideas about what new features might be added or what existing features can be cut out.
What if the tests show you need to go back to the drawing board and start over? If that’s the case, you should evaluate the existing designs to see what might be salvaged from them. The new design shouldn’t be built around the salvaged pieces of old ideas, but those pieces may work better with the new iteration.
Whatever edits need to be made, make them fast. Sketch out new wireframes and build better prototypes. Then test it again and iterate until your designs are validated.
Give your wireframes some style
Once your wireframes have been validated through testing, it’s time to start exploring visual direction. Before you start picking typefaces and color palettes, it would be a good idea to go over your research findings again; those insights will come in handy. Visual design isn’t just about what looks good. As with wireframes, every decision needs to have a reason behind it – you’re trying to solve a problem so make sure everything works toward that goal.
The user’s environment greatly impacts the design style, as does the user’s expectations of industry technology – sometimes colors have meaning that we might not expect within the context of a specific industry:
Green, while it signals “go” to most of us, in oil and gas it often indicates oil production. Individual companies may also have long established color and iconography systems that you’ll need to consider when applying visual direction to your wireframes. Sticking to basic design principles and color theory may help greatly in these situations.