A few months ago the wonderful Giles Colborne and I were given an interesting challenge by Sjors Timmer and Matthew Solle who were organising the UXDO event for August. Would we run a session on Workshop Facilitation.
Of course we would, but the question was… could we run a workshop about workshop facilitation?
Well, it was certainly worth a shot.
And so it was that twenty something very meta workshop participants bravely joined us last week for a workshop on workshop facilitation. It went a little something like this….
We posted our workshop plan, including timings, onto the wall.
The workshop was structured broadly following the KJ Technique with some collaborative affinity sorting and then ending with some group discussions on key topics. We structured the workshop in a way that promoted a pattern of widely exploring the breadth of the problem area, then synthesis or exploration of the patterns that emerge from our exploration and then consolidating into actions and findings.
7.05pm: Private brainstorm (Exploring the problem space)
Question: What are the biggest challenges you face when putting on workshops?
Write challenges on to post it notes – one idea per post it notes, in capital letters using an appropriately heavy marker.
7.10pm: Post up
To save time we didn’t do the ideal thing of discussing each idea as they were called out (to
capture all the nuances). Instead we asked people to volunteer whether they had similar ideas and posted them in clusters. You wouldn’t want to do this in a ‘real’ workshop as you want to give people plenty of time for discussion.
7.40pm: Grouping and sorting
We did a collaborative affinity sort by gathered in small teams, giving each team some of the clusters of post-its and re-grouped the post-its into their final clusters. We labelled the clusters with problem statements. This allowed the group to understand what the real problems were and how issues that might on the surface appear different sometimes stem from the same problem.
7.55pm: Dot voting
We gave participants Three votes each to vote for the problems they felt were most significant in blocking their ability to run effective workshop sessions – these would be the topics participants wanted to discuss in more detail later in the evening.
8pm: 1-1 Ranking
Here we deviate a little from the KJ Method. We compared cards in pairs. Rank them all, according to the question ‘What is the bigger roadblock to you running an effective, productive workshop.
8.15pm: Group discussion
We broke into small groups and brainstorm the problems and solutions
Again, this took two parts: firstly, examine the problem – what is it? what causes it? – make notes about this at the top of the flip chart. Then solutions – what’s worked well? why? List ideas on the bottom half of the flip chart.
8.35pm: Groups present back
We heard from all the groups on their problems and solutions
8.58pm Wrap up and head to the pub! (Although, in all honestly, we did end up running a little late… too much interesting discussion!)
Workshop planning tips:
TIP: Workshops are about the attendees, not your designs. Turn your attention outward. Make
the participants feel valued and listened to.
TIP: Every workshop needs to go through a phase of expansion (where you gather ideas) and exploration (where you understand ideas) and consolidation (where you set the outcomes). Your workshop structure should follow this flow.
TIP: The attendees have given up their valuable time to be there – recognise and respect this. Be clear about what you need from them, plan well, get as much as you can out of the day and communicate it back.
TIP: We posted the agenda and timings up on a big sheet at the front of the room. The agenda is not a secret and making it visible helps everyone to know where they are and where they’re going. It also means you can discuss it and make visible changes (if you need to) during the workshop.
TIP: When you’re planning your workshop remember its important to leave plenty of time at the end for your wrap up. People need to be heard. We’ve been to workshops where the moderator has ended by saying ‘we don’t have time for a wash-up, but please think about what we’ve said today.’ What a let down. Make sure there’s enough time to go around the room one last time.
TIP Make sure they’re putting just one idea per Post-It. Post-Its are the atoms of your workshop – and you don’t want to split the atom in the middle of a workshop.
The outputs: Affinity sort
These are the problem statements (and the related post-its) that we gathered.
Before the workshop
How do we know who to invite?
Inviting the right people | Getting the right people in the room | Decide who attends | Who is coming? (+ What do they do?) | Right people | Knowing about the likely audience
How do we agree on a date?
Agree on a date | Right time in the process
How do we communicate the problem to solve?
Describing the problem | Agreeing outcomes | Selling the whole idea | Agreeing the content, purpose, objective | The outcomes you need from it | Reason why | Agreed purpose
How do we create a good physical environment?
Venue & equipment | Cleaning the whiteboards | Venue | Choosing funky music | Maximising resources & space | When should I start to prepare | Right location | Finding a good space | Post it notes not sticking | Establishing the ‘right environment’ | Which alcohol to bring | What should I bring?
How do we make sure they’re in the room?
Making invitations that people will stick to | Make them show up | Getting people enthusiastic | Convincing stakeholders to participate
What to do?
How to structure the workshop | Lack of good methods | Appropriate method for participants | Which activities lead to the right results
During the workshop
How to manage time?
Knowing when to stop | Managing time
How do we get the group to work well together?
Group dynamics | Group social dynamics
How do we introduce the session?
Setting expectations | Warming up participants | Ensuring participants are prepared
How do we create the right social environment?
Break silos | Make people think creatively | Getting the client to pick up the pen | Breaking down the fear of collaboration
How to keep participants focused?
Keeping people on track | Retaining control of the group | Keeping participants on track (work issues) | Keeping people focused | Attendees not focused on listening (wondering mind) | Agenda saboutaged | Keep open without losing control
How do we best get people to participate?
Framing the right questions inspirationally | Communicating to the attendees appropriately | Knowing my own limits and strengths | Facilitating and guiding without stifling | participants not understanding workshop method or format | Letting go during the workshop – appropriately, of course
How do we maintain interest from all attendees throughout?
Keeping up energy | Going deep | Attention | Focus | Engagement | Keeping up momentum | Maintaining good, healthy energy | Going the long haul – energy
How do we deal with Hippos*, Wallflowers & Snipers
Overcoming ‘silent stares’ | Hippos! \ Handling strength of opinion | Negative attitudes | Encouraging people who are sceptical | Commitment | Wrong PX in the room – it’s not working! | Participant’s fear of coming up with bad ideas | Getting quiet folks to speak | Ensuring that everyone involved has a say | Shouty people | Avoiding one dominant voice | What to do with bigtime extroverts | People who hate workshop format as participants | Negative attitudes.
*Hippo – Highest Paid Person’s Opinion – i.e. important people who use their power from outside the workshop to override debate within the workshop.
After the workshop
How to communicate the outcomes of the workshop?
How to collate report on results | The what | Playing back findings | Summarising the workshop’s findings | Remembering details | Not missing something | Summarising efficiently | Who is writing up? | Processing — distilling
How to communicate the worth of the workshop?
Communicating the value of the workshop
How to act on stuff after the workshop?
Getting people to own actions.
How do we deal with a lack of consensus?
Managing differing opinions | Designing together without feeling the result is a big mess of compromise | Culture problems | Getting people to collaborate | Managing dissent | Divergent personalities | The personalities of people involved | Facilitating towards a good outcome
Tips for collaborative affinity sorting
TIP: Have someone to manage the labelling while the moderator leads the discussion.
TIP: We asked teams to begin each problem statement with the words ‘How do we…?’ so that we were sure these were real problems – questions that could be answered – rather than vague ‘stuff’.
TIP: There is no scientific way to approach this – point people to a bunch of post it notes and a space on the wall/table and have them get started – it will come together (and start to make more sense to everyone) as you go.
TIP: Encourage people to call out their groupings as they go. ‘I’m starting a group about scheduling over here’, ‘Does anyone have a section on difficult people yet?’ for example. The best way to encourage this is to lead by example.
TIP: Allow and spend plenty of time on this activity – it can be quite time consuming but is a format for having some really important discussions and building a shared understanding of the problem space. Have these discussions and push the group to make sure that the problem statement labels really accurately reflect the content that they represent. Don’t allow generalisations and ensure clarity.
The outputs: What the groups came up with in their short discussions on the key problems we explored.
Problem / solution – How do we communicate the problem to solve?
1. The problem
Not used to working together, no sense of being part of a wider team. Don’t speak the same language. See the problem differently – like that old chestnut of the blind men and the elephants. Don’t think there’s a problem. Think the solution is ‘obvious’ (we should just be doing what I say). Assume ‘my view is the true view’. Legacy of wrong thinking – commitment to wrong ideas or mindset.
2. The solution
Re-framing – make sure the problem is not described from one privileged viewpoint.
Don’t assume participants agree on the problem definition. Agree on the problem.
Listen to their views and opinions – respect. Weave their different views into a view of the problem.
Get a universally respected figure to set up the problem statement.
Get an outsider to state the problem (that’s what we do with user testing – users are our ‘outsiders’).
Bring it to life with examples. Case studies.
Encourage open discussion.
TIP: Always make sure you have clearly defined the problem(s) you’re attempting to resolve in your workshops and that everyone has a shared understanding of the problem and it’s importance/relevance.
TIP: Get the information into the world! – write your problem statements down, in clear, agreed, understood words and post them up in a visible place in the workshop venue. Refer to this liberally throughout the workshop and encourages others to do so.
TIP: Make your workshops a jargon free zone – don’t let others intimidate through use of language and make sure everyone feels comfortable asking others ‘what do you mean by that term’ or ‘what does that acronym stand for’. As every, the best way to achieve this is to lead by example – use the simplest language possible to convey your point, avoid jargon where possible (including UX jargon!) and explain it wherever it’s not possible to avoid it, don’t let people use language or terminology that you don’t understand – set the example by asking others to explain, even if everyone else in the room apparently understands what is going on (often they don’t either!)
What to do? (in your workshop)
1. The problem
It’s about lack of experience, not knowing the domain or culture, lack of confidence and it being too easy to stick with past methods.
2. The solution
Just do it – try something. Practice beforehand [so you feel confident in new methods]. Learn from others, be ready to make mistakes, learn by doing. Build up a good stock of resources. Talk to clients, colleagues, etc. Share your experiences. Take part in other people’s workshops – watch what they do.
TIP: Don’t get carried away always trying to come up with new techniques to use in your workshop. Make sure you’ve got a few options for each phase of opening, exploring and closing discussions and a few for the various ‘difficult people’ you might come across and focus on becoming really great a facilitating those. Others will come on your radar over time, pick them up when you see them.
TIP: Plan your workshop so that you spend time on opening, exploring and closing each problem/issue you’re trying to resolve or understand. There are no good shortcuts – skimping on any of these phases will negate the effectiveness of your workshop. Some workshops will be mostly exploring, or mostly resolving but pretty much all workshops need to go through all these phases in order for people to engage with them properly and for you to have somewhere to go to (a specific course of action) beyond the workshop.
TIP: If you’re doing something for the first time, do a pilot first. Yes, it takes some time what you learn from it will be invaluable and then you’ll be on top form for when it really counts. Respect your workshops participants more than to experiment on them on the fly if there’s any chance it could all come to nothing.
How to keep participants focused on the subject we’re workshopping? / How do we maintain interest throughout the workshop
1. The problem
Facilitator hasn’t understood well, importance has not been communicated effectively, discussion goes in endless tangents, losing sight of the objectives, people expecting to talk about topics other than the planned ones.
Boring – the format doesn’t give people an opportunity to have fun, don’t want to be too bossy [that’s] not fun, lack of engaging activities.
Human factors – tiredness, need breaks, hunger, mood swings, good view out of the window.
Technology interrupts – email, phones.
Group dynamics – language barriers, bad mix of people in the room, people seeing people they haven’t seen in ages for a catch up, chatty people, people have their own topics they want to talk about.
2. The solution
Mixing up types of activities,
Give them sweets (controversy here over which ones and how to avoid sugar crashes!)
Plan breaks, phones and laptops off (promise they’ll have time to check later), more exciting creative activities, icebreaker to engage them from the start, make things relevant and practical, let people talk a/b themselves.
TIP: The absolute best way to keep people focussed is to make sure they understand clearly what they are doing and how it contributes to solving a problem that is important to them. This means making sure that the problem is clearly defined but also that you’re continually linking the activity you’re currently working on back to that and showing how it is all coming together.
TIP: Don’t let people feel that they’re wasting time – this means making sure that you’ve planned activities that clearly lead towards an valuable outcome, and making sure that people see where they are on the map – how does what they’re doing now get them to that outcome. Kee people in the loop, don’t go for a ‘big reveal’ at the end.
TIP: Make sure you plan reasonable length breaks at least every 90 minutes – to get more out of people over a longer stint, make sure that you are mixing up the format of your activities – get people on their feet, moving around the room, working in different groups, talking, writing, sketching – building variety into the format increases stamina.
How do we deal with difficult people / create the right environment?
1. The problem
Different knowledge levels | People feeling threatened | How do we deal with different people to get a representative outcome? |
2. The solution
Make sure you talk to people 1:1 before hand to warm them up | Communicate clear objectives | Choose activities and tactics that treat everyone equally | Herd the Hippos together | Break down hierarchies through play.
TIP: Make sure you know who is going to be in the room before you workshop, if you don’t know much about them try to get an insight into their personalities and use this knowledge to plan activities that will help get the best from the group.
TIP: Build up a repertoire of activities especially to deal with people who either dominate discussions or who are reluctant to contribute, if you find yourself ambushed by this situation in your workshop, be ready to change techniques on the fly rather than persisting with ineffective methods.
TIP: Read widely and talk to others about techniques for talking with difficult situations in workshop – memorise these and practice using them so you can confidently take control and steer the participation in a positive and productive way.
Gamestorming: Gray, Brown, Macanufo (great overall manual with lots of suggested activities)
Icebreakers: Tizzard & Evans (pocket sized book of useful icebreakers to keep in your bag)
How to make meetings work: Doyle & Strauss (good on the roles that people need to play in meetings – see also Kevin Hoffman’s Slideshare ‘I hate sports but I love kickoffs)
Dealing with difficult people: Brinkman & Kirshner (has a great framework for understanding and managing difficult people and simple strategies you can put into practice)
Games People Play: Berne (helpful in understanding when, why and how you’re being pulled into a negative relationship)
Team roles at work: Belbin (useful for understanding team dynamics and the value that different types of personalities bring to teams, see also Belbin’s website to get your personal profile – for a fee)
Giles and I have lots of people to thank – this workshop happened because Sjors Timmer willed it into being and told the world (with Matthew Solle lurking in there, too) and thanks to the generosity of Fortune Cookie for giving us the space (and letting us in early) and providing the refreshments and human support in the forms of Jeff Van Campen and Matt Lindop. The attendees threw themselves into things and came up with lots of tips and ideas which we’ve tried to capture below. We hope we’ve done them justice (comments welcome).
Those who don’t follow me on Twitter (don’t worry, I understand. I’d probably unfollow me sometimes too!) may not know about two new UX related initiatives I’m involved in at the moment. Thought you might find them interesting.
UX Tuesday: is something I’ve wanted to do for a long time. I do a lot of UX Consulting work with start ups but a project by project engagement model is sometimes a little frustrating. UX Tuesday is a monthly, affordable Pay As You Go UX Clinic for Start Ups where founders and their teams can come to learn more about User Experience and to work on some of their own UX Challenges with a team of really experienced User Experience Consultants.
We’re currently running a survey to learn more about what Start Ups are doing and what they want to know about User Experience – complete the survey and be in the running to win a free company ticket to UX Tuesday!
These are both a little experimental and I’m really interested to see how they go and what we can learn from them. Come check it out if you’re interested or please pass details on to anyone you know who might be interested. I’ll keep you posted re: progress.
If you’ve spent any time hiring User Experience Designers chances are that they’ve shown you some examples of their work in a portfolio with the following disclaimer:
don’t look at the website though, it’s terrible.
We’re currently operating with this tacit agreement that you can do great design ‘in theory’ but that it’s not our fault if that design never makes it to market. Or if it gets totally transformed so that it’s unrecognisable by the time it goes live.
Can we really go on like this? Doesn’t it make you question your own existence?
Sure, there are a LOT of things that come into play between the time you present your awesome design and when the code hits the live server, but it seems to me that, as UXers and designers, we’re largely stepping away from the plate to wash our hands clean of responsibility for what happens. (How’d you like that mixed metaphor?)
I think we might be letting ourselves off a little too lightly and, for myself, I’m going to take starting a lot more personal responsibility for whether and how much of my design sees the light of day by thinking more about:
the nature of my engagement with clients and the shape of my projects - as a freelancer, the way that I engage with clients can vary a lot from client to client. I’m going to think more about how I can design engagements that maximise the chances of good design going live (this is part of the reason I recently kicked off UX Tuesdays)
communicating design and user experience strategy – are you spending enough time on communicating your design to the project stakeholders? Are you giving them tools that they can use to help make good decisions as they move through the implementation process (where, let’s face it, some of the most important design decisions are made in the absence of a designer). Do your clients/managers understand the implications of the decisions they’re making on the integrity of the user experience? Quick tip: a functional spec does not tick this box.
staying in the debate – are you still around when your design is being taken apart? are you engaging in a discussion to help save your design work? It’s easy to swan off like a princess mumbling under your breath about people who don’t appreciate good design work when they see it. Are you helping them (sometimes with a little force) to learn to appreciate it?
making sure you’re designing things that can be implemented – it’s all well and good to design a thing of beauty but does the team have the resources to bring it to life? Have you made something that’s beyond their current capability? If so, then, how good is your design really?
From this point forward I’m taking personal responsibility for the design that goes live, no matter how far it is from the documents I might show you from my portfolio.
In the Drupal community they say ‘talk is silver, code is gold‘.
Let’s make a new UX motto: ‘portfolios are silver, live design is gold‘.
Let’s own the work that goes live, understand and explain why it is as it is, and work on the skills we need to make sure more good design actually makes it over the line. Otherwise, what’s the point?
I’m sure that many of you will have heard about the very worthy Alpha.gov.uk project, the first prototype of which was released earlier this month.
If you’re a user experience practitioner, this should particularly interesting to you.
By way of a quick background, the AlphaGov project was formed in response to findings from a report by Martha Lane Fox, Revolution not Evolution into Government online services and opportunities to improve. (As a tangent, I’d love to see her in a cagefight with Lou ‘The redesign must die‘ Rosenfeld)
In this report she recommended the introduction of
“a service culture, putting the needs of citizens ahead of those of departments”
To test, in public, a prototype of a new, single UK Government website.
To design & build a UK Government website using open, agile, multi-disciplinary product development techniques and technologies, shaped by an obsession with meeting user needs.
See. It doesn’t get more UX-interesting than that right? It reminds me quite a bit of the D7UX project I worked on with Mark Boulton and the Drupal community, so I’ve been following it’s progress with a keen interest.
Now, go have a play with the prototype and see what you think. I’m actually not going to comment on the UX of the prototype today, partly because it’s actually quite difficult to do so. I’ll get to that later.
What I want to talk about today is the responsibility that playing out a project like this in public brings with it and how, in my opinion, AlphaGov have let down both the UX and Inclusive Design/Accessibility professional communities.
What you do, not what you say
Let me start by saying that I have a lot of admiration for the the ambition of this project. There is a lot that is good about it. There are also a lot of smart and talented people on the team.
The first thing that strikes me as strange is that on a project that claims to have an obsession with meeting user needs, the team contains a visual designer and a content strategist, a general strategist and multiple search analysists but NOT a user experience lead.
That’s right. We have an obsession with meeting user needs but not so much that we’ll actually hire someone who has extensive experience in actually making that happen.
Now, the project was fortunate in that it had Richard Pope, who I first met when he was a very UX-savvy developer at Moo and who played the Product Lead role on AlphaGov. As far as UX resources go, you could do a lot worse.
The team also recruited Paul Annett later into the project. Paul also has some UX experience but, as I understand it, his role was primarily as visual designer, making the interface a nicer place to be.
Without commenting on the interface itself, the lack of a rigorous approach to user experience is very evident in the way that the team talk about the work that they have done and their ‘design rules‘.
We spent the first two weeks in February recruiting a team from inside and outside of government, talking through the scope, agreeing some design rules and agreeing a vision for the Alphagov product based around the recommendations of Martha’s report.
We ended those two weeks with a list of prioritised user needs (based around search analytics from Directgov, Hitwise and departments),
We roughly grouped into functional areas and stuck to the wall. Each card (or user story) represented a user need, prioritised roughly from left to right and top to bottom.
Crucially also there was a fair amount of @tomskitomski and @memespring‘s product experience. All this was more than good enough to get on with twelve weekly development sprints.
More than good enough, eh? For many projects this would have been more than they ever had to work with.
But this is not just any project. This is a groundbreaking, whole of government initiative that claims to take a User Centred approach and be obsessed with knowing and supporting the end user need.
I think a project like that needs to demonstrate User Centred-ness a little more rigorously. For example.
Who is the audience?
At no point that I saw did the AlphaGov team ever apparently think deeply about what kind of an end user they were going to prioritise. They talk about ‘thinking about who our users were’ and having a ‘user-base of all the entire adult population of a country’.
As User Experience practitioners we know that although you might want the whole country to use whatever you’re designing, you need to put a ring around the kind of users you MOST want to support.
As designers we always privilege some behavioural attributes over others, even if we don’t articulate it. By not thoughtfully articulating this, you risk either an incoherent approach to the experience design or resort to self-referential design (designing for your own behaviour – something that is incredibly difficult to overcome).
You can’t take a User Centred approach to design when your user is ‘Everyone’. You need to define who your users are. You must clearly identify the behavioural characteristics that you most want to support and focus on designing to best support these.
There are many valid design approaches that do not require such a clearly articulated definition of the end user, but these are NOT user centred approaches. Thinking generally about ‘users’ while we design is not doing user centred design. I think it’s pretty irresponsible to suggest that it is.
AlphaGov sends a message that you can say you’re doing User Centred Design but you don’t have to show any evidence of a UCD process – audience definition, research, user involvement, design principles that actually track to specific behaviour attributes.
For example, it would have been great to see some personas developed and shared for this project – even hypothetical ones that drew on the data/insight available to the team. As well as helping the team avoid the problem of the ‘elastic user’ (particularly problematic when you do think your target audience is everyone), it would also help us be better able to evaluate what is good and bad about the prototype. It would also have demonstrated that the team was actually practicing User Centred Design.
(Elastic user, for those not familiar with the term, was coined by Alan Cooper to describe the way that while making product decisions different stakeholders may define the ‘user’ according to their convenience, often resulting in self-referential rather than user-centred design. More here).
This leads us to one of the complexities of the AlphaGov audience which is that, in reality, rather then being obsessively user-centred, the project had two competing audiences. The largely undefined end user and, often more importantly, the stakeholders who would ultimately decide the fate of the project – public servants. These two audiences have VERY different motivations and goals for this project, and the impact of the latter on design decision making was never clearer than when the accessibility topic came up.
On Accessibility and a conflict of interest
Again, from what I know, there was no formal expert accessibility (or inclusive design as I prefer to call it) consultancy on the project team. This is not to say that the team didn’t have quite a bit of knowledge about the mechanics of accessibility (the impact of technical decisions on whether something could be certified ‘accessible’).
Accessibility should start with research and consideration, not with box-ticking or sprinkling a few standard accessibility features – especially in a government context where a user journey regularly extends into the real world (Booking a driving test? You’ll probably want to know the facilities at the test-centre).
Actually, what I picked up from discussions about this on Twitter and elsewhere was that actually, it was the other target audience – the stakeholders – who most influenced this decision. If they put the focus on accessibility, they’d have to take away some of the ‘shiny’ – AlphaGov would end up feeling like Just Another Government Website. Rightly or wrongly, the shiny would help excite the public servants to approve and fund a beta version of the prototype.
Perhaps it was a noble sacrifice… who knows. Point is, it’s far from transparent.
The message that the world takes away from this exchange is that accessibility, even when your audience ‘entire adult population of a country’ is optional. And that accessibility can be ‘done later’ not, as they had first set out, built into design considerations from the outset.
These are really bad messages to be sending and, given how publicly visible and lauded this project is, sets the work of many amazing inclusive design specialists back considerably.
It’s hard enough to sell in good accessibility work already. AlphaGov just made it harder.
Activity Based Design and Search Analytics
OK. So I will talk briefly about the prototype… but mostly to discuss how the data you have access to can significantly shape your design.
The team have published very little information on the data that has guided their design decision making for this project but we do know that search activity has influenced it heavily. A team of sixteen people included no UX lead (sorry, did I mention that already?) but two people doing search analysis.
In the design rationale blog post, Richard Pope implies that search logs strongly influenced the design and information architecture strategy for the prototype.
we spent the first couple of weeks scouring search logs and analytics for the various central government websites; thinking about who our users were and generally discussing the kind of thing we were setting out to make
Based on what we learned from looking at search-logs, we knew that there was a relatively small subset of tasks that require the majority of people need to interact with government online. So we should do less and focus on tasks.
Since for the vast majority of people their web journeys (finding out the date of the next bank-holiday, or reporting a lost passport) start with a search engine rather than a direct visit we should think of Google as the homepage and we should also feed Google, Bing and other search engines nice friendly urls.
If someone is just landing at a page on your site then it’s helpful to start thinking of every visit being a new user, assuming they have no prior knowledge of the structure or content website they have landed at.
It is really difficult to evaluate this prototype from a user experience perspective, given the competing target audiences. The best you can do is try to recall the last few times you interacted with a government website and try to reenact that here. Every time I do that I come away with a lingering feeling of disengagement. There’s something that search logs probably don’t really show which is that this is MY government. For better or worse, I have a long term and multifaceted relationship with this government and yet, every time I encounter this site it (by design) makes me feel as though this is my first visit. I find that really unsatisfying and kind of perturbing.
Now, this is not a professional design critique, this is a qualitative research data point of one. But it’s not something that you’ll ever pick up from search stats and analytics. I could bore you further with how I find the promise of localisation with this infinite noob status even more perplexing, but you’d have to spend time with me to understand it. And then spend some time with a bunch of other people to see if this is a common theme or just me being an edgecase.
And people will never post this kind of feedback on GetSatisfaction. (Most people can’t really articulate this kind of weird feeling and wouldn’t think that it was important enough to comment on compared to, say, a bug. You need a good facilitator to extract this kind of data).
To do really good user experience design you need a mix of data points. If you privilege one set of data, you’ll see that in your design. I think we’ve got some of that going on with AlphaGov.
Quantitative data is fantastic. I’d love to see more of what the team had to work with and how they applied it in their design process. But it’s just one kind of input. Qualitative research helps you better understand your end users and thereby to design better for them.
People who do User Centred Design do Qualitative Research.
User Experience is a Time Soak/Non-Agile
Which leads me to the final problematic sub-text that I felt emanating from the AlphaGov team which was essentially that ‘we’re as user centred/accessible as we can be given that we only have 10 weeks to build this thing’. This perpetuates the myth that User Experience can be a time soak, that it slows you down, that it doesn’t really have a place in an Agile methodology.
This is where having an experience UX practitioner on the team from early on could have been helpful.
It is certainly true that historically, Agile and UX have had a fairly vexed relationship but these days many practitioners are experienced and adept at including both user research and ux design into the most demanding agile iterations. We have a toolkit of lightweight qualitative research approaches that work beautifully in this kind of fast paced and responsive environment. UX does not have to be a laggard either at the outset or in the throes of an agile project.
The ten week project timeframe is absolutely no reason to not include real practice of user experience in the process. You may need to find someone who has experience working this way (not all UXers find this kind of project much fun), and you may need to be creative in the way you structure the work, but you should definitely be doing it. Particularly if you’re setting an example of how projects should be done, as the AlphaGov team certainly was.
I want to repeat again, this is a very worthy project and many of their design principles are, I think, sound. For many commercial projects, the methodology that they’ve applied and shared is absolutely appropriate. But the bar is set higher here.
By doing this project in public, by making such a big deal of putting the end user needs and their importance to the project, the AlphaGov team have set themselves up as rolemodels. They’re sending messages about the the way things should be done. They’ve made quite a rod for their back.
If I was just a member of the community, I’d probably be nothing short of delighted with what they’ve achieved. Unfortunately, as a User Experience practitioner, I feel kind of glum. This project has talked the talk of caring about the end user, of placing their needs at the centre of the project and above the needs and desires of government, but at every step, they’ve done little to set a good example for how others should actually do this.
I hope AlphaGov does move forward into BetaGov.
But I hope, if they do, they take a moment to think about what the public performance of AlphaGov and then BetaGov means for their professional community.
Either stop calling the project User Centred, or hire someone to really focus on user experience and do more to share how they’ve integrated real user insight into their design strategy and implementation.
There’s a big opportunity to set a good example to a big audience here. Let’s take advantage of that opportunity and show the UK Government, digital industry, hell, the whole world what projects really look like when they’re user centred, – that they don’t have to be cumbersome, expensive and slow.
Imagine that, a properly user centred government website that was agile, and shiny and amazing. Now, that’s something to get excited about.
My name is Leisa Reichelt. I am the Head of User Research at the Government Digital Service in the Cabinet Office.
I lead a team of great researchers who work in agile, multidisciplinary digital teams to help continuously connect the people who design products with the people who will use them and support experimentation and ongoing learning in product design.
If you're interested in working with me or would like to talk more please email me