4

I am developing a group of personas for a very complex piece of enterprise software. The problem I am having is that there are very distinct types of users, and I can't seem to boil them down to fewer.

Right now I have 10 archetypes. The problem I am having is that the software is very complex, and I am trying to develop new interfaces and abilites to make it simpler. It's becoming confusing because the 10 personas do have fairly different use cases. They are using alot of the same parts of the interface, but are different archetypes with different jobs and goals.

And sometimes, if I make a certain behavior goal "accomplish task Z" which can be a goal of more than one persona archetype.

I am stuck where I can't develop a "person" persona since the actual "actors" might be different, but their archetypical role might be the same.

I am stuck where I don't know how to develop these things. As groupings of people into personas, or into behavioral groups based on goals.

Or, is it just simple enough to say "We've got 10 distinct archetypes who use this program in 10 different ways" and then start to build a UI and process that can accomodate them all, with focused UI in areas that 1 archetype can access as needed without having to muddle through a huge UI built for all 10?

Improve this question
2
  • 1
    It sounds like your problem is now that your software needs to be able to accommodate different users by presenting itself differently to different personas, rather than trying to make one single interface that works with them all.
    – Zelda
    Commented Nov 11, 2011 at 20:47
  • At a certain point, the excessive number of personas should trigger a review of the product to see if it actually should be one monolithic product (vs, separate applications)
    – DA01
    Commented Nov 14, 2011 at 14:46

4 Answers 4

Reset to default
5

Maybe it's time to take your persona work and translate it to roles within the application itself. With role based permissions enabled in an application, you can hide or de-emphasize actions not pertinent to an individual role. This can drastically simplify the interface.

For example, an individual contributor role does not need to see or interact with the advanced security permissions more applicable to an administrator role.

In my opinion, Personas are most useful in the early ideation part of a project, to put real human faces and stories into how a product is understood and planned. Once actual implementation work begins however, roles are a more useful system object for designing great interfaces.

Improve this answer
1
  • +1 for role/permission based views, we have a much smaller application but it has distinct permission levels, views for each permission level are only natural as many people won't use much of the interface (or can't), no sense in displaying menu items they won't and can't ever use.
    – Zelda
    Commented Nov 11, 2011 at 20:46
4

Important thing to consider is that Personas should be a helpful tool. If trying to distill them to less the ten is detrimental to moving forward, then use ten.

With this many make sure to identify who are the overall primary personas, secondary personas, served personas (those who may not use the system or a particular feature, but are served by it. ie. a patient who does not use a medical device but has a stake in the results of how it gets used by the nurse).

Once identified at a high level of these buckets, as you stated you may need to identify for flow A, or feature Z, that this persona is the primary persona and all (or some others are secondary) so that you can optimize the interface, rather than having a huge clubbed together product that has features for everyone everywhere but none can use it or it takes longer because it is not optimized.

As Nadine stated also consider how permissions or roles may help you inform the flows so the interface can be optimized based on what I can do or who I am.

My word of caution on this though; Make sure you keep roles and permissions at the global level, and combine that with access controls for specific areas to round out giving full control. You can give ultimate flexibility by allowing exceptions to cover the rare cases where I have a right everywhere but at this particular location. I've seen enterprise apps that force the admin to apply permissions at every single "node" over and over again, like everything is a exception, and it is not pretty.

Also design in mind that enterprise admins will always want to customize roles, or have users that span across 2 or more roles due to org size or structure. You dont want this user having to "switch hats" to accomplish their goals.

Improve this answer
1
0

Here's some more info on why I am having a hard time:

These 9 people (its 9 now), they all interact at different stages, on different "screens" if you will.

So think like "system architect" who designs the solution, but doesn't use the software. Then there's an engineer, who sets up the software, but doesn't do the day to day work. Then a day to day guy, who runs it all day. Then the people he runs it for day to day. And then the managers of all those people.

So we run into 9 Personas that don't overlap, and all have different views/screens of how and why they need to use this product. There are so many "hand off" stages, each persona might see a different 1/9th of the entire app.

Does that help?

Improve this answer
1
  • It does make sense, and makes things a bit easier as they each have their own "playground" which you can optimize for that type of user. On thing to consider though is why do you need a role like system architect. What complexity in the system makes it require such a specialized role? Why cant the admin who runs the day to day have the interface that makes it simple enough for them to set it up? Make sure if it is this sectionalized that you optimize each of the flows for their primary persona, not everyone. There may be personas who are only ever secondary or served personas. That's ok.
    – Chris Janssen
    Commented Nov 14, 2011 at 18:30
-1

Have 2 types of hierachies: role based views and standard view with all features.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.