Personas in enterprise web application systems

Question

I'm involved in a project that will be replacing a student information system at a post-secondary institution. I would describe the scope of this project as very large, comprising of approximately 200-250 known sub-processes (plus ones we currently don't know about yet), which are grouped into ~70 processes, which are in turn grouped into 14 broad process areas (e.g. Admissions, Registration). This single system will be used by students, staff and faculty across the entire student lifecycle. We are currently entering an initial requirements gathering phase that will last approximately 4-6 months. So this is our opportunity to engage in user research activities.

I believe personas are excellent tools for packaging up and sharing our understanding of target audiences. But almost all literature I've read (books, articles, etc.) talk about personas in the context of single-purpose systems or systems with a low number of purposes. It's not surprising then that much of that literature speaks to minimizing the number of personas you have (e.g. 3-5 distinct personas); that makes sense to me and I'd like to do that.

Yes, we have three core audiences - students, staff, and faculty - but these are far too broad to be useful as design artifacts. As a cursory example, international students have very distinct needs from domestic students. If I had 3-5 personas per process area, I'd be looking at something like 42-70 personas total. Is that reasonable, let alone achievable?

So my question is this: has anyone else here had experience developing personas for information systems with a massive functional scope, and if so, how did you approach persona development? How many did you end up with?

Answer 1

I'm doing one now. I work for an enterprise software. Our software seems to be at least 10x the size of yours, however, we are very aware of our user types (types because there are different types of users). 1) the IT people who admin the software 2) The actual user 3) People who view, approve, comment, collaborate on the work of the user (call them the manager) 4) The stakeholder (basically people who are much more senior level and just want to glance over... they may not even have access to the software, but we can provide them view via specific email link)

I'm creating a persona for each of these 4 types of users. Obviously, I will be concentrating on #2, but I don't want to dismiss the other.

Basically you have to put a couple things into consideration: 1) Do these users use different features (if yes, decide how the features will be separated to each group of user) 2) If the same features, do they use them differently (if yes, decide how many ways there are to use it, roughly) 3) Based on 1 and 2, you can decide how many types of persona there are.

I don't believe persona should be differentiate because the demography are different. But that's my opinion.

Answer 2

I think it is a mistake to categorize your personas by process area. The value of a persona is in creating a quick reference so that everyone on your product team knows WHO the user is. This is why they are typically casual or fun - to make it easier to remember, for example, that 'Bobby Beginner' represents a group of real people who will benefit from extra instructions throughout the system.

Instead, I would imagine that process areas would be a data point you include on every persona. If it won't be useful to come up with a handful of faculty, student, and staff personas, maybe try going with slightly more specific categories of roles: If you had to group all staff members into 5 groups, what would they be? Open card sorting will be useful for this.

FWIW I am working on an enterprise product, and am developing 2–4 personas for each category of user. Right now we are dealing with about 5 user groups.

Answer 3

Aurora Bedford does a great job explaining personas and their creation and application. A key point that may help you is that personas aren't user groups. Essentially they're an average of a set of data points. Think of clothing designers for the mass market. They have to design clothes that can be sold off the shelf, not custom-tailored for each customer. Thus a set of averages are grouped into "sizes". Very few people fit into a size perfectly, but the majority of customers generally fit into one of the given sizes. The number of sizes available depends on the characteristics of the key customer population.

In the same way personas aren't as much a perfect fit for every user as they are patterns that reflect the characteristics of the majority of your users. Careful analysis of quality user research should reveal just how many sizes (or personas) you'll need.

Answer 4

Personas do not need to be limited to smaller-scale products. I would argue that they help with prioritizing features/functions that should be redesigned or even dropped from the redesigned product. Additionally, they can serve as communication tools when discussing design decisions with other project team members.

I recently conducted user interviews/observations and developed personas for an enterprise application directed towards a specific industry that similarly has a very wide user base with very different patterns of use.

My approach was to take the major categories of users (in your case students, faculty, staff) and from there, identify subcategories of users within each major category, like the domestic and international students that you mentioned. The user subcategories were more specific but still bare-bones descriptions of users and their needs, goals, attributes, etc. in list format. You can do this without conducting user interviews; validate and fill in details as you proceed through the research process and communicate with stakeholders.

This exercise can give you a better view of many of the user types you will be designing for on this project and help you pull out a few personas to use as the primary audience for the redesign project. You can focus on the high level goals and tasks that the product needs to fulfill before diving into specific process areas.

Answer 5

The best personas should be viewed as actual (albeit fictional) people and not "elastic users". When it comes to large complex systems with numerous user groups, you've nailed the problem on its head. How do you balance having enough personas for capturing variance within members of a diverse user group in your personas with having a handful of salient personas that the project team can identify with?

The pragmatic view to this problem might be to reframe the question as "How many personas can you realistically build great experiences for?" Then strategically choose the most important subgroups to base these personas on.

Let's face it, for any large projects, it's near impossible for you to design a system with perfect user experiences for everybody even if you have unlimited resources. Put in budget and time constraints, there's no way you can make the system great for all user groups. So let's just acknowledge this fact and choose the important subgroups and focus in providing good experiences for these folks. After all, good experiences for selected groups is way better than mediocre experiences for everybody.

How do you decide which are the most important subgroups? Your stakeholders would be key in making this decision. Involving them in this process helps you to identify areas and people that matters to them. There's also a secondary benefit of you being able to involve them in the process of creating these personas. It helps foster a sense of ownership so your stakeholders buy into personas and through them the entire UX first design process.