In today’s mobile society, the current and future generation of “mobile” devices (i.e. smartphones, tablets, “phablets,” special purpose devices, etc.) and the applications that can be hosted on them provide a significant opportunity to improve the way we work. This is especially true for those workers whose job involves traveling during the day to work directly with customers “in the field.” In this post, I’ll share some recent experiences we’ve had in working with mobile field workers as part of an analysis effort to define requirements for a tablet-based application.
The specific approach we used for this project was to “follow” or “shadow” the workers as they performed their activities and collect observations about:
- The tasks they performed,
- The devices and applications they used to support those tasks, and
- The types of information and work products (forms, documents, etc.) they either collected or produced in course of performing the tasks.
We worked with both staff personnel and supervisor personnel, and we looked at both scenarios where customers would come into a field office and scenarios where the field staff would meet customers at a field location directly. We then followed the observation sessions with one-on-one interviews to review the observations and ask more specific questions.
Based on our experiences, we identified what we would consider to be some key recommendations for business analysts, product managers, or others seeking to elicit requirements for mobile worker applications.
Recommendation #1: Planning is everything… Get all your ducks lined up ahead of time. Field workers are BUSY people working directly with their customers. Their time is beyond valuable. Plan your visit with them down to the last detail as far ahead as possible, set the ground rules on what you will do, what you can observe and what topics you can ask questions about and what information can be collected. Also, it is critically important to be aware of any organizational policies, security policies, union rules, and privacy regulations that would apply to the situation.
Recommendation #2: Clearly explain your intent in working with them and the intended benefits. Make it crystal clear why you are there, how long you will be working with them (one hour, all day, etc.), what information you are looking to collect, why their investment of time with you will be to their benefit, and how the information you collect will be used and who it will be shared with. Make sure you obtain all of the required management approvals in place ahead of time for their time.
Recommendation #3: Always be courteous, considerate and respectful. Seems obvious…right? Use common sense to judge when it is appropriate to politely ask a question to get information while they are performing their work. Always seek to minimize the disruption to their workflow and if needed write down the question as a follow-up you will ask later. This ends up paying huge dividends through building trust, and often they will be willing to spend more time with you during a slow period of the day answering questions or stay after the appointed time to help you understand what they were doing in more detail.
Recommendation #4: Be on time and ready to go. Field workers often work on an appointment basis so all parts of their day are scheduled down to the last available time slot. If you have scheduled time to go out into the field or be at work site with them as their go through their appointments, make sure you arrive on time (or better yet…early) and are fully prepared to hit the ground running.
Recommendation #5: Take copious notes. You absolutely need to sweat the details during your observations of the field worker’s activities as what appears to be not important to you may be very important in the their view – you have time (usually) to sort out which are the key details later. Microsoft OneNote (or any tool that lets you record handwritten notes on your PC/Tablet) is your best friend. The Microsoft OneNote Windows Store app on a Microsoft Surface Pro is a great way to take notes quickly and efficiently. One additional item to consider around note taking is whether you can take pictures, or voice or video recordings during your time in the field with them. This can be a very sensitive topic in most situations so you need to work out any ground rules around recordings ahead of time.
Recommendation #6: You never really know for sure unless you ask… During any follow-up interview sessions make sure you come prepared to ask clarifying questions about what you observed, even if they may seem obvious. Pay attention to the order to the sequencing of tasks and make sure you understand what has to be in place to start each workflow, and what are the possible outcomes of each workflow. In defining requirements for a mobile application, you need to fully understand the details of each activity performed today to properly explore candidate solutions/technologies (mobile cloud services, hybrid web/native device app vs. mobile web) that can be used to improve the workflow.
Recommendation #7: Always ask for their input on what they would like to see improved. This can be a delicate conversation to say the least, but it is vitally important to your mobile application requirements definition effort. In some cases, field workers may be reticent to share ideas about how their workflow can be improved out of concerns of what management or their peers may think, so you need be prepared to elicit their input by asking questions is a general case context and from an organizational, not individual perspective. In other cases workers may be more than happy to share what’s wrong with the current practices and systems, and are very willing to take advantage of the opportunity to share with you what types of changes they would like and what features in a new mobile application could best meet their needs.
Recommendation #8: Pay attention to form factors. What devices are used, how they are used, when they are used and why they are used. What applications are they running on each device and for what purpose? How to do they enter information — are they using a keyboard, pen, mouse, touch or voice? Take note when they are performing tasks using handheld devices and walking around vs. sitting at a desk. Be on the lookout for situations where the device (and the apps on it) may not be utilized to the fullest extent possible.
Recommendation #9: Understand what information is collected in each workflow: how, when, where, and why. Watch for any duplication, rework, or repetition in information collection and usage. Look at real-time and batch transfers of information between:
- Apps on devices
- Central server or cloud service (uploads/downloads)
Apply Lean Thinking principles to your observations to look for sources of delay and waste. Find out when any information is captured/stored, shared, and published; where that information ends up and in what form (stored in database, viewed in a report, printed on a form, etc.), and what quality assurance processes that the information goes through.
Recommendation #10: Understand the bigger picture of the whole user community. Remember that you are only going to see one (or maybe a couple) of field workers performing tasks, and each person will optimize the way they work in their own individual fashion. Ask questions to understand how others may perform similar tasks. Also gather information on total number of users of the different systems they currently use and what the general workload is like throughout the day on the systems being used. Understand the differences in work patterns during “normal business hours,” and outside normal business hours (nights and weekends, if applicable).
Recommendation #11: Collect sample forms, documents, email templates — any materials that are used by the field workers as part of their workflows. These help you understand all of the information that may be used during specific scenarios and may give insight into how the workflows can be improved both from a performance, consistency and quality perspective.
Recommendation #12: Ask for Training Manuals, User’s Guides and/or Online Help Topic content for the systems that were used. These are also great reference sources of information that can help you understand both business context and how the current systems are expected to be used, and also often provide information that helps identify specific scenarios you may not have seen the field workers perform during the time you spent with them.
Recommendation #13: Transform your interview notes into an initial product backlog…while it is fresh in your mind. It is critical to create an initial product backlog for your mobile device application while the information from your shadowing activities is still fresh in your mind. One approach is to formulating the initial backlog is to go through your notes and:
- Identify the different personas/user roles from your observations of the worker(s).
- Identify the goals each role had in using the existing applications, and using their input (and other stakeholder/sponsor goals) for process improvements identify the goals for the new mobile application. This may require adjustments in the definitions of the personas/user roles to account for new ways of working.
- Identify the candidate epics and user stories for each user role/goal.
- Create and structure your backlog (group epics/stories, perform initial stack ranking etc.) using the tool of your choice.
Recommendation #14: Use Team Foundation Service (or any online tool mechanism) to communicate and collaborate on the initial product backlog for review and quick feedback. One option, if the customer permits it, is to use a TFS project in the cloud. You can use your Microsoft Account (Windows Live ID) to create an account on http://tfs.visualstudio.com and quickly build your product backlog using either the Agile or Scrum process templates.
In our experience, following these recommendations will go a long way towards building a trusting and productive relationship with the mobile field workers you are building an app for. These practices will also strongly support the ability to collect the necessary information for building a sound product backlog of requirements for a mobile application.