User-centered Design Tools for the Enterprise

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!

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.

Fish spread across two fishbowls.

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.

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

A multi-racial group of people.

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.

About the Author

Jana Sedivy

Jana Sedivy is a user experience consultant who has spent a lot of time elbow deep in enterprise software guts. She is deeply uncool in a variety of other ways as well. She blogs at http://www.authenticInsight.com and tweets at @janasedivy.

Write for UX Booth

Contribute to UX Booth
Contribute

Contribute a guest post to UX Booth and let the community know what's important to you!



Comments

  1. I like these strategies which could make the life of developers easy. The control flow diagram is similar to use case diagrams of an software.

    • Yes, exactly, you make an excellent point. I find these kinds of diagrams are extremely useful in discussions with the engineering teams. Engineers instantly “get it” and it helps to make sure the entire team thinks about an end-to-end process.

  2. Joseph Rivera January 26, 2013

    I disagree with your statement that personas are not first-hand interview data. Personas must be based on factual research data in order to be an effective tool for UX design. Otherwise, your persona process is completely wrong to begin with.

    • Hi Joseph, Thanks for your comment – sorry for the delayed response. I agree that personas are a great UX design tool and that they need to be based on solid data rather than just assumptions. The problem in enterprise environments is that you are often designing a “generic” solution that will be highly customized at the customer site. By “highly customized” I don’t mean just different colors and button sizes. I mean that it will be customized to a different workflow, in wildly different market verticals. It is just plain not practical to create interview-based personas for all the possible permutations.

      What I’m striving for with user profiles is an approach that is still based on data – but secondary data, rather than first-hand interview data – that can be compiled in a couple of days rather than a couple of months. It gives the right level of specificity for enterprise projects, and allows you to map out all the different kinds of roles that might use the product so that you know where you need flexibility in the system.

Related Posts