Users, Roles, and Personas

The ability to understand a user and their role in a software system is not a new thing to many. We have all interacted with applications and software where there is, at minimum, a normal user and an administrator. Users can’t do all the things an administrator can do and an administrator can do all the things a normal user can do – plus some additional things.

However, when we look at systems in this way all we are really modelling is permissions. Who has permission to perform a task? Who is allowed to perform an action? If someone does something wrong who will moderate this? These are all valid questions about the systems and it’s intended Access Control List (ACL), but captures nothing about the individuals that will be using the system, what their goals are and what things we can do with the interface that will improve performance for the users.

I found myself in this position on a recent project and something I read caused me to rethink my approach. This is what I read:

User roles do not resemble real people nor are they intended to; roles are spartan abstractions narrowly focused on those aspects of the relationship most likely to be relevant to presentation and interaction design. Compared to personas, user roles are a more technical and formally structured model.

By contrast, personas are figurative models rather than abstract models, that is, they are constructed to resemble real users, even down to photos, background information, and personal history. Verisimilitude most likely contributes to the popularity of personas. They sound like people you could know, and over the course of a project can take on a reality that encourages empathy and facilitates thinking from the user perspective. What is more, many people find that the creative process of constructing personas to be engaging and energizing. Personas are fun. (Constantine 2005)

The suggestion here was that when modelling users for a system it wasn’t a case of picking one or the other, role models or personas, but that really the two needed to be carried out together in order to get the fullest picture of how a user would use the system and what they wanted to achieve from the system – not just what they would have permission to do.

I decided that it was time to put this into practice, to give it a go. Was I going to add the persona modelling to my toolkit or not? The system I was working on (and still am currently) is for managing learners in a learner centre. The scenario I am going to use as my example is quite simple: Learners attend the centre in the morning and are greeted and registered by a ‘learner administrator’. The learners then commence on a piece of learning and are assessed by a ‘tutor’.

In this scenario I identified two users a learner administrator and a tutor, the learner was not interacting directly with the system. However, due to resourcing issues at the centres it was important that learner administrators and tutors had the ability to perform the same actions. In essence the two users share one role.

So under the role based model this is fine, nice and simple. I don’t really need to create two user types I can just create one and add a label that just identifies their job title, in case I ever need to reference it somewhere. However, I’d decided to add personas and see if anything changed. Here are my personas:Watch Full Movie Online Streaming Online and Download

Learner Administrator

Sarah is a single mum in her early twenties. Her day consists of checking students in, chasing the ones that haven’t turned up and ensuring that the correct reports are run so that the centre can claim its allocated funding for the learners they have had through the door. Between admin tasks Sarah uses Facebook to see what others are up to and uses an IM client to chat to her boyfriend. She’s a confident computer user who finds the system easy to navigate.


Phillipa is an ex-school teacher. She works as a tutor part-time more to keep her busy rather than because she is dependent on the income. Phillipa has older children who are no longer at home and her husband is a consultant surgeon. Her day-to-day tasks are the assessing of learners, recording their outcomes and helping them to move on to the next piece of learning. Phillipa is focused on the learner and finds the need to record everything on an online system a chore. She only uses about 25% of all the systems functionality but the areas that she does use are used relatively. Phillipa doesn’t mind using a computer for her tasks but likes to have peoples on hand to check with and ask questions when needed.

From this it became very obvious that my two users with the same permissions role were going to be using the system for very different purposes. I had been able to identify this early, rather than waiting for User Acceptance Testing (UAT) and I was able to do something about the design of the system and its interface.

The system has not been fully implemented yet but one suggestion that has come out of this was a configurable dashboard. The dashboard is made up of a number of blocks and pods that either display content or a forms and filters into other areas of the system. The layout of this dashboard would be dictated by the priority of certain day-to-day jobs, allowing for learner administrators and tutors to rearrange these pods to suite their needs. Also, based on the understanding that the tutors were generally older, less computer savvy users I opted to prioritise the default dashboard around their needs so that they would need to do less configuring, allowing the more confident learner administrators to customise their dashboards heavily.

So what did I learn from this exercise?

  • I learnt that an ACL role model isn’t always enough
  • Roles need context. Personas allow us to add context
  • You can create an interface that is different for two users but only charge them for one.
Constantine, Larry. 2005. Users, Roles, and Personas. [online]. Available from:

2011: The Year of Professional Development

I decided this year that 2011 was the year of some professional development. Well, I decided at the end of last year and opted to renew my lapsed student BCS membership for 2011.

Having studied on a BCS approved degree in Manchester, I knew about the BCS’s work and acknowledged them as a group how act as a common forum for both academia and industry. It is the professional qualifications that I was particularly interested in, many in the areas of Business Analysis and Business Systems Development.

I liked the BCS’s definition of CPD, that focused on maintaining competencies:

Continuing Professional Development (CPD) is the organised continuation, improvement and broadening of knowledge, understanding and skills, as well as development of personal qualities necessary for an individual to maintain their competence in order to undertake their duties throughout their working life.

On graduation in 2009 I though I was set, that I had everything that I needed and knew all I needed to know for my career. I’ve since learnt that what I studied was both excellent and dated in equal measure. Some of the tools I studied are no longer in common use and others are no good unless adopted by the whole organisation. In short, it was time to do some more learning.

I hope that there will be some more posts to come on the topic of CPD this year as I look to keep the blog updated with lectures, courses and conferences I attend.

I’m also keen to get along to some of the BCS Manchester events this year. The weekly email I get from the branch is always packed full with some great events and opportunities to get along and meet more like minded professionals. No doubt more posts will follow on this.

Using The Right Tool For The Job

As a business analyst it’s important to know when to use the right tool for the right job. Although there is a wide range of tools available out there, some differ based on the methodology being employed, but often the end goal is the same. To assist in capturing valuable information and ensuring that it’s well communicated to all involved parties.

As I have mentioned in an earlier post, my background is in traditional waterfall projects. The tools of my trade were the lengthy functional specification documents, developed over time thanks to stakeholder interviews, document analysis and observation sessions. While these documents severed their purposes for the projects I was working on at the time, I have come to learn that they are not always the best tool for the job.

I have been faced recently with a number of scenarios where a long functional specification document is not beneficial and does not help to move the project on at all. Some examples of this include when:

Your client is not your end user

This is quite new to me but the firm I work for are often used as an outsourced technical partner. As a result the brief I get is often third hand and the answers I get during interviews are not accurate.Watch Full Movie Online Streaming Online and Download

Your client doesn’t realise the implications of changes

This can often happen for a number of reasons. In my experience it’s because either the project team have not helped set realistic expectations for the project, thus not limiting the scope. Another reason may be that the client is very technically unaware of software projects.

Your client does not know what they want

This is the client that says. “I’ll know what I want when I see it”. We’ve all worked with these sorts of clients, some are great because they allow you to be creative and innovative, and others can be just unrealistic.

The question is, how do you know which tools to use when projects and clients are so different? This will of course be a decision you make based on a number of factors, some of the things I think about at this stage are:

  • Is the PM on the project a good one and will they be concentrating their time on this project or will they be tied up with others?
  • Is there a fixed delivery date? What are the implications of missing it?
  • Am I going to get access to some stakeholders or just a 3rd party?
  • Have I done a similar project to this before? Do I know the domain?

The way that you are able to answer these may affect the tools you chose to use. For some projects it will be obvious which toolset you use, for others it may be a little trickier. In these cases I like to sit with the client and explain the possible approaches and the pros and cons for each. Offering a client the option between a formal document heavy process and an open collaborative process with lots of workshops could be the difference between having a nightmare client and having a champion within the clients organisation who believes in your team and the work you produce.

At the end of the day a BA’s role is to get alongside their clients, elicit requirements and communicate them in the most effective way possible. As long as you’re able to do this, it’s not really relevant the tools you used to do it.

Good Reasons Not to Follow the Process

This made me smile. We’re starting some new agile projects this week and there has been a lot of interest from people not on the project team. Most of this interest seems to be based on the belief that we’re throwing the rule book out and becoming ‘a bit relaxed’ with our development process. I don’t believe that’s the case but this comic strip sums it up pretty well!