Eggbox in Transit - soon to be settled again!

Category: Professional (Page 1 of 3)

Pertaining to UX, UI, software and other stuff I get paid for

An idea – Q-Methodology in UX?

Why I think it could be useful and how it could be used

First, a disclaimer.

People can and do spend lifetimes working in this area. I have not done so. I am almost certainly cutting corners or just flat out being wrong on the internet. But I think that what I’m turning out is useful for a UX context. I may be doing a disservice to the techniques by dumbing them down or removing some rigour that would be present in a more proper application within the context from which they originate.  For this application, this is acceptable.  For other applications – particularly those relating to Health Psychology, you should seek better advice.

If you’re after a UX research technique to help you understand subjectivity and viewpoint, this might be helpful or interesting to you. If it is, then we’re good – but you might benefit from reading a little more about it.

What is Q-Methodology?

It’s a qualitative research technique, originally from psychology (particularly health psychology) which is used for understanding subjectivity. While it is a qualitative method, it produces numerical data, leading to it sometimes being referred to as a qual-quant methodology.

It helps reveal both consensus and divergence from consensus within a group of subjects. It characterises both that consensus and the divergence from it.

What is subjectivity?

Consider subjectivity as an opposite of objectivity.  If you are objective, you have taken your viewpoint out of the equation.  If you have not taken your viewpoint out of the equation, then you are exhibiting subjectivity.  Objectivity is an absolute, but subjectivity is not – it is individual to a person.  Understanding subjectivity means understanding a user’s attitude regarding a topic.

Why is understanding subjectivity useful to us?

When we are talking to users, we want to be objective, but we want them to be subjective.  We want to understand what their subjectivity is, what it means to them and what it should mean to us.

Consider where you have sent out a survey and two users have returned almost identical responses but when you interview them you discover that their identical responses are hiding wildly different concerns, interests or goals.  They might be doing the same things with different motivations, or they might have encountered the same problems but have felt wildly different impacts from them. They might both say that one flow is bad, but have very different reasons for thinking so.

The difference in these situations is often not in what they needed to do or how they achieved it (or failed to), but in their subjectivity – their attitude and viewpoint.


Because I heard of this approach from a Health Psychology professor – albeit in an ad-hoc, unofficial fashion – I’ve researched it using sources arising from that field.  I’m using (or perhaps abusing) Health Psychology practices and terminology, which is not always the same as is used in UX or software related fields.  So, here’s a bit of a glossary:

Cohort – The body of individuals being interviewed.

Concourse – The wider body of discussion – this could be made up of notes, recordings and quotes from interviews, excerpts from online communities, support tickets or any other body of user-created statements.

Statements (aka. Q-Statements) – A representative sample set of short phrases, drawn from the concourse.  The subjective true-ness or right-ness of these are compared via a Q-Sort to understand subjectivity.

Subjectivity – see the introduction.

Q-Sort – A specific form of card-sort exercise, using the statements and performed individually with some or all of the cohort.  This is not the same as a QSort in software development terms, which makes googling a little bit harder.

How an interview series works

A quick summary

  • Build a concourse or find a pre-existing one
  • Prepare statement cards
  • Prepare the q-sort matrix
  • Run the interviews
  • Analyse the data

Step one – build a concourse or find a pre-existing one

If there is no pre-existing concourse, then a two-part session is possible – the first part should be a group discussion with several subjects about the matter under discussion, from which a set of representative statements can be drawn.

If interviews have been conducted on this subject in the past, notes or recordings from those may be used, although it is entirely possible that the subjectivity of your new interviewees may not match that of those interviewed previously.

Step two – prepare statement cards

The facilitator should prepare a set of statement cards, which should be drawn directly from the concourse.  The number of statements can vary a lot – a smaller set of statements will lead to a faster interview process, but you also may not gain as much insight.  You should aim somewhere between 10 and 100 cards.

  • Statements should be phrased as declarative statements. Some examples:
    • “It is the case that…”
    • “I must be able to…”
    • “I can…”
    • “It is important that…”
    • “It is good when…”
    • “It is bad when…”
  • One statement per card, one card per statement
  • The cards should all be uniquely numbered.
  • The same cards should be used in each session in a series

When creating statements, it is better to start fresh, but you could take typical “As a [p], I can do [x] to achieve [y]” story titles and rephrase them as “I can do [x] to achieve [y]” or even two statements – “I can do [x]” and “I can do [y]” separately.

The rephrase to remove the role is important, as including the role would affect how the statements are sorted.  This would provide a better-than-nothing set of statements to work with.

Likewise, separating the reason or end goal from the specific actions taken towards it lets you understand where subjects differing viewpoints may result in different actions for the same goal, or the same action for different goals.

Step three – prepare the Q-Sort matrix

At the start of each interview session, the facilitator should prepare a Q-sort grid.  The configuration may vary, but the following will usually be true:

  • It is a funnel-shaped symmetrical grid able to accommodate all the statement cards
  • There will usually be more than three columns – typically five, seven or nine.
  • The columns will have different heights to accomodate different numbers of cards each.
  • The central column will accomodate the most cards, outer columns the least, with a steady decline moving outwards. Often modelled on a normal distribution.
  • The columns will be labelled across the top and given a value.
Number of columns Example Leftmost label Example Rightmost label
7 Least true / most false (-3) Most true / least false (+3)
5 Least accurate (-2) Most accurate (+2)
9 Strongly disagree (-4) Strongly agree (+4)

Step four – run the q-sort interview sessions

  1. Run a one-on-one q-sort interview for each subject in the cohort
  2. The facilitator should explain that the exercise is about understanding viewpoint, and as such there are no right or wrong answers. The statement cards are also a talking point and may be discussed or talked around. These sessions can be recorded as if they were any other interview – the cards and sorting exercise provide a framework for the interview as well as being an act of research on their own.
  3. The participant should sort the cards into the matrix, depending on how well the cards fit their understanding, interests or needs. If the session is being recorded with audio-only, the facilitator should ensure that the cards being discussed are each read aloud, and their eventual placement is made clear for the recording.
  4. After each session, the facilitator should document which cards were placed into which columns. They should do this by creating a record for each participant. That record should be a list of {card number, column score} pairs.


Step five – analyse the data

After the interviews, the facilitator can perform some simple analysis with (for example) excel.  There are several useful things which can be produced:

Heatmap – consensus

  • create a square grid with card numbers on one axis and column values on the other.
  • Fill each cell with the percentage of users who placed that card in that column.
  • Convert numerical values to a colour shade to produce a heat-map.
  • Use the heatmap to spot commonality or difference of viewpoints, and therefore identify consensus or an absence of consensus.

Fingerprint – individual viewpoint

  • For each participant, create a rectangular grid with card numbers on one axis and column values on the other.
  • Fill any cells where a participant matched card number and column number.
  • Overlay one fingerprint over another to identify commonality/difference of viewpoint.

Heatmap / Fingerprint comparison

Overlay a Fingerprint over the overall heatmap to identify where it varies or matches any consensus.

Fingerprint grouping

Identify similar fingerprints within the cohort and use these groups as a basis for persona creation – similar fingerprints imply a similar viewpoint.

  • Treat each fingerprint as a vector, determine the “distance” between fingerprints by subtracting one from the other.
    • The shorter the distance, the closer the subjectivities.
    • The greater the distance, the more different the subjectivities, and the greater likelihood that they should be different personas.
  • Two users might have same goals, same day-to-day activities, but have different subjectivities. This would indicate they are a different persona who happens to be in a similar role, but who operates in a very different way with different priorities or in a very different space.

Further analysis?

Data scientists and statisticians can then apply tools like Principal Component Analysis or other Factor Analysis to the results if they feel the need to do so. This may help with further definition of the most significant differences between uncovered subjectivities.


A mini-rant about “Delight” abuse in UX

I started writing this blog post over a week ago, but it stalled as I was hitting a bit of a mental wall with it. But then I saw this tweet, which summed it up nicely.

Just add “Delight” or “Delighters” to the bottom of that list. I’ve been feeling a lot of backlash from the UX world against them, which isn’t vastly surprising given the amount of complete hogwash which has been vomited forth about them.

But it does bug me. It’s another example of people who don’t really understand domain-specific terminology latching onto it, unwittingly abusing it… and then the “experts” deciding to blame the terminology and models instead of stepping back and thinking “how can we help people grok this better?”

The Kano Model is at the core of this terminology, but Maslow’s Hierarchy of Needs is a handy reference too.

The Kano Model

The Kano Model, Showing Change over Time.
Image By Craigwbrown (Own work)
CC BY-SA 3.0,
via Wikimedia Commons

But Dr. Noriaki Kano didn’t use the word “Delighter” originally, as far as I can tell.  The paper it’s all based on [Kano, N., Seraku, N., Takahashi, F., and Tsuji, S. 1984. “Attractive quality and must-be quality,” Journal of the Japanese Society for Quality Control (14:2), pp 147-156] uses “Attractive Quality”, and is mostly focussed on the following:

  • Attractive qualities give a satisfaction boost if they’re present, but their absence doesn’t cost anything.
  • Performance qualities give a satisfaction boost if strong but have a satisfaction cost if they’re weak.
  • Must-have qualities lower satisfaction if they’re not present, but their presence doesn’t give a boost.
  • Features move down that list over time. Attractive qualities gradually become performance qualities and then must-have qualities as they become more common and more people just expect them to be there.

I think the words “Delight” and “Delighter” were brought in later as a way to clarify what is meant by an attractive feature, but I could be wrong about that.  I’ve been unable to actually get hold of the original article to check – so apologies to Dr Kano if that’s incorrect.

The Problem

Before its use in UX land, I understand that the word “delight” in this context came from the hospitality business.  It came from the idea that just doing what was expected wasn’t enough to stand out.  Nor was doing all the typical “we’re a classy hotel” optional extra things because all the other classy hotels did them too.  You had to do everything which was expected by default, then do everything which might be considered as optional and then do something extra – something above and beyond.

The “bit more” on its own doesn’t cut it.  You’ve still got to do all the stuff before it. If you haven’t covered off the baseline stuff, it’s wasted effort and adds insult rather than delight.

It’s like building a ladder with only a top rung: of course it’s useless. It shows a fundamental misunderstanding of both the goal and the Kano Model. But that ladder is exactly what I keep seeing built, and then I hear complaints that blame the Kano Model and its delighters for it.

A fair number of people just saw the words “delighter” or “delight” and latched onto it, focusing on trying to create delight to the exclusion of all else. Because that always ends well.

The problem is that if all you have are delighters or attractive qualities, you’re in a situation where you have none of the other stuff.   I can assure you, whatever your designing, there will be some of the must-have qualities you are missing.

Think about the pyramid view of Maslow’s Hierarchy of Needs (with or without the popular additional “wifi” layer – this works either way).  This is a somewhat related idea.  That hierarchy works on the basis that the lower down needs must be satisfied before the higher up needs become meaningful, stable or sustainable.  Maslow’s idea was that the lower layers must be fully met before the higher layers can be achieved – without them, the pyramid collapses.

Origin unknown – I found it here:

That idea is baked-in with the Kano Model too.  The satisfaction gained from one or two delighters or attractive qualities being present will be massively undermined by the absence of all of the must-have qualities and performance qualities.


Fancy wine with a personalised label and a box of chocolates might be a nice touch in your hotel room, but if the room is covered in faeces and crawling with cockroaches then it isn’t going to make your stay delightful.  It’s going to be insulting.

It’s only a delighter when placed in the context of everything else that might be considered having also been done!  Without that context, it’s just an inadequate attempt at a bribe.

But what really gets my goat…

It’s not really that exclusive focus on delight that annoys me, although it certainly doesn’t help.  That’s just the problem of a buzzword-heavy discipline which, on a superficial level, looks like an easy way to make a buck.

The UX industry will always attract people who’ll exploit the gullible by throwing buzzwords at them in exchange for money. They bug me, but what bugs me more is the misguided backlash from the people in the industry who should know better. The backlash against the models and techniques that are being abused and misapplied, whose names are being taken in vain.

I’m starting to see and hear UXers in positions of authority denigrating the Kano Model for being focused on the frivolous idea of “delight” to the exclusion of all else.

I don’t like it when people who don’t know the origins or meaning of domain-specific terminology muddle it with casual language.  It leads to a watering-down of ideas.  But I understand it and understand why it happens. You fix it by explaining and sharing understanding.  At a minimum, you just suck it up and cater for the terminology difference by using the appropriate terms for each audience.

But the backlash against the model itself because people don’t bother to properly understand it? Nope. Let’s just stop doing that, please.

Let things be things

The Kano Model is a model.  It’s a simplified abstraction.  It’s a useful model, but that’s all it is. While it’s useful, it’s not a world-encompassing ideology.  It’s a tool. I strongly suspect it didn’t come around to your house and force it’s filthy delighters into your face, shouting “DELIGHT! DELIGHT!”.

People who didn’t know better did that bit (not literally, I hope).

We can train most of those people out of abusing the models and terminology. We might even end up with more good designers as a result. But if we blame the models and terminology and steer people away from using them instead of understanding and explaining them better, we might as well give up and all go home.

Let’s not do that. Let’s just learn, use and teach our tools better.

Recent UX Reading – Build Better Products

After listening to the “What is Wrong With UX?” podcast (from Kate Rutter and Laura Klein) for a while, I recently picked up the book the hosts have been relentlessly shilling (and writing or contributing to) since the dawn of time start of the podcast.

But to start with, before I get onto the book (Build Better Products by Laura Klein), I’ll mention the podcast a bit more.

They introduce it every time as “The podcast where two old ladies yell at each other about how to make products suck slightly less”, and typically conclude by complaining about how they’ve run out of booze.

If you’re a UXer who likes talking about UX a) in a frank, open manner and b) in a pub, this might be a podcast for you.  They have a cynicism which is oddly refreshing in this particularly shiny and glossy field, and I’m pretty sure I’ve been to workshops presented by one or both of them at some point.  One of them probably helped me get into sketchnoting… which you might have noticed included in some of my other posts.

So.  The book.

It’s a no-nonsense, clear and straightforward guide to UX processes, which (for a nice change) acknowledges that some of us are in-house UXers working in the enterprise space, and so have to live with our work for years (decades!) in a way that just doesn’t happen the same way in the consumer world.

There are parts of if which I’d describe as leaning towards “my first UX” or “teaching grandmother to suck eggs”, but they’re wrapped in a mountain of useful advice and sane ways to make some fairly weird and wonderful UX practices actually make sense to business users and developers.

Really, I ought to wait until I’ve finished reading the book before blathering on about it, but this time I decided not to.  Why?  Because it’s that good.  Because not only does it make sense to me in the UX field, but it’s also written in a clear and concise way that managers, directors and developers will understand and find useful as well.

It’s not about putting some UX next to your product, or trying to smear it on at the end.  It’s about baking UX design thinking in throughout the life-cycle of the product.  From identifying user needs, through promoting behaviour that supports and addresses them and on to validating assumptions, measuring outcomes and then iterating based on what you find.

I’ll be making sure a copy gets added to our office library, and quite possibly demanding that our product management team, senior developers and architects get locked in a room until they’ve read it.  If you’re a UXer who works with other human, read it.  It’s a breath of fresh air. Written with the same combination of capability, realism, pride and self-effacing humour that the podcast has, it manages something that most UX books have utterly failed at: It provides an enjoyable and memorable reading experience.

If you work with a UXer and don’t really know what they actually do or why they keep asking weird questions and going off sideways from problems, you could do a lot worse than picking this up.

Antagonism Required

Two Bad Words

Nothing turns a design to crap faster than a certain two words.  They are the bane of my professional life. They are a signifier that work I’ve done is either the wrong work, the right work done at the wrong time or the right work done for the wrong people.  They are, without fail, the worst words to hear in response to a request for your work to be reviewed.

The words in question?

“Seems Fine.”

Give a shit

There are other words that can be similarly bad, but “Seems fine” basically boils down to “this was not important enough for me to give any time to”.

If it’s a design review, and you’re seriously and honestly not able to see any problems then shout it from the rooftops.  You have found the perfect, shining unicorn. Hand that designer all the money in the world and tell everyone else to retire because they are done.

If you are involved in a design process, be involved. Merely being present is not good enough. In the event that it’s not so perfect that a life of perpetual ecstasy would disappoint, say something.

If you don’t give a shit, you’re in the wrong place.  I don’t care what job you actually do, but if you don’t care enough to do more than phone it in then be up-front about it.  Remove yourself from the process.

Push Back

If you do give a shit, then push back.  It’s not even about disagreeing.   It’s about making sure that the design stands up.  A rough design that you agree with still needs to be challenged, otherwise that rough design is what you’ll ship.

All design thrives on creative tension – you can usually produce “good enough” without it, but is “good enough” all you want? Do you really want to ship your designer’s first draft?  They sure as hell don’t you to.


A request for a design to be reviewed is a request for one of the following:

  • Information to inform or further constrain the next iteration of the design
  • Information to inform the complete restart of the design within different contraints
  • Confirmation that the design is the best it can be, given the established constraints

A first draft is more interview technique than design

I always consider my first-draft to be an interview technique rather than a design. It’s a means to gather more information about what’s needed and refine the direction, rather than an actual attempt to deliver a solution.

The sacrificial first-cut is a long established way to tease out other people’s ideas. People are a lot more able to articulate what they’d rather see than they are to articulate what they want in the first place.

If you don’t push back, then you’re committing to a shot-in-the-dark.


Design is all about constraints. Without constraints, all problems are trivial and solutions are obvious. Design, as a process, works best when the current result of that process is challenged and pushed to improve.

One of the best ways for that push to come is from tightening and refining the constraints – from speaking up when something is not good enough.

If everything is good enough from the outset, you’ll never get to actually good.

Summing Up

If you take one thing away from this post, take this:  If you’re meant to be involved in a design process, be involved or acknowledge that you’re not, acknowledge what that means and step away.

One up, One Down

Half finished posts from the unpublished archives:
I’m pulling this post out and making it live largely unedited.  This is because it’s been sat there a fair while and I thought the idea deserved to be put up, even if the post isn’t ready for prime time…

Anybody who’s worked in software know that one thing is virtually impossible to get: Positive feedback.  You’ll get negative feedback up the wazoo, but meaningful positive feedback is a right bugger to get hold of.

So how about we start asking for it more?  We’re always very good about inviting people to tell us what we’re getting wrong, but we’re also terrible about asking what we get right.

Why don’t we have a bug reporting tool that’s specifically designed on a “one up, one down” basis?  The idea here isn’t that you can’t submit bugs without giving praise too, but that giving meaningful, useful positive feedback gives the bugs you raise a higher priority. Yes, folks, I’m talking about bribery.

Raise a lot of bugs without giving any commentary about what we’re doing right?  Well, you’ll still get help, but we’d prefer it if you engaged with us on a less superficial level.  Tell us what you like.  We probably already know about the stuff you hate – we probably hate it too, but can’t get it on the table to fix it.  What we’re less clear on is if you’ve used the bits we don’t hear about.

As things stand, If you’re not complaining, it could go either way.  Either things are not bad enough to make you complain, or they’re so bad that you’ve stopped using those features and so have nothing to tell us about them.  We can’t know for sure.  “We’re pretty sure it’s not bad enough to make people complain” isn’t a great marker for design to aspire to.  There’s a big difference between “we got that right” and “we either did okay or did so badly nobody’s using it”, and being able to tell that difference would be nice.

Some Responses to “what does a good enterprise UX look like?”

My previous post generated a bit of commentary on one of the sites it syndicates to, so I thought I’d post them up here and follow up with a bit of response.

From Themadone:

“I think my answer would be that it should not feel like you’re trying to roll a large rock up a hill. With the obvious associated problems of something going wrong and you ending up at the bottom with a large rock on your face. Or finding the rock is stuck on something that you can’t readily see or do anything about.”

From Nojay:

“For various reasons my workflow involves an older graphics editing package, an esoteric OCR package, several web apps, another graphics package for review and testing and a batch image processing package for final release. I have to remember that “Paste” is Alt+F+W or [Shift+Insert] when editing, for the OCR package it’s [Ctrl+B] and for review it’s the classic [Ctrl+V]. Enterprise software MUST NOT work like this.”

I’ll acknowledge that I’m quoting a bit selectively in places, but can you spot the commonality between those responses? It’s been common with the verbal responses I’ve had too…

There’s a strong focus on what a good Enterprise UX isn’t.  The field is so bad that just not sucking is enough to be seen as a good experience.  That’s a pretty low bar.  It’s like having your personal best at the high jump being “didn’t tunnel underground”.

A couple of other responses did stray away from the negatives towards the positives – which I wasn’t really expecting.  I did my readership a disservice – which was nice to discover.  Some more selective quoting:

More from Nojay:

“That implies a consistent interface between apps with seamless switching and information transfer.”

From Katlinel*:

“Imperceptible? That is, the software enables you to accomplish the tasks you need to do, without getting in the way of those tasks. The software should facilitate this and not provide stumbling blocks that impede the user.”

From Cryx:

“At the moment user experience is often done like going to a convention. You open the door and there is a hubub of options. You may have a guide to the event, but you have to pick your way around to the areas of interest, and slowly fill up your bag with the info you want.”

“It should be more like you are the VIP. You say ‘I want X done, by X time’ and people scurry away and work out the best way to make it work for you. They come back and present the plan/information to you. They don’t go on at length about all the work they did, and keep asking you small questions. However if you bring your laser focus to a task they can tell you each step, and will let you modify things quickly and without fuss.”

From those it becomes clearer.

Good Enterprise UX plays nice

No enterprise software application exists in isolation – everything is just a step in somebody’s workflow, and needs to fit into that workflow.  Each enterprise application is there to fill a step, or some steps, or every step of somebody’s workflow… even if it’s not providing an end-to-end workflow, it’s still part of one and it needs to play nice with its neighbours.

It becomes clearer that enterprise software needs to not be a bottleneck or a hurdle.

Good Enterprise UX works for you

I particularly like the analogy in the final quote – about enterprise UX needing to be more like a concierge or a team of employees, being ready with what you need when you need it… but also serving a large number of users. I’d like to take it further, though – for common behaviours, I don’t think I should have to ask.  The software should know who am and what I do – all of that information is available within an enterprise anyway.

If it’s being like a concierge, it should be a really good concierge who can anticipate my needs and have prepared some information ahead of time.  I should be able to start my interaction with that software by being greeted with a clear picture of what’s going to be relevant in that interaction, to pick and choose from and add to if needed.

So, the comments exercise this time is slightly different.

In your day job, you almost certainly use some kind of enterprise software.  If the UI for it was a very, very good (human) concierge or PA, what would it be doing for you?

Please let me know either as comments where you see this post, on the original blog post at or however you like on social media – but please tell me where so I can read!

What does a GOOD enterprise user experience look like?

It’s been a fair while since I posted on here, so I thought I’d try kicking off again with a question, and then see what comes back.  But, because not everyone works in the same field I’d better define some terms first:

Enterprise Software is software designed to serve the needs of an enterprise (typically a larger business) rather than an individual, although individual human users still have to use it and may have multiple different jobs to do which require them to use it.

User Experience is what you have when you are one of those individual human users being forced (it’s rarely a choice you’d make on your own) to use it.

So, on to the question:

What does a good enterprise software user experience look and feel like?

Answers in comments please. Or on your own blog or social media of choice, but let me know about them here.

The Rise of The Shadow Persona!

I feel is is my duty to warn you that you have been infiltrated. Your product (or service) has an interloper. There, lurking in the shadows behind everyone else. Clothed in darkness, wrapped in silence, there lurks the mysterious shadow persona.

You can’t see them, but you know they are there. Dark figures, moving behind the scenes and manipulating things from out of your line of sight.

They never go so far as to touch your product itself, though. They’re far to clever or important for that. But they manipulate and influence those who do. You’ll never see them, but you will hear talk of their presence. They’ll come for those you do know, stalking them quietly when you’re not around. Putting demands on them, or twisting them to do things they wouldn’t otherwise do. Or those you do know will be constrained by their whims, unable to act in accordance with their better judgement.

Whilst these quiet, faceless creatures never touch your product themselves, you’ll know them by the marks they leave on those who do. From the stains and the scars.

If you wish to truly understand those you know, seek out the unseen figures who whisper to them from terra ingognita. Get to know their ways, as their impact is often greater than is otherwise apparent.

In Plain English

In User Experience design, the idea of the persona is well understood – well defined examples of those who use a product. But a few years back, I encountered a situation where we needed to design for a user who would never use our product.

At the time I called this a “Hidden Persona“, “Indirect Persona” or “Shadow Persona“.

One of our known personas needed to work with this person to extract relevant information that they could then use to work with our software. That conversation, which happened out-of-sight of our product, was a key interaction for the feature we were designing.

But it was a difficult interaction to nail down. That “Shadow Persona” was somebody we couldn’t ever really know, and we could never interact with them directly through out product.

Indirect Interactions

Historically, we’d always considered the information gleaned from that difficult, formless discussion to be the starting point for the job this feature was designed to achieve. The problem was that nobody knew what information would be useful to glean until after that conversation, and the person embodying the hidden persona would be quite unlikely to know any better.

There would usually be several rounds of back-and-forth before a rudimentary language and understanding could be reached, and meaningful exchanges could occur.

Typically, this left the person embodying the known persona frustrated and the person embodying the hidden persona annoyed. As you might imagine, that didn’t help achieve good results and a steady working relationship.

So we had to think of a new approach.

Start With An Icebreaker

We figured that a good place to start would always be with a gift. Not just a fruit basket, a bottle of wine or a box of chocolates (although those might help too – don’t rule them out!) but an offering that says something about how to go forward. A sign that our known persona cares and is trying to do something useful.

In this case, we treated our shady figure as another persona. A shadow persona, lurking behind the one we can see. They’ll never touch our product, but a smooth interaction with our product depends on them all the same. We learned who they were and how they fitted in.

So we build an offering for them. Something that our known persona could use to introduce themselves and start the ball rolling quickly, without taking much of the shadow persona’s time. In this case, it went through some iterations, but ended up being a printable or email-able report of the few things that were already known prior to the discussion, with spaces and questions included to find out more and feed it back in to the process.

This report also included conversational affordances – things that announced reasons to speak, and reasons why the information was relevant. Catalysts for discussion. Icebreakers. That sort of thing. Things that would let the shadow persona cut to the chase and see value in what was being done. Things that would hint at what information would prove useful and what wouldn’t, and to let them provide that information painlessly.

Make It A Conversation, Not A Monologue

What’s more, the report provided information in a format designed to be added to through notes and comments – ways to capture the conversation quickly, easily and without repetition or clutter. We then provided ways for our known persona to collect this information together and encode it back into the product.

Once that was all included, the early conversations could happen without the frustration and annoyance that had previously made them painful.

Rethink Personas – Learn To See The Invisible

So, if you’re going to take something away from this post, make it this:

Stop making personas just for anyone who uses your product.
Instead, start making them for anyone who impacts the usage of your product – even if they don’t use it themselves.

Design Iteration isn’t just about the good ideas…

At work, I keep hammering on to people about how design is an iterative process.  How it’s not something that you do once at the start of a project and then never touch again.  Mostly my colleagues seem to get that and run with it, but occasionally I get farmed out to elsewhere in the company, where I find stark reminders of how much progress the team I usually work with have made.

The big eye-opener is to work with people who’ve never had the opportunity to learn about good design or how to shape a user experience.  Going right back to the basics like that reminds you of a few of your core ideas, and forces you to find new ways of expressing them.  On my most recent such excursion, I became a lot clearer about an idea I already knew and understood:

Good design is as much about the bad ideas as the good ones.

Bad ideas happen.  There’s no way around that.  They happen, and they chew up time and resources before they either finally get identified and cut away, or they get munged around until they’re workable.  In the really bad cases, they linger for a long time and chew up all that’s good about a project, leaving only an enthusiasm-free husk.

I’ve generally found that the bad ideas that hang around the longest are the ones that come out latest in the project… the ones that looked good when somebody suggested them at the 11th hour, and which grabbed all the remaining free time.  The ones that became somebody’s pet idea, which they couldn’t let die because they’d invested too much time already.  The “fixer-upper-opportunity” style time-and-money sinks that just seem worse every time you look at them, but that you can’t step away from because you don’t have the resources to start again.

It’s those ideas that are why I’m a big fan of collaborative, rapidly-iterating design processes early in a project.  To find the bad ideas, and to find them early.

The early stages of design are often referred to as “exploration”, and that’s an extremely appropriate word.  Exploration isn’t just about finding your way somewhere or finding the things you want… it’s also about finding and avoiding the pit traps, blind alleys and quicksand.  It’s not just finding the destination, but about avoiding the  hazards whilst doing so.

Good design isn’t just about making sure you build a perfect picnic bench.  It’s also about making sure you don’t build it on an ant colony, next to a sewage plant or halfway down a firing range.

So, folks, make sure you spend enough time identifying bad ideas… just so you know where they live and you can avoid straying too close to them by accident.


« Older posts

© 2022 Eggbox

Theme by Anders NorenUp ↑