As consumerization of the enterprise increases, producers are redoubling their efforts to make their notoriously poor user experience a higher priority. The challenges that confront this genre are unique, however, forcing user-centered designers to change their otherwise conventional workflow.
Three, specific attributes of enterprise software affront the otherwise normal, user-centered design process: (1) Enterprise software is oftentimes “made generic” in order to be customized at the customer site. (2) Despite this, the sheer number of people using enterprise software – and their corresponding use cases – create a wide array of highly-specific requirements. (3) Finally, the people who use enterprise software are usually not the ones who purchase it, you can get details from Technology Evaluation Centers!
Each attribute affects how we, UX practitioners, come to know our users. In this article, I’ll outline two tools that have proven useful for me over the last six years: generic user profiles and user role maps.
It can be hard to get to know enterprise software users
An affront
I was constantly frustrated when I first started designing enterprise software. Product managers would often meet with a customer and return with detailed product requirements. This wasn’t bad, per sé, but the requirements were always accompanied with the caveat that we must also support opposing – but nonetheless equally specific – requirements.
That’s because enterprise software vendors tend to approach problems in a very generic way. For example, a “process-automation system for mobile workers” might use the same building blocks for each customer. One building block might show someone a form; another might be the back-end process the form goes through. End users can have radically different use cases, though, which means a pipeline inspector, a child welfare case worker, an insurance agent, and an IT troubleshooter, for example, could want wildly different things out of this otherwise “generic” system. Because the design process for enterprise software process rarely takes these user differences into account, it usually ends up either too-generic-to-be-useful, and/or too-specific-to-be-easily-customized in others.
So I (attempted to) returned to my roots: My training taught me to begin user-centered design endeavors by creating interview-based personas. However, this methodology didn’t suit the enterprise. Even when I did manage to interview people – 5-8 pipeline inspectors, 5-8 child welfare caseworkers, IT troubleshooters, etc. – the variations between them inhibited any kind of concise summary or generalization.
Generic user profiles
That’s when I turned to what I call “user profiles.” Like personas, they’re based on data. Unlike personas, they’re not based on first-hand, interview data.
I often begin a user profile by looking on job boards on sites such as Monster or Workopolis. I then look at various career pages. These resources provide me with plenty of information about a person’s responsibilities, desired skillset/background, and even reporting structure. The tone of a job posting – as well as the salary range – indicates how difficult it can be to find someone with these skills. Finally, looking through LinkedIn profiles (or industry-specific groups) of people who currently hold a particular job provides insight into their education, their background, their industry’s rhetoric, etc.
Many professionals (like UX designers) frequent industry-specific websites (like UX Booth) that can be uncovered with simple Google searches. For example, there is a “Business Forms Management Association” for people who design and implement corporate forms. There is also an Association of American Archivists. Because these sites are created by and for people with these highly-specialized roles, they can be excellent resources for learning more about them.
After building up some guesses, I interview a few users to test my assumptions. The most important thing that interviews provide is context: Where does this person(’s role) fit within a larger process? At what stage in a process does their work apply? What happens to their deliverables before/after they’re done? Are there a lot of back and forths?
Because it it can difficult to talk to them in an unsolicited way, I also create user profiles of the people who might purchase the software I’m designing: IT managers, heads of purchasing, or finance. After developing user profiles, I take stock of the similarities and differences between them. What do child welfare caseworkers have in common with pipeline inspectors and insurance salesmen? What are their differences? Analysis provides insight into what needs to be at the core of the system and what needs to remain flexible.
Work scheduling is an important part of running any business. Сorrectly allocated worker time can bring projects to their successful conclusion. An optimal work schedule for employees can help managers gain maximum productivity from their subordinates. If you need some help check with this blog post about NCESC
| Role | Scheduling behavior | % of time travelling | Comfort with technology | Wireless connectivity | Nature of tasks |
| Pipeline inspector | Someone else schedules their time | 80% | Novice | Not likely | Repetitive checklist |
| Welfare case worker | Someone else schedules their time | 70% | Novice | Likely | Require many long-form answers |
| Insurance agent | Schedules their own time | 70% | Average | Likely | Requires common documents on hand |
| IT troubleshooter | Someone else schedules their time | 60% | Expert | Likely, may be behind firewall | Requires common documents on hand |
User Role Maps
Enterprise software has to work for a lot of different kinds of people.
The next most helpful tool I’ve found is User Role Maps.
Most enterprise software facilitates a complex workflow across multiple users. For example, in an expense reporting system: someone submits an expense, another person sees and approves it, and yet another person reimburses the originator. Finally, the originator receives notifications and someone in the finance department sees a change in their departmental budget. In addition to this maddening scenario, because enterprise software is usually uniquely tailored for each customer, the software must accommodate a range of these types of workflows.
It’s easiest to explain this is by use of a swimlane diagram:
This diagram illustrates how various roles relate to one another in a workflow. Each role gets its own “swimlane” and, as things are handed off, an arrow links one swimlane with another. It’s very effective communication tool because it provides it explains what different users of the system need from one another in order to provide a useful, coherent user experience.
It is worth noting that this tool is different from classical deliverables in that it describes the flow of a system process rather than the experience of a single individual in that process. This by no means supersedes classical design scenarios and storyboards, which are still an essential part of enterprise software UX.
Organizational charts are a good, complementary tool to swimlane diagrams; useful for understanding the landscape of users involved in a product. Variations in user roles can (and, likely, should) have an impact on a product’s design. For instance, a product that helps a User Experience team share assets with their product team must support several different structures: The UX team could be a separate group reporting up to a design manager; they could be embedded within the product group; or they could also be a self-contained “agency.” Each scenario affects the optimal design/workflow.
Visualize the problem at hand
So there you have it: two of the Enterprise UX tools I keep up my sleeve.
An increasing amount of enterprise software vendors care about their products’ user experience. However, a UX practitioner in an enterprise setting is faced with the ultimate challenge of only knowing about their users by proxy. By tweaking some of the standard UX tools it is possible to strike a balance between providing a generic view of the landscape of users, while at the same time having specific enough information that it is possible to design the best application.