When I work with clients in creating mobile user interfaces, I often find that the developers involved want to know about tricks that will let them “fit more stuff on the screen.” And “fitting it all in” does matter….but it’s not the critical success factor in mobile design. The critical success factor in user experience mobile design is figuring out what your users actually want to do in the mobile environment (as we discuss in our UX design course). Here’s an example, based on one of my clients, of what this means in a practical sense and the lessons we learned.
My client had created an in-house desktop application to support their business of providing consulting services to mid-sized businesses and mid-level government bodies. The application served a lot of purposes for the business consultants: they could enter their time and expenses on each client’s project, review their “hours spent” by project and time period, see what their upcoming assignments were, modify their work schedule, and so on. The application used the data that the consultants entered to bill the company’s clients, record payments, and track the company’s projects.
The consultants’ most common interaction with the application was entering the time spent on client projects – a task that was more complicated than it might initially sound. When entering time, consultants had to select a project, select a task within that project, specify the kind of work they were doing on that task, and (finally) enter the number of hours spent. The consultants used the same screen to enter their expenses, which required them to enter the dollars spent, the date the money was spent, what the money was spent on, and what project the expense should be assigned to. This screen also displayed all the time and expenses for the consultant for any period.
In a mobile environment where the user is often in motion, supporting any of those tasks was going to be challenging and doing it on one screen would be impossible. However, in the mobile environment we recognized that the consultants wanted to do much less than they did in the desktop application. We identified three scenarios that made up the consultants’ mobile user experience:
For everything else that the consultants did with the application, they preferred to fire up their laptops and take advantage of the big screen, the mouse, and the physical keyboard.
We had one other fact in our favor when designing the mobile scenarios: for both billing clients and paying consultants, the company was organized everything by the calendar week. As a result, any lists we provided just needed “a week at a glance” view.
This understanding of the mobile scenarios let us redefine the mobile time entry scenario from “entering time on any project/task/work type” to “entering more time on the current project.” That redefinition let us dramatically reduce the data entry required: We just repeated the data from the user’s last time entry when the user went to enter new time. Typically, the only thing a consultant had to enter was the hours spent. When a consultant did have to change any of the project/task/work type options, we let them select the new settings from dropdown lists, pre-filled from the user’s existing assignments.
For entering the actual hours, we put a spinner control on the screen to let the user select the number of hours worked. To support billing for part of an hour, we provided three radio buttons under the spinner that let consultants choose between 15, 30, and 45 minutes. With this design consultants typically just:
Because time entry was the most common task the users performed, when users opened the application we did not bring the user to some main menu screen or require the user to log on. Instead, the mobile application opened on the time entry screen.
Because the consultant’s second most common task was entering expenses, we allowed the user to slide the time entry screen aside (up/down or left/right) with a thumb flick to bring up the expense screen. Any expense a consultant entered was automatically assigned to whatever project was set on the time entry screen. As part of analyzing the mobile scenarios we discovered that 80% of expenses fell into one of just five categories so we provided those categories through radio buttons (a text box supported all other expense categories).
For the reviewing time scenario, we provided the consultants with a button on both the expense and time entry screens which brought up a screen showing a list of time entries for the week. Consultants could press on an item in this list to go to the now familiar time entry screen and adjust their time. After changing their time, consultants could return to the time entry list using the phone’s back button.
First mobile UX design principle learned: Everything starts with the actual scenarios your users want to execute. But, it turned out, we had more to learn.
During usability testing, we discovered that the consultants used the total time on a project in the week as a way of crosschecking their time entries. To support that crosscheck, we added a panel at the bottom of the list that showed, for a project, the total hours worked this week, the total hours worked to date, and the total hours estimated. Users could tap any time entry to see the information for the project in the selected time entry. That tap usually wasn’t necessary, though, because a consultant typically only worked on one project in a week and we automatically displayed the hours for the project for the first entry on the list.
Second mobile UX design principle learned: There’s always more to learn and usability testing is a great opportunity to learn more about your users’ scenarios.
When we were done, a user could enter their time or a typical expense in less than 15 seconds and review/update their time in a few minutes. By understanding the mobile scenarios, we created an application that could be used in a hallway, a Starbucks, or a cab. In other words, we created a genuine mobile experience.