19. Planning the Experience

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

19. Planning the Experience

Knowing how to use the newest Android APIs is a great start, but there is more to building Android applications than just programming a bunch of code and adding more features to your application. Implementing a slick-looking user interface is also wonderful, but if your application is difficult to figure out how to use and it does not provide any real benefit to the user, it will most likely never become that “killer app.” In order to truly set your application apart from the myriad of other applications available to users, you really must think differently about what user problem your application solves. Solving that problem in a graceful way—rather than developing an application that is just a collection of implemented Android features—is one of the best pieces of advice the authors have to share.

The purpose of this chapter is to present many different concepts and techniques that should enable you to make better decisions about how to design your application with your users in mind. The information presented in this chapter is not exhaustive, nor is it meant to be the default methodology that you have to use when planning your applications. Rather, the information should be adapted to fit your particular project. The authors have seen that the most successful projects are not always performed by developers who follow one particular rigorous development methodology that has been handed to them. Usually, the most successful projects are completed by developers who work together to create their own system and refine a methodology that works best for them, within their own resource constraints.

Thinking about Objectives

When starting a new Android development project, it is always a good idea to set some expectations early on, before writing code. The most helpful expectations to think about are in the form of objectives. Usually, there are at least two parties who have objectives in relation to a given Android development project, if not more. People who use your application obviously have reasons for doing so; therefore, they have objectives they are working to achieve with your application. On the other hand, you, the developer or team of developers, have reasons for building the application. In addition, besides users and team, there may be other stakeholders who have objectives in relation to your project.

User Objectives

Generally, users install an application because of a need they are trying to fulfill. User objectives may vary widely; for example, users who are forgetful may be looking for an application that can keep track of important information for them, such as a note-taking application or a calendar application. On the other hand, certain users may want to be entertained by a game, but have only short bursts of time they can devote to playing it.

Focusing your development efforts around a clear set of user objectives should help you determine who your target users will be. As an application developer, if you try to fulfill the objectives of too many different types of users, you may end up not pleasing any users at all. If you start development without determining who your target users are, you may end up building a note-taking game for a forgetful, busy user looking for an entertaining way to help them remember important information in short bursts.

Not only will knowing your users’ objectives help you focus your development efforts on creating a superior experience for a particular type of user, but it will also help you discover if there are applications that may already be fulfilling the same or similar needs. Building an application that is just like other applications already available is not a good use of your efforts. But focusing in on the pain points that your target users have, and knowing what the current competition is, should help you make better decisions with your development efforts.

Take the time early on to think about what a realistic set of user objectives is for a particular need you want your application to fill, and think about how to differentiate yourself from the competition. Then design your application to fulfill those objectives. You may be pleasantly surprised when your users thank you for fulfilling their needs.

Team Objectives

Whether you are a team of one working alone in your bedroom, or one person on a team of many at a large corporation, you are probably building the application with specific objectives in mind. Those team objectives could be achieving 5,000 downloads in the first month or generating $50,000 in revenue in the first quarter. Other examples of team objectives could be releasing the first version of an application in one month, or something different altogether, such as generating a measurable quantity of brand recognition. The more measurable the objective, the better the decisions you make will be as your project progresses. Stay away from unmeasurable objectives, like “inspire people to write deep thoughts.”

Whatever those team objectives are, it is a good idea to start thinking about them as early as possible. Fulfilling your users’ objectives is only part of the equation. Failure to have a clear set of team objectives may result in developing software that is late or over budget, or it may even result in the project never being completed.

Objectives of Other Stakeholders

Not all Android application projects have other stakeholders involved, but some projects do. Other stakeholders could include advertisers that provide ads for placing within your application. Their objectives may be to maximize their revenues while maintaining their brand recognition without harming the users’ experience of your application. Early in the planning process, think about other stakeholders in addition to your users and your team.

Not thinking up front about the needs of other stakeholders may result in harming any types of business partnerships that you may have developed with those stakeholders. Failure to consider their needs could damage your relationship.

Techniques for Focusing Your Product Efforts

Knowing that you should target your project efforts around a clear set of objectives is the first step. Now we will discuss practical techniques that you can begin using right now to help you think about what your users’ objectives are and how you can fulfill them.

Personas

One way to keep your target users in mind during your Android project is to create a fictional persona. The purpose of using a persona during development is to think about your users’ problems from their perspective. Defining a persona and the problems that persona has is just one way to fine-tune who your target users will be—and how to differentiate your product from the other available applications.

Personas are fairly easy to create. Some of the information that you should consider defining for your fictional personas includes

Name

Gender

Age range

Occupation

Android sophistication level

Favorite applications

Most-used Android features

Attitude toward or awareness of your application’s objective

Education

Income

Marital status

Hobbies

Problems for which the persona wants or needs a solution

This list is not comprehensive, but it is a good start to help you focus in on exactly who your target users are. You should create only one or two different personas. As we mentioned earlier in this chapter, if you try to please every single type of user, your application may never actually solve any particular need for any users at all.

You can create these personas on paper and keep them nearby and visible while you work. Sometimes it even helps to attach a picture of a person to this fictional character; that way, your character has a face to go with the name. Then, when you are making decisions for your Android application, you can refer to your target user’s persona to see if you are fulfilling that user’s needs.

User Story Mapping

User story mapping is one way to approach project planning and come to a shared understanding of what you are building by helping your team to discover who your actual target users are and what interactions they will be performing with your system. This is usually done by creating simple user stories that describe the most beneficial features of your application as functional details, collecting the minimal set of beneficial features—each in their simplest form—while still allowing users to complete the most important tasks they want and need to perform. Then you can order those stories in the flow required to complete a particular objective. Once the order of the minimum number of stories is determined to meet a particular objective, a product backlog can be arranged for each story in its simplest form. When iterating over time, more complexity may be added to the individual stories as the project evolves and user feedback is gathered, helping your team determine the best way to proceed with development.

The goals of user story mapping are to learn as quickly as possible what your users actually want—without just relying on assumptions—from user feedback; to drive features with benefits provided to users as the method for deciding what to build next; and, all the while, to arrive at a shared understanding with all project stakeholders. User story mapping is a fairly complex topic, and it is worth looking into for those who are interested in taking their project planning skills to another level. To learn more about user story mapping, see the following link: http://www.agileproductdesign.com/blog/the_new_backlog.html.

Entity Discovery and Organization

Early in your project’s life, you should start thinking about the entities, classes, and objects that describe the information within your application. Drawing simple diagrams on paper can help you determine how to organize your code. Here are a few techniques that you can use:

Domain modeling: A domain model provides names for all of the entities used within a project. The domain model usually evolves over the life of a project and includes the entity names, which should be nouns, and their relationships to other entities.

Class modeling: A class model is very similar to a domain model, just more specific. A class model is usually derived from a domain model but includes much more detail—class names, attributes, operations, and relationships to other classes.

Entity relationship modeling: An entity relationship model is used specifically for describing an application’s data model. The data model describes the tables of a database. This diagram usually includes the entity names, their attributes, relationships to other entities, and cardinalities.

With the information you gather from these diagrams, combined with the Android classes that your project requires, it becomes increasingly important to think about where and how to implement classes in relation to one another as your project progresses. The larger your project gets without proper organization and planning, the more your code base resembles spaghetti code: that is, unstructured, tangled, overly complex, and very difficult to follow.

Planning User Interactions

Having an idea of the objectives a user seeks to accomplish in your application is a great foundation for moving your project forward. With this information in mind, you should take some time to plan how users will interact with your application and how they will proceed through the application to accomplish their desired tasks. You can begin planning user interactions by thinking about user flows and creating screen maps.

User Flows

A user flow is the path the user takes through an application to accomplish a particular goal. This goal may be closely related to one or more use stories, because a user must often take multiple actions in order to accomplish a particular goal. When designing user flows, remember to keep the steps to the minimum required in order to accomplish the goal while maintaining an optimal experience for the user. Too many steps may lead to unnecessary confusion or frustration.

You should also limit the number of user flows your application provides. As we mentioned earlier, you should not try to create a solution for every type of user. Instead, specialize by fulfilling a need that helps users make their lives easier. A few user flows per application are common, but you probably will design at least one or two key flows that a user performs frequently.

Screen Maps

One way to determine the user flows or key flows for your application is by designing a screen map, which is a way to visualize the relationships among the screens of your application. The organization of a screen map will vary from application to application. Some maps may involve just one or two screens, whereas others could have dozens.

You can assemble a screen map by first creating a list of all the screens that your application will need, and then connecting them to show their relationships.

Note

Not all user interactions may require you to build a screen within your application. For example, notifications for your application appear in the status bar, but you do not have to build the status bar. You just need to integrate with the Android APIs for displaying notifications to the user. Keep these things in mind when creating your user flows and screen maps.

When designing your screen maps, here are a few things you should be aware of:

A screen does not necessarily mean you need an Activity. Instead, consider reusable fragments for displaying like content.

Group content fragments together when in a multipane layout, but use them separately when in a single-pane layout.

When possible, use one or more of the navigation design patterns that are commonly recommended for use in Android applications. We talk more about navigation techniques and design patterns in Chapter 10, “Architecting with Patterns.”

Tip

To learn more about creating screen maps and planning your application’s navigation, please read the Android documentation found here: http://d.android.com/training/design-navigation/index.html.

Communicating Your Application’s Identity

To set your application apart from other applications, you should think about the identity that you would like users to associate with your product. Some of the most common ways to communicate identity are as follows:

Develop consistent style guidelines and follow those guidelines throughout your application. To jump start this process, you should take a look at the material design specification here: http://www.google.com/design/spec/material-design/introduction.html.

Choose a specific color palette and theme for your application. Use colors to establish uniformity or contrast among the different visual elements of your user interface. Style the various UI components such as the status bar, app bar, menus, action icons, views, layouts, and various other components to help make your application’s brand stand out. The material design documentation provides an amazing visual color palette to simplify the process of choosing bold colors that work well in harmony with each other. You can find the color palette here: http://www.google.com/design/spec/style/color.html#color-color-palette.

Create a unique application launcher icon that your users will remember. Try to associate the purpose of your application with the design of your icon. In addition, any other icons that you create should instantly communicate to users what the icon means.

Use your application logo rather than your application icon when portraying your brand to users. Prior to API 21, it was recommended that you display the application icon and title on the app bar. As of API 21, using an icon and a title is discouraged, so you should consider using your brand’s logo elsewhere in the application. Many of the most successful application brands portray their brand logo on the launch screen of their launcher Activity, and keep it visible for a few seconds before transitioning to the actual application with which users interact. For inspiration on launch screens, see http://www.google.com/design/spec/patterns/launch-screens.html.

Emphasize content with various font styles. Don’t just stick to one font, style, color, size, or other attributes. To learn more about the material design typography recommendations, see http://www.google.com/design/spec/style/typography.html.

Use white space or empty space effectively. To learn more about these material design layout recommendations, see http://www.google.com/design/spec/layout/principles.html.

Do not cram user interface components together. Instead, use padding and margins to provide spacing between these components. To learn more about the material design metrics and spacing user interface components, see http://www.google.com/design/spec/layout/metrics-keylines.html.

If you plan on having your application run on different-size displays, make sure it remains flexible with its layouts to accommodate differences across devices’ displays.

Tip

For a comprehensive overview of style recommendations, see the Android documentation that can be found here: http://d.android.com/design/style/index.html and the material design specification here: http://www.google.com/design/spec/material-design/introduction.html.

Designing Screen Layouts

Before investing a great deal of time or money in developing your application, you should spend some time deciding how you would like your user interface layout to appear. There are a few different methods you can use for determining your screen layouts.

Sketches

You should start making decisions about your layouts very early on by quickly creating rough sketches, on paper or on a whiteboard, to determine how your screens and their visual components should be organized in their layouts. This is a very quick way to determine any screens that may be required and should help uncover any usability issues prior to investing a lot of time in writing code. Don’t be concerned with accuracy or detail at this stage.

Wireframes

Wireframes are slightly more sophisticated and structured than sketches but serve a similar purpose. Once you determine that your sketches are appropriate, you can create a more structured wireframe to further solidify how the application layout should appear. Wireframes typically do not involve details such as color, images, or typography. Like sketches, you can create wireframes on paper or on a whiteboard, with a little more attention to accuracy and detail. You may even want to consider using a software program for designing your wireframes.

Design Comps

A design comp is a high-fidelity mock-up of an application’s layouts. Usually, it would be created in a graphic design program. In a design comp, your application’s identity should be taken seriously, as this is usually the stage where major decisions on the branding of an application are made. You may even want more than one design comp created, to allow you to choose the one that best communicates your application’s identity. A design comp is created prior to finalizing the design and identity, and prior to spending a great amount of time coding the design.

Tip

Google provides a great set of high-fidelity stencils, icons, colors, and fonts that can be used for making design comps. The stencils include realistic mock-ups of common Android user interface controls. When you are ready to create your design comps, you may opt to roll your own, although using these downloads will make your job a whole lot easier and save you a great amount of time. Many different formats are available for download, so you can choose your graphics editor of choice. You can download these files here: http://d.android.com/design/downloads/index.html.

Reacting Properly with Visual Feedback

Provide visual feedback that follows your style guidelines to let users know that something is about to happen or has already happened when they interact with the user interface, especially when the interaction involves initiating application operations or behaviors.

Some ways to provide visual feedback include

Using color states, animations, and transitions.

Displaying alert messages or dialogs to confirm or acknowledge before making a final decision. An alternative to confirming or acknowledging is the Undo pattern, similar to what is found in the Gmail application. When a user deletes an email, rather than asking for confirmation or acknowledgment, a Toast message with an Undo option is made available in case the message was unintentionally deleted.

Using Toast messages to provide feedback that does not require important decisions to be confirmed or acknowledged.

Using the Android Design Support library to maintain backward-compatible material designs for supporting Android devices, version 2.1 or newer. The following blog post provides a great overview of this new addition to the Android SDK: http://android-developers.blogspot.com/2015/05/android-design-support-library.html.

Displaying validation when users interact with forms or provide input, to let them know whether they have provided the correct information or format.

Tip

The material design specification provides a great resource for incorporating animation into your design to create responsive interaction. You can learn more about this feature here: http://www.google.com/design/spec/animation/responsive-interaction.html.

Observing Target Users for Usability

The quicker you present your design to actual target users, the quicker you will be able to discover any problems in your application’s design. In addition, observing the users’ interactions with your application and receiving their feedback could prove to be invaluable and help you get your design right.

You may want to start presenting your design to friends or family. This is definitely a cheap way to begin testing usability. The only problem is that your friends or family may not fit the profile of your target users. Therefore, you may need to use other means to find your target users. Once you have found them, have them test your design and see what you can learn from their interactions with it.

Mocking Up the Application

The fastest way to receive feedback on your design is to present your work to your target users even before you have written any code. You may be wondering how this is done, but the answer is simple. As we recommended earlier in this chapter, you may have already created rough sketches on paper. If so, presenting these mock-ups to users, without a real working application, is definitely the most cost-effective approach to testing your design up front, with very little effort.

UI Storyboards

A UI storyboard is usually a collection of screen mock-ups derived from designs. You may want to create a storyboard of all the screens required for your application, or you may decide that you just want to test the most important user flows. Usually, you would present the UI storyboard in paper format and ask a target user to begin using the storyboard as if it were an actual application.

There are drawbacks to presenting just a UI storyboard to a target user, especially because the design is not working on an actual device. But the immediate benefits that you receive may far outweigh the drawbacks. As we mentioned earlier, presenting a storyboard to a user, even if it is a series of paper mock-ups, may actually help you uncover major design issues early on.

Prototypes

You may consider building a prototype, which is similar to a UI storyboard, only more sophisticated in that the prototype actually works on a real device. Usually, the prototype’s functionality is extremely limited and is definitely not meant to be a real application. Depending on the effort you want to invest, the prototype may be merely capable of navigating through your screens and can be used just to validate the user flows, or you may decide that you would like to spend more time providing it with some of the most important functions of your application.

A prototype usually does not have much styling, if any, but it should reflect how you presume the layout will actually appear. The main point of the prototype is not to impress users with the beauty of the application, but to help uncover any usability issues that may not be readily apparent. Presenting your target users a minimally functioning prototype is another great way to discover any usability issues early in the development process.

Testing the Release Build

To validate your design, you should present your release build to your target users prior to an official launch. Even if you have tested and verified your application’s usability with UI storyboards or with a prototype, you still want to be sure that the real application does not have any major usability issues.

The release build is usually much more sophisticated than a prototype and more than likely has received styling and an application identity. Problems not apparent in the storyboard or prototype phases may be evident when your target users begin testing the release build. One reason for this could be due to any styling that may have been applied. Major styling decisions typically are not applied to storyboards or prototypes, so usability issues caused by styling will not be uncovered until real users test the release build.

Testing and validating your design prior to release is just as important and valuable to the overall success of your application as it is to the process early on in development.

Summary

In this chapter, you have learned many different methods for planning the Android application experience. You have learned how to think about your application from your users’ perspective and have picked up valuable tips for how to structure your application. You have also learned that focusing on one or two key flows can help set your application apart from your competitors. You have also learned that getting your application in front of users as quickly as possible may be the best way to validate your design. Go forth with the knowledge learned in this chapter and begin creating incredible Android application experiences for your users!

Quiz Questions

1. What are the three types of objectives you should think about when planning your application?

2. What information should you consider defining for your personas?

3. What are the three techniques mentioned in this chapter for discovering and organizing information without your application’s code?

4. What are two methods useful for planning user interactions with your application?

5. What are the various methods you can use for determining your screen layouts?

6. What are the two methods mentioned in this chapter for mocking up your application so that you can start receiving user feedback as early as possible?

Exercises

1. Come up with a simple application idea. Create your first persona, choose a problem he or she would like solved, and define a simple user story map for your idea that focuses on the primary benefits your solution provides rather than features.

2. Make a list of screens that will be required for implementing your idea, and then create a screen map.

3. Create a simple mock-up of your application on paper and ask someone to use the paper mock-up. Determine if there is anything wrong with your application or if there is anything you could do to improve the design after presenting it.