The Complexities in our Digital Identity
In a recent Documentary on RTÉ TV (the Irish national broadcaster) about Annacarty Barracks and its central role in the Irish path to freedom & independence, Mick Dromm (at least, I think that was his name!), who was one of the primary Archaeologists on the Project, said
“AS A NATION, AS A PEOPLE, WE ARE MATURE ENOUGH TO BE OK WITH THE
COMPLEXITIES IN OUR IDENTITY”
Now, while that quote relates specifically to the complexity in the modern Irish national identity, it did start me thinking about the whole concept of complexities in our individual personal identities. Every one of us is a unique combination of the different identities we portray to the outside world, to our friends & families, to our work colleagues, to our Customers & Clients, to our most intimate personal connections and – frankly – even to ourselves.
Enough of the Philosophy and Psychology, though: what does this have to do with Digital anything, Online anything or even Business Analysis…?
Well, it’s all about Personas.
You are most likely represented by a Persona in the WordPress world right now (assuming you’re reading this on WordPress). You’re a ‘Reader’ persona or a ‘Content Consumer’. I’m likely represented in there as a ‘Writer’ or ‘Content Creator’ or ‘Blogger’ (or whatever terms they use for this Persona). Of course, I can also be a ‘Reader’ and you can also be a ‘Consumer’ depending on the role you’re playing or whatever action you’re taking. So, in fact, we’re both multiple Personas. Not multiple Personalities (like Schizophrenia or whatever!), but multiple Personas.
Now, I’m not going to start explaining all about Personas (phew…! for both of us). There are thousands of articles online that do that better than I can, from all sorts of Perspectives (UI and Ux Design, Marketing, Product Feature Development and so on). What I’m interested in is why these otherwise-intelligent Experts and Stakeholders who are at the forefront of the Digital Revolution seem to want to reduce our multiple and complex identities to a single value and why a Business Analyst – especially in an Agile context – should care.
Personas are Abstracts. They are easier to talk about, visualize and conceptualise. Reader, Writer, Customer, Buyer, Seller and millions of other labels across the Digital and non-Digital world help product and system designers figure out how best to facilitate their intended users with the focus (initially, at least) usually on minimum effort for maximum effect. If you’re working on a system and nobody from the Business can categorise the different types of users – even if it is only Visitor, Member and Admin for something like a Web portal – this might be an indication that not enough attention has been given to who is going to use the Product and how they should use it, likely resulting in something that’s either all things to no men, or no thing to all men (to mangle a well known phrase). That would be a bad result. In Agile terms, that’s also an indication that someone screwed up early and big but also that nobody noticed. Or maybe everyone noticed but didn’t care or feel comfortable enough challenging the Business. Again, in Agile, that’s a bad sign.
Sometimes, Personas are given names, brief Biographies and even addresses. Sometimes they go much, much further. Huge numbers of Ux Blogs, Articles and Tutorials suggest everything from naming their (fictional) pet to including their (fictional) shoe size. For example, https://www.justinmind.com/blog/user-persona-templates even suggests
Include psychographics – behaviors, attitudes, opinions, and motivations are what make your
personas human.
To be fair, those who swear by the use of ‘lifelike’ Personas insist that this makes them more real and this makes it easier for the Designer to visualize them. Maybe it does for those who are comfortable using Personas – and talking about them in Meetings and Design Sessions – but for those who are maybe less accustomed to inventing fictional characters and then designing Products for them, it’s perfectly OK to have a very abstract Persona (like Reader or Writer) or a sort of intermediate – an unnamed but quite specific character that allows anyone in the Team to create their own visualization for.
In one Project, where the brief was to design a Reporting platform to facilitate newly published Legislation for Charities Regulation, and where the only ‘requirements specification’ available was the actual Legislation, Personas were used to represent the primary Users. Of course, they would be professional Charity managers and administrators, Regulators and their Agents, Public consumers of published data. When designing the requirements for this platform, however, a conscious choice was made to target a Persona described as:
A little blue-haired old lady in County Kerry who knits Sweaters to raise money for the local
kid to go abroad for specialist treatment.
Blue Haired Old Lady – Mrs Slowcombe of ‘Are You Being Served’ http://www.bbc.co.uk/radio4/womanshour/01/media/slocombe247x165.jpg
Is this too complex, too narrow a Persona? Depends on the intended outcome of using that Persona. In that particular project, the goal was to make it as easy as possible for someone who had no interest in, no real understating of and likely no experience of submitting Annual Regulatory Reports to the Charities Regulator. So this Persona served a very specific purpose – to focus the design on making the Platform very, very simple to use. And therein lies the point: if it serves a useful Business purpose, it makes sense to use Personas. If it only serves the ego of the Marketing Manger or Ux Designer and adds no value (or, worse, adds a mental block for others!), it doesn’t.
OK, so let’s say the Business (and maybe more specifically the Marketing Department or similar) actually have got their Perosnas all lined up, fully categorised into 128 variants – 64 male and 64 female, equally split across all races to be politically correct. Is that better? As with all things Agile, it depends. But in reality, and in most cases, it’s probably worse to have too many narrowly defined Personas than not to have any at all. Again, as with all things Agile, the question should be: what value does this bring?
- Is gender relevant? Well, for an online clothes retailer it may very well be, if they believe men like to shop differently to women, even online. Or even if they think men would react better to a different color scheme. So, it depends.
- Is race or skin color relevant? For a Cosmetics manufacturer it may very well be relevant if they decide to show their logged-in customers Products that suit their skin tone. So, it depends.
- Is age relevant? Well, for an Insurance company or Pension provider it certainly is. It also is for anyone trying to sell to the younger generation than those selling to an older, less Tech-savvy generation. So, it depends.
- Is left-handedness relevant? Well, for a… you get the idea. It depends.
For every data point that is used to separate one Persona from another, the Business should ask: what will we do differently for one Persona than another based solely on this one data point. The danger of too many data points is simply that they can over complicate while adding little or no value. In Agile, that’s not good.
