End-User Ecology: Overlooked Success Factors

You know what your system is supposed to do, and who the target users are, but knowing the context of the end-user operations can be just as important. End-User Ecology looks at the relationships between people and applications in the context of their operating environments. In this blog post, I will list common environmental factors that are easy to forget, but can make all the difference between a barely functional system, and one that is truly successful!

Interruptions: Rarely are your users only doing one thing at a time. For mobile applications, a user can be interrupted by a phone call or text at any moment. A mobile application must instantly save its state and data, and every screen should be intuitive enough to let the user resume at any point. For business applications, users might be using the application while also answering phone calls, interacting with people at their desk, responding to emails, squeezing in time between meetings, and handling countless other distractions. If a task takes more than a couple minutes, a designer cannot assume it will continue in one continuous stream. You should plan for interruption as the norm, not the exception.

Work Patterns: How frequently are your users doing each task? Do they repeat a task several times a day, once every few months, or do they do it once and never again? Frequent users will benefit from shortcuts and accelerators that let them complete tasks quickly. For less frequent users, more guidance may be needed. Users conducting longer-term, episodic tasks might need to gather a lot of different information in between uses, and complete the tasks in segments, over several weeks or months. Some users might also compose responses in another tool, such as Microsoft Word, and then paste it into the application. The system should accommodate these users too.

Gateways to the System: Is the user clicking on a search engine result? Accessing a bookmark? Navigating a menu? Clicking a hyperlink or a deep bookmark? Maybe they’re launching an icon from a virtual desktop or their mobile device. Knowing how a user initiates a task can help determine the necessary level of guidance. For example, people who search a Web site’s content might land deep within the site, far from any headers. Navigation aids such as breadcrumbs, and local navigation links, can be signposts to help them find their way. Applications that always have the same start point can have dashboards or workspaces that let the user easily respond to tasks needing their attention.

Social Context: Many times, a user needs to interact with others outside the system – researching information or obtaining approvals from other people who never use the system directly. Even a beautifully designed system may still need to export reports to standard formats such as Microsoft Word or Excel, to allow external stakeholders to view the information. Their input may have little to do with the actual software, but their needs are still critical to the overall success of the business process.

Special Environments: Does the user need to upload information to a classified network, via an appointment set weeks in advance? Are they on a mobile device with low bandwidth or unreliable connectivity? Maybe they’re on rugged terrain with sun glare or sand stinging their eyes. These factors all affect the task design. Special environments might also offer benefits. Perhaps the user is in a store looking for bargains, and might respond to a coupon. Or a user is at a conference, wanting to connect with others who share their interests. Good task design can take advantage of these factors.

Device Limitations and Features: Small touch-screen devices can be difficult for entering text, but high-resolution screens can showcase content for user consumption. Mobile phones have tiny screens, but they have geolocation features and social information in the user’s Contacts. Computer workstations have large screens, keyboards, and mice that allow for easy double-clicking and right-clicking. Rather than trying to use all of a device’s special features, it’s helpful to focus on one or two to avoid overwhelming a user. And of course, only use features that truly support the task functionality.

Channels Outside the System: Any interaction that depends on an external system needs careful scrutiny, to make sure that it’s reasonable to expect the user will have access. For example, if a password can only be reset by sending an email, realize that some users cannot check their personal email from work. Mobile devices often do not have easy access to printers. The tradeoffs also need to consider other factors, such as security and reliability. If another system is not reliable, don’t make yours depend on it.

Other “X-Factors”: There are always other, unexpected factors that affect a project’s success. No matter how talented the analysts and architects are, or how well-informed the clients and subject-matter experts are, the end users always have some surprises. The only way to discover these factors is to get direct input from people who will be using your system; the earlier, the better. Also, since users may say they would do one thing but actually do another, try to see them working in their natural environment. Field studies can offer unexpected insights. Early usability testing with prototypes can yield enormous benefits – and help put things into perspective. Maybe you were worried about something that doesn’t bother the users.

Once you have thought about all these factors, list and prioritize them. Which are most important? Did the users mention any “pain points” where your system could help? Are there any factors that can be mitigated? Likely, some factors will only matter to one or two user types. Take a hard look at the tasks. Listen to the users, and try to address the things they are concerned about.

There’s much more to a successful system than merely meeting requirements. Understanding the users’ ecology can make all the difference.

This post originally appeared on Segue Technologies corporate blog.  Special thanks to Matt Kelley for editing and suggesting the term “X-factor.”