I found the design process utterly transformed once I decided to stop trying to be the expert and start trying to encourage a culture of experimentation.
Battles that would rage, angrily, for months – dying down when the provocateur was busy with other work but rising up as soon as they had a little time on their hands – these battles began to go away. Long frustrating and unproductive sessions of trying to explain, defend, rationalise why the design that I suggested had more merit than the many and varied suggestions (or requirements) coming from stakeholders all but disappeared. People who would usually sneer derisively at the design team became participating members of the design process.
It’s not perfect, it’s no silver bullet, but for me, it’s been a transformation.
And it’s pretty simple. To embrace experimentation you just need to stop talking about design in a Socratic way (other related but less civilised methods are also very common) and start formalising hypotheses and tests.
Stop having meetings to argue about which design approach is better - endless meetings with stakeholders full of defensiveness and crazy arguments where the people who tend to win are those who are loudest, most persistent or highest paid. Start making decisions based on lightweight research that provides evidence (sometimes stories, sometimes numbers) to support the design that most strongly supports the agreed goals.
Goals. That’s one pre-requisite you need for this experimental approach to work. You need to have agreed what your goals are for the design. What success looks like. Without this agreement, no change to methodology will save you.
The experimental mindset is an egalitarian approach to design. It allows that anyone can suggest a design solutions and, rather than argue endlessly about whether it is better or worse than other approaches, you design a test. Find out how to find out which design works best.
Hypothesis, prototype, test.
There are loads of tools you can use to test ideas quickly – from some quick in person user research, to some A/B testing (if you’re not set up to do A/B testing, meet your friend Google Content Experiments and get onto this immediately), to an online card sort, to one of the range of tests that places like VerifyApp offer. The methods for testing are limited only by your creativity and are mostly inexpensive.
Sure, you can’t design from the ground up this way – you will still need a good designer that you trust get you to a good starting point from which you can experiment up, but once you’ve got the framework in place, don’t waste time and goodwill bickering about the details but encourage experimentation throughout the entire organisation. You’ll raise the overall ‘design IQ’ and happiness quotient of your company, your design team and, most probably, even yourself.
On approach, I’m warned by most clients that this will be a very tricky design problem, very hard to get right and of course, utterly imperative to the business that we do so.
And, at first glance, often this appears to be the case.
It’s been my experience that the main reason most designs go unsolved is not the lack of talented designers or their interest in solving the problem. Instead, the problem is with the organisation themselves - their inability to allow themselves to implement the right design, or even any good design.
Many times I’ve suggested a design approach only for the in house designer on the team to literally pull the design from their desk drawer or computer and to tell me how they tried to get the organisation to go this way two, three, maybe four or five years ago. They tried and tried, had no success, and filed the design away so they can get on with the work the organisation deemed acceptable or appropriate. It’s kind of depressing, and almost embarrassing when my main role is to advocate for work that was actually done years before I appeared. And sometimes it works.
Politics and egos are the main reasons that great design goes awry – either it is never presented (because presenting it is a risk to those egos and would be not wise politically), or it is presented and dismissed, or it is presented and then changed such that egos are not wounded and the politics are in tact, the design integrity is hardly a passing consideration.
Organisation processes and complexity are another common killer. As more and more, the digital products replace the previous products and functions of the organisation, this requires a transition in how things should be done that most organisations are unprepared for an unwilling to support. They’d rather keep doing things the way they always have, and craft a design that doesn’t trouble their processes or require additional resources. You know you’re designing for an organisation on the way out the back door when you come across this – disrupt yourselves or be disrupted, Peter Drucker, amongst others, has been telling us this for half a century (or more). Still, it can be surprisingly hard to do. We don’t like change and the changes required often threaten the existing egos and power structures. See above.
At first glance, the solution is strategy. Get more designers higher up the food chain and involved in the creation of strategies that would guide an organisation to make better decisions. Sounds right, but the reality is different. Most places I encounter these problems have all kinds of strategies talking about how important design and the end user is to them. They all handwave the right way, but the execution doesn’t match the strategy. This is the reality we live in – almost every organisation you come across is loudly proclaiming their interest in the customer experience and surveying you within an inch of your life to prove it. They’re talking about the importance of design and hiring expensive designers (who are then nobbled by the organisation). None of this matters if the execution, the tactics, don’t fit the strategy. And most often, it doesn’t.
I’ve tried approaching this two ways – firstly playing the politics and trying to get involved higher up, spending lots of time in meetings, or secondly: just executing – making things that actually live out the strategy that mostly lives on posters and induction manuals and giving the higher ups a better choice to make, giving them a good choice to make not expecting them to get there on their own and then brief the design team. These days I don’t get too much feedback throughout the design process (forget wireframes) – make it and then iterate. It’s been the second approach that has worked better.
‘Show, don’t tell’ is a design principle that seems to work well in design practice as well.
It saddens me how many great design solutions are hidden away in filing cabinets. It’s not enough to know the right answers, the real design challenge is in getting the organisation to adopt and implement and maintain (a whole other challenge) good design. It feels to me like we need to focus on this more.
Earlier this month the UK Government Digital Service publicly launched the gov.uk , the ‘single government domain’ or the primary interface for UK Government’s digital interaction with citizens, replacing sites including DirectGov and BusinessLink.
Although I’m no expert on public sector projects or the history of the UK Government’s web presence (I’ve done bits and pieces as I suspect many of the UX Community in UK have done), I want to take a moment to commemorate the impact of this achievement for anyone who is trying to encourage large organisations to embrace better digital work practices.
This is a big deal.
It’s important because Gov.UK arguably brings a new high standard of design, content and overall user centricity to public sector digital projects. It’s true that the UK Government has engaged its share of designers and user experience (or, probably more accurately, usability) people over the years, until now it has felt as though they were constrained to making things less bad, rather than aspiring to really create experiences that citizens wanted to engage with.
That’s because this is not really a design case study – it’s not about the government finally finding a decent designer to pretty up the interface or a usability person to write the perfect report telling them what to do. It’s about actually creating an environment where, having hired those people, they are able to do what they are good at and to actually get their work, relatively unscathed, through the complex web of stakeholder engagement and approval processes, and into ours – the citizen’s (or in my case, resident) hands.
What the Government Digital Service have given us is a brilliant case study in overhauling the way things were done before and changing them around so that they can support the creation of better user experiences online.
I thank the @GDSTeam for giving me the case study I need to present to large complex organisations who are trying to revolutionise their user experience without changing the way that their organisations work. Now I can say, ’Well, if the UK Government can do it, I’m sure we can’. In my experience, it’s quite compelling.
A page like this doesn’t come into existence because one designer had a good idea. This is no vanity redesign project, these designs and this content has gone through the complex series of stakeholders and approval processes to get from ‘good idea’ to ‘actually live’.
Being able to sell something as radically different, to give stakeholders the confidence to go with something like this -that is a tremendous achievement.
Remember – this is the typical approach to public sector content:
This is not a story about interface design (although kudos to the designers who have worked so long and hard on this project). It’s a story about organisational design. The changes that the GDS Team made to how digital design is done in government is what enabled design like this to emerge.
- moving to a centralised, multidisciplinary team who work in close proximity and are able to focus on solving particular problems, not get hauled around from project to project to project with no time to focus.
- housing this team in a space that facilitates close teamwork between the members of these small, agile teams (including, from what I’ve seen, plenty of wall space. It matters!)
- using an iterative but agile project methodology that involves regular testing information gathering allowing the team to make decisions driven by data rather than opinions
- working openly, sharing what they are doing (including the code) and why they are doing, inviting others to participate in the process and inviting feedback often.
- having clear and inspiring leadership who continue to evangelise for the team higher up in the organisation and be the battering rams driving change throughout the organisation.
- having vocal and consistent support from the highest parts of the organisation
- spending time on creating artefacts that allow the team, as it grows, to maintain a clear shared vision about the way they are approaching challenges and defining solutions.
and many more I’m sure.
More than anything I’m thankful for the final point – the openness and the time spent creating and sharing artefacts.
From the very beginning, the team have been sharing their methodology and rationale, their project documentation and even their code. They have been helping to enable the rest of the world – not just governments – to improve their practice and make better digital products.
Some of the treasures that they’ve provided us with include:
- Design Principles
- Content Principles
- Performance Framework (measuring effectiveness)
- and lots of discussion around user research and design decisions made on their blog.
There is plenty to criticise, there always is. Nothing is perfect, and even less so in large and complex projects like this. And yes, the real challenges are ahead – can this scale and can it be maintained for the years to come now that the ‘launch’ has passed.
Most of all though, here is an amazing opportunity for all of us – public sector or otherwise, UK and around the world, to take advantage of the awesome work the team has done and the resources they’ve provided us with and to use them ourselves to no longer accept ‘the way things are done around here’ but to require and facilitate transformation.
The space you work in, the size of your team, the access to and interest from upper management, your project methodology – all of these things and many more will directly impact your ability to do good work, to deliver good experience. If you want to fix the experience, it’s critical to look at the environment that is impacting the ability of your team to deliver.
People often talk about Apple’s design process, but I think equally important is the way that Steve Jobs took the focus off the Profit &Loss statement- making that the responsibility of just one person and, apparently, running just one P&L for the world’s most valuable company. (Most companies run multiple P&Ls between departments (functional or product), and crazy decision making and politicking ensues).
Only through transforming the way your team, your organisation works will you really be able to transform the experiences that the organisation is creating for its audience. It’s not a UI problem, it’s an organisational design problem. Those things do matter.
So, get stuck into addressing the environment as well as the experience design and when you’re feeling challenged, remind yourself and your colleagues, ‘well, if the UK Government can do it… ‘
Ross Popoff-Walker wrote a properly ranty blog post yesterday entitled ‘UX Design at Digital Agencies is F*cked‘ in which he discussed the typical waterfall methodology utilised by digital agencies he’s worked in.
Most of us with any agency experience would have no doubt been nodding in agreement to read:
Big digital agencies especially, will kick off a project with a “discovery phase” (which may or may not actually discover anything), and quickly jump into a waterfall-style design process of UX sketching, wireframing, and client meetings/approvals. Then after many (many) rounds of visual design… and only then… will agencies start to move into the development and tech stage. Only after every pixel has been pushed and use-case documented, will something be made that is working and actually functional.
Developers and tech leaders intuitively get the problem with this. Websites (or anything digital) are not buildings, made the stand the test of time without change — they are meant to be tested and iterated, and improved continuously. But in my experience, it has never made anything of real value to a client.
Ross goes on to advocate that agencies take up the Lean Startup methodology widely in use amongst start ups and some of the more forward thinking and/or buzzword aware larger companies. I concur. This is indeed a fine and very user focussed way to approach a project.
However, Ross glosses over the reason agencies work this way (‘comfort, dogma, and the ease of billing clients’ he suggests). I think a lot of agencies want to work in a more Lean or Agile way (and some attempt to do so), but the nature of the agency/client engagement will have to change substantially in order for this way of working to become widely adopted.
A few things happen when you hire an agency.
Firstly, the client effectively outsources the work. They create a separation between themselves and the people who are doing the work.
Even the agencies who work most closely with their clients (and by this I mean properly in each others faces physically or virtually ALL the time). This creates a different dynamic than what you get in an inhouse team. There is an “us” and a “them” and they have very different realms of expertise and knowledge and often not a great way of combining these two sets of knowledge to make a great product.
The lack of integration between the company who needs the project done and the company who is doing the project creates a very different shape to a typical (effective) Agile or Lean team, and it makes it difficult to work effectively.
It also introduces another ‘customer’ to the mix – one that is not the end user customer, but one who will sign off the project and pay the bills – so, probably, a more important customer to the agency than the *real* customer that the project is being created to serve.
Complicated huh. Makes it hard to focus on what’s really important when there are actually TWO things, often in conflict, that are important. Agencies will always preference making their customer happy over making the customer’s customer happy. That’s understandably, but it doesn’t lead to good project outcomes.
Secondly, when the client outsources the work, they feel as though they’re outsourcing the risk.
They effectively pay a premium for an agency who knows what they’re doing to do that thing well. It tends not to play well for an agency to then spend the duration of the contract being actively uncertain, making hypotheses and validating them, using the client’s money to ‘learn’.
This, traditionally, is not what we pay a top class agency to do. We pay them to know stuff and to get stuff right, and to be the people we blame if it doesn’t work out well. Until clients get comfortable with this (will they ever?) it will be difficult, nigh impossible, for an agency to be properly Lean or even agile.
Thirdly, when you’re paying an agency a lot of money (and you usually do), you want to feel confident about what you’re going to get when then money is spent.
This is why clients are so desirous of spec work in the pitch process – it makes them feel more confident about what they’re going to get for their money. Getting them to let go to spec work in the pitch is hard enough, how much luck do you think the Biz Dev guys are going to have selling Lean, where all we have is a Build, Measure, Learn process that admits we don’t really know anything for sure, and the possibility of pivots along the way. (Not to mention that most biz dev guys probably don’t have the first idea what Lean is and have the wrong idea about Agile).
No one ever got fired hiring a big name agency to do waterfall, complete with functional specs and three different visual design variants for the marketing team to choose from. They probably didn’t get a good product at the end of the process either, but they got a thing that looks as though it probably took as much time as the agency said it was going to take, and looked kind of pretty, and so they don’t feel ripped off and angry. And they won’t get fired.
It takes a special kind of client to take the risk and develop the level of trust and integration required to work the way that Mr Popoff-Walker and many, many other inhabitants of agency world would like to work.
The agency model is certainly pretty broken, but both agencies and – I’d say more importantly – clients need to take responsibility for that, and take both action and a little risk to help mend it.
I’ve been asked a few times recently about my opinion on what software people should know if they want to do UX so I thought I’d share my thoughts here. Of course, the first answer is – it depends.
It depends on what *kind* of a UXer you want to be (there are many types – some are more design-y or research-ish, some some are closer to the business or the interface) and what kind of place you want to work for (there are many options there too).
The tools you use affect the work that you output, so I think you should be thoughtful about the toolkit you decide to use.
To begin with, I would say that no software will ever replace the advantages provided by a willingness and ability to sketch.
If you are not confident with sketching you will start designing into software and this is not something you want to do.
The minute you start designing into software you limit the number of options you explore, you move more quickly to high fidelity and are more likely to become attached to your own design. You sit by yourself at a desk instead of collaborating with your team.
Before you learn any software, get comfortable sketching in company.
Another important thing to understand is that most of the time, the tools we use are substitutes and shortcuts for the actual raw material for which we design.
The last thing I would say before I give you the list you’re really here for, is that it is less important which software you learn now, and more important that it doesn’t become your hammer.
(You know the saying – when all you have is a hammer, everything looks like a nail). Every day a new piece of software comes out that might be a great tool for you on the particular project that you’re working on. Get comfortable always exploring, evaluating and learning new tools. In fact, I’d go so far as saying, don’t even bother trying to be a master of one, be a jack of all software! And be prepared to change your mind.
But, tools you must have. Here’s my thoughts what you might find useful.
- A ‘diagramming’ tool for basic wire framing, sitemapping, content/data modelling and flow charting. Common choices are Omnigraffle (for Mac) or Visio (for PC). There are also a swathe of online (SAAS) alternatives including Balsamiq, Mockflow, Mockingbird, Hotgloo, Pencil, Pidoco and the list goes on (there’s a nice list with summaries here)
- A tool for making higher fidelity (prettier) wireframes/prototypes. Common choices include Fireworks, InDesign, Photoshop. Keynote (Mac) or Powerpoint (PC) are also increasingly popular with good reason I think – they’re easy to use, flexible and increasingly powerful little apps.
- A tool for image processing – a lot of people use Photoshop but most UXers could get away with Fireworks or even Preview (comes with Mac) for their requirements
Personally, I’ve moved away from Omnigraffle and towards Fireworks in the past 12 months or so for various reasons, but there are no perfect UX tools. I’ve seen people make a compelling case for moving back to Omnigraffle. Personally, I think Axure is more trouble than it’s worth, unless you are having to do all your detailed interaction design work in the absence of developers. (Which, if you know me, you’ll know I try very hard to avoid).
Some companies will only hire people who have skills in specific software, eg. Axure. This is idiotic as software is easy to learn, being a good UX designer is the hard part.
Good UX Designers will also read this section – there’s not a clear break and more and more designers should be integrating these tools into their daily practice.
If you’re doing UX Research then having some good Excel skills will come in handy for analysis. You might alway want to get handy with SPSS (although, again, this will be overkill for some). I’ve found having some good mind mapping software to be handing for research analysis as well.
Important note: the best analysis, in my opinion, happens doing affinity sorting using post it notes on a wall – this is research’s equivalent to sketching.
You’ll also need some software to record the user research you do in person. The obvious contenders are Morae (if you’re working for a company with a decent budget) and Silverback which you can run on your Mac.
The tools I find most interesting for UX research tend to be newer web services such as:
- Online remote usability testing: Usertesting.com / Whatusersdo.com etc.
- Other online research tools such VerifyApp and the other tools from the team at Zurb, and OptimalWorkshop‘s great range of online usability testing tools.
- Online analysis tools such as Reframer
- Remote moderated research tools (mostly screensharing/online meeting tools) such as GoToMeeting or Webex
- Apps that can be used for longitudinal contextual studies such as Yammer, Twitter, Facebook, DScout
- Online recruitment tools such as Ethn.io
- Optimization and other measurement tools such as Google Optimizer
This is by no means a definitive list – there are lots more great tools out there that I’ve no doubt neglected to mention. Feel free to add your favourites in the comments below.
Just remember – it’s not the tool you use (although they will no doubt leave their imprint), it’s the way that you use it that really matters.
I had the honour of doing a short talk about my thoughts on Strategic User Experience at the Content Strategy Meet Up last night and in my presentation I included a list of reading that I’ve found particularly useful in helping to understand how UX can work more strategically within organisations.
This is far from a comprehensive list, but is a good place to get started.
If you’ve got any other recommendations you think people should know about, feel free to share below.
Lately I’ve been asking the same set of questions to UX people.
How many weeks in the past year did you feel as though you were doing the right kind of work, on the right kind of project. How often do you feel as though you’re really being properly utilised, that you’re using your skills and experience in a way that is really helping companies make a difference?
Based on my own experience, my hypothesis was that the answer would be pretty depressing. And, with a few exceptions, it has been.
At a time where companies are crying out for User Experience people to come help them solve problems – and there are so many problems to solve – the people who are at the coal face generally feel as though they’re either not able to work effectively, or they are doing great work but tackling the wrong problems.
What a tragic waste of talent, of time, of money, of life.
The last few months I’ve seen a lot of movement in the UX field – people moving in house out of agencies, starting their own companies, leaving freelancing – it feels like we’re generally a little restless at the moment, and it’s a feeling I’m familiar with. I need to stop taking briefs and trying to reshape them, and instead to work with companies to give them the tools to make better decisions, to give better briefs, to allow teams to work together more productively. We need to get out of the design or UX department to solve these problems.
So I’m shifting my focus to Customer Journey Mapping.
In workshops and conference talks I’ve done recently I’ve waxed lyrical about the Customer Journey Map and how it has, without doubt, been the thing that has most transformed my practice as a User Experience practitioner over the past few years. In particular it does three things that immediately accelerate an organisation’s customer focus:
- Makes the customer experience understandable and addressable – even for quite small companies, understanding what it is like to be your customer at all points of the customer lifecycle and across all channels can be difficult. Creating a customer journey map helps make the big picture of customer experience understandable so that even as we deep dive on specific projects, we’re maintaining a consistent and coherent experience at all times. By picking out the critical moments of truth and focusing on those touchpoints, we make significant improvements much more achievable and measurable.
- Unites the silos, ignites customer focus – often organisations are filled with people who are passionate about customer experience but who are functionally separated from each other and have difficulty communicating effectively and aligning their efforts across the organisational silos. A customer journey map gives them a focal point and a shared language and way of communicating the insight they have and activity within their functional group, improving the organisation’s ability to maximise the efforts and expertise of its customer champions.
- Visibly connects business value and customer value – Peter Drucker tells us that the purpose of the business is to create value for our customers and that profit is the feedback we get from doing it well, but the connection between customer and business value is often difficult to see in today’s organisations. A customer journey map provides a way to show how the critical moments of truth for customers – the touchpoints that should be most thoughtfully designed – almost always maps to places where money flows in or out of an organisation. Customer journey maps provide a way to measure CX metrics that directly impact the organisations bottom line.
I’m not giving up the usual research, design and strategic UX work I’ve done over the years, but I’d like to spend more of my time working on making Customer Journey Maps with clients and helping to focus their energies on the UX projects that will really make a difference for their organisation, and also to bring some more ‘design’ into the world of Customer Experience (CX) (yes, CX is different to UX, and yes, I totally understand how confusing that sounds).
So, if your organisation needs some customer experience mapping done, or you hear of someone who does, I’d love it if you’d send them my way. With a bit of luck and good management I can do my bit to help make sure more UXers are working on real and important UX projects in the coming years.
I’m writing this post while attending Cognitive Psychology UX Bootcamp. This is an exercise that we’ve been set to do and I’m working with Tara and Jerome of Ribot. This is the incredibly laymans version after half a day of the two day program so don’t take any of this too seriously. If you disagree with any of this, you can take it up with our Bootcamp trainer, Joe Leech:)
Tips we’ve learned so far:
- Limit the line length to around 95 characters per line, allow plenty of space between lines, make sure the colour contrast is sufficient and be aware of the impact of colour choice and colour blindness
- Aim for a reading age of around 10yrs (using the Flesch-Kincaid readability test), especially if your audience is multitasking
- Write using upper and lower case unless you want people to read REALLY SLOWLLY and find all your typos
- Don’t put lots of flashing stuff in the peripheral view but also don’t rely on something animating to grab attention in my field of focus
- Try to keep hyperlinks on the same line (not broken over two lines), and don’t put too many links off to other pages/sites if you want to keep people focused on your article (hyperlinks create a fixation point and draw attention)
- If you want to look smart on your blog, include a photo of yourself that is closely cropped around your face. If you’d rather look less intelligent (and possibly more sexy), include a photo with more of your body in it (Note to self: get new profile photo).
- Group similar things together, make use of established/known patterns.
- Make sure any buttons are sufficiently large targets (ref: Fitts Law)
- Encourage psychologists to do a lot more research about the effects of design on reading on the screen because there seems to be a lot of things we don’t really know for sure.
I was invited to speak at the MonkiGras event this week where getting a little sweary and ranty is kind of encouraged (it goes well with the craft beer consumption that is an integral part of the conference mix). This was my contribution.
When I checked the agenda to see what I was supposed to be talking about at Monkigras, I saw that I was down to talk for 15 mins about ‘Crafting Good UX’. Where to start. I suspect James expected me to come up with something like this post that ReadWriteWeb published the day before my talk: Five Signs of a Great User Experience If you’re interested, the five signs (aside from simply *being* Path), are:
- An elegant UI
- Being Addictive
- A Fast Start
- being Seamless, and
- It Changes You
I hate these kinds of lists. You look at them and you go – yes, that makes sense doesn’t it. We just need to do those things and we’ll have great UX. Simples.
If only that were true, we’d be overwhelmed by UX amazingness. Instead, here we are, using the same handful of good examples in ever conference talk or article written about User Experience this year.
It’s not that simple right. So, I changed my topic to ‘Why Most UX is Shite’. The audience was people (especially developers) from start ups, open source and enterprise software – I figured this topic would probably resonate with them.
Now, there are plenty of ways you can make a user’s experience of your product rubbish, but in my experience, there are a handful of serial offenders. These are not things you can add to the backlog and bug fix next week, but if you know what they are you can stop wasting time fiddling around with things that, ultimately, don’t matter if you don’t get these other things right.
1. You’re not making decisions (so you force the people who use your product to make them instead)
So, this one I see ALL the time.
From a start up who doesn’t want to rule anything out of its value proposition so doesn’t really know what it is so, as a consequence, no one knows what problems it’s solving so they don’t engage. To open source software that tries to be Rails and WordPress at the same time and is consequently a usability pariah. To a page that is so full of content with no hierarchy, or a form with too many fields, meaning the customer gives up and goes somewhere that makes mores sense.
Decisions like: WHAT A COMPANY STANDS FOR, or WHAT WILL NOT BE IN THIS PRODUCT, WHAT YOU WANT PEOPLE ON THAT PAGE TO DO, or WHAT THE BEST PERMISSIONS SETTING FOR MOST PEOPLE. These decisions don’t get made, and these are reasons that people look elsewhere.
You can’t designs something if you don’t know what it is. If you don’t have constraints or priorities.
Here’s the choice – YOU make your end users choice easier and you’ll have more customers.
This starts at the top. What does your company do and not do. What does your product do and don’t do.
Get a vision already.
These decisions don’t happen because people and companies are too gutless to make them and to potentially be wrong.
From a UX perspective you are BETTER to make them and be wrong and then make a better one based on what you’ve learned than not make them at all. Preferably in testing, BEFORE you inflict it on your paying customers.
In reality tho, most people are much more interested in their own careers – not being wrong and getting a bonus – than they are in really delivering good user experience for their customers.
2. You think your opinion counts (unless you’re the end user, it probably doesn’t)
You can probably get all pedantic on this with me, but but make sure you understand the point I’m trying to make here.
As a designer, there are two sets of people who will influence you: the end users you’re designing for, and the stakeholders who you work with every day, who you want to impress and have a good working relationship with, who will write your performance review and recommend you get a bonus, or not. Who will think you are cool in the open source community or a pain in the ass.
End users who you probably don’t get to see all that often, co workers you see every day.
Which do you think will have most influence?
I would LOVE to believe that all designers are able to put the end users needs ahead of their own personal ego, or their end of year bonus, but, let’s be realists. If you’re my boss and I know what’s going to please you, your opinion is going to be influential. Chances are strong this is not going to lead to your product having better user experience.
If you’re not an end user of the product (really), or your not regularly talking to or observing your end users to understand how to design for them, seriously consider holding your tongue rather than giving your opinion.
3. You don’t measure it (you’ve probably not even defined metrics for ‘good experience’ let alone tried to gather data for it )
You hear talk of the ROI of design every now and then but in reality, Most organisations do very little about trying to measure how well they’re doing in giving their customers or end users a good customer experience.
Most companies have no clue about the acquisition cost or lifetime value of their customers, who their most valuable customers are, what behavioural characteristics map to high value customers. This is because, historically, we do functional accounting rather than customer centric accounting.
Most companies don’t have good acquisition metrics or retention metrics or engagement metrics, let alone cohort analysis.
Sure, there are lots of challenges in measuring User Experience, making numbers of it, but it’s super important. Your Net Promoter Score is only going to get you so far.
if you REALLY want to craft good UX you need to understand what people are doing and why, how effective your current UX is and what difference an investment in improving it could have. In NUMBERS. because, really, that’s what companies care about.
4. You don’t really care (companies who really care shape their organisations, their accounting systems, their culture around their customers)
This brings us nicely to the nub of the issue. Most companies don’t really care. They pay lip service to UX because everyone has started saying that UX is important and because apps like Path look cool don’t they? We need to look more like that.
Why can no other company do design like Apple despite lots of companies doing their utmost to rip off the iPhone?
Because the iPhone is a symptom of a company that massively cares about the user experience that their customers have with their products. Apple structures the operations of its entire organisation to support the creation of these kinds of products.
This is not new, we know this, right? but how many big corps do you see trying to copy Apple’s organisational structure, or the way they do communications and accountability, or where design sits in the organisation?
Pretty much none. Because there are too many people in cushy management jobs who have no clue how to operate in this new kind of environment and are too pleased with their current set up to make such big changes. And because most companies are too scared of what shareholders would say about making such radical changes that will cost money in the short term to make money in the long term (I give you Apples most recent balance sheet in response to that argument).
At the end of the day, most managers care more about this stuff than they do about UX. End of.
The UI is a symptom of organisational culture – you need to get beneath the skin to craft really, sustainably good UX
There are no Five Simple Steps to making your UX fabulous, there is no simple fix. All of these things are hard and most of them start much higher up in the organisation than the average UX designer ever gets to.
Good UX is cultural. If you want to hire a freelancer to ‘do UX’ , it’s like putting a plaster on gangrenous leg.
Design good organisations so we can design good User Experience
If you want better UX, stop looking at your design team and whichever new sexy UI you’ve seen this week, take a long hard look at your organisation and whether it caring about UX is part of its cultural make up and what evidence there is, beneath the interface, of this being true.
Go design some good organisations so that we User Experience people can make you some properly good UX.
I posted a note on Twitter earlier today about a friend of mine who calls himself (at my suggestion, having worked with him and knowing his skill set and interest) a UX Developer. Several people suggested in response that a UX Developer was not really a thing and that the term was either pigeonholing, unnecessary, redundant or ‘so 1996′.
With respect, I disagree. UX Developers are definitely a thing, and more than that, they’ve become an essential part of my project team mix, especially when I’m working on the UX of an application style system (which is more and more the case).
I’ve been fortunate enough to work with front end developers who have plenty of sensitivity to creating good user experience for as long as I can remember, it makes perfect sense that most front end developers are more interested in UX than those whose work doesn’t touch the UI. These are great front end developers, but, by my definition, they are not UX Developers.
A UX Developer is all of that – a front end developer with a sensitivity and talent for crafting a UI that is going to be better to use – but in addition to that they have a declared interest in understanding more about the User Experience work that goes ahead of the UI design. I doubt many of them would ever be happy doing pure user research, but they’re probably keen as mustard to run some of their own usability tests, guerilla or otherwise. They’d probably go nuts having to do some of the workshops and stakeholder communications that forms a key part of the garden variety UXer’s role, but they want to understand the strategy and customer insight that is driving the bigger picture product decisions.
There are different layers of user experience – these layers sit on a continuum between the pixel and the person.
UXers like me sit further toward the ‘person’ end of the scale, focussed on understanding end users, stakeholders, and what is going to work well for them as a wholistic experience. UX Developers are situated much closer to the pixel. If you’ve met a UX Developer, you will not be surprised to hear them tell stories of videoing a transition in an application so that they could slow it down enough to understand how it was working so they can recreate it. It’s what they do.
UXers like me (and I’m all about Prototyping in Code, I’m just not particularly good or fast at it) work very well with UX Developers. Trying to get the finest details of the UI right is not something that someone with my rudimentary development skills should be doing, and frankly, it’s not where my real strength lies. With a UX Developer on my team, I can involve them in the strategic / research aspects of the project as a second pair of hands, then work with them to create prototypes quickly, moving from sketches direct to code – and really nice feeling code – quickly. Eliminating the need for putting myself or my stakeholders through the wireframing process and being able to iterate on the ‘how it works’ part of the design from almost the very beginning.
The UX Developer, having been involved in the UX process from the beginning of the project, understands the rationale behind the product and design approach and is able to make good, consistent, UX decisions without needing every piece of UI defined. In fact, in my experience, they’ve probably made better design decisions than I would have made… well, sometimes.
Is UX Developer a synonym for interaction designer? Perhaps, except that it makes strong front end development a critical part of the skillset, which I think creates a completely different team dynamic and quality of interaction than an interaction designer who uses prototyping tools like, say, Axure (and there are still plenty of those). If you can’t produce high quality, production quality code, then I don’t think you’re a UX Developer. (Although, you may well be a perfectly competent Interaction Designer ).
How do you work with a UX Developer?
- get them involved in the strategic parts of the UX process – defining the product, the audience, the research, all the fun stuff. Let them increase their UX skillset and make sure they understand WHY things are happening the way they are in the project.
- sketch together and get prototyping in code as quickly as possible. This is not a senior/junior relationship, this is the dovetailing of compatible skills to get to a better UI, faster.
- share ownership of the UX, don’t feel like you have to make all the design decisions, let them own the finer details of the UI and you focus on the bigger things (that are actually pretty hard to stick to when you do get to obsessing about the details on the interface)
- allow yourselves to push and pull focus from the strategic ‘person’ level to the pixel level – it is difficult for one person to maintain focus on both ends of the spectrum at the same time – a team like this helps enable this rapid shifting of perspective more effectively.
A UX Developer is not a silver bullet. You can’t work this way on all kinds of projects for all kinds of people, and it can be hard to find a good UX Developer to work with. I’m a freelancer, so I used to travel solo from project to project, but since I’ve started working with UX Developers, I now like to BYO team (where possible) and an essential member of my UX posse is a great UX Developer.
Works for me, your mileage may vary.
In the process of writing the book (A Practical Guide to Strategic User Experience, yes, it’s coming, I promise!) I found myself surprisingly flummoxed when it came to writing about Experience Strategy and the role it plays (or should play) in business strategy. I’ve talked about Experience Strategy with clients over the years, written Experience Strategies for projects I’ve worked on, and worked under the illusion that I was clear about what this actually entailed… however, in coming to write about and thereby define what it meant, it all of a sudden felt very fuzzy.
What is Experience Strategy?
Having done a review of some of the significant contributions to this topic from the UX community, I found myself dissatisfied… Steve Baty wrote a detailed essay on the topic for Johnny Holland some time ago. This essay does address a lot of significant issues around what businesses should be doing to create better experiences as differentiating opportunities… but at the end of it I can’t help asking myself – isn’t this just a part of a good value proposition? And where and how does/should a User Experience person get involved in these kind of activities that go way beyond the interface and into the mechanics of how the entire company functions?
Then I discovered Customer Experience (CX).
Turns out there is this whole other profession, born, it seems, mostly from the marketing discipline, who have an active interest in orchestrating company wide good experience for their customers. They are experienced in making strong, financially driven business cases to management at the highest level, getting decent budgets and then investing in infrastructure that enables an organisation to deliver good customer experience (such as ‘single view of the customer’ and ‘voice of the customer’ programs that enable an organisation to aggregate their understanding of a customer into one view (how rare is this for most established organisations, and how crippling is the typical fragmentation), and enables an organisation to hear and respond to what their customers are saying to and about them.
Reading some of their books (I particularly enjoyed this one) it strikes me that they have a much more mature and structured way to approaching company wide good experience than we User Experience people (generally) do. Given the choice of having a Chief Experience Officer (CXO from a UX background) or a Chief Customer Office (CCO from a marketing/CX background), I’d probably choose the latter – for the more comprehensive, well rounded view of the organisation and all its working parts than the interface obsessed UXer is likely to be. And I’m more confused about where Service Design fits into all of this than ever.
I’m writing up a lot more about what people who do CX do, and what they think about in the book (and I’ll no doubt share some more of that here, now that I’m back writing again!) but I wanted to take a moment to flag how – from my own experience and a lot of the people i’ve been talking to – we don’t really know people who do Customer Experience, in fact, most of us probably don’t even know they exist and will be immediately skeptical upon discovering them.
Similarly, in reading what they write about, it is disturbing how little reference Customer Experience people make to User Experience people. I’ve come across several references to human factors and usability, but you’ll almost never find Customer Experience and User Experience in the same book/article/room.
This worries me.
It worries me because I think that actually, this is possibly one of the best, strongest alliances that could exist in companies. It worries me because so much of what CX people do is what we need done so that the experiences we’re designing have a real chance of being good. And it worries be because I think we as UXers could really benefit from understanding, in greater detail, a lot of the structure and discipline and business focus that CXers bring to our combined cause.
We’ve done a lot of hand waving about Good Experience and Experience Strategy over the past few years, but we’ve done very little to explain HOW to make this happen. Getting to know our Customer Experience colleagues, getting more of them in our organisations and making them aware of our existence could really help move this forward.
I had the opportunity to attend Drupalcon London this week and to talk some more about the Prairie Initiative – what is is, our goals, and the progress we’ve made so far. Unfortunately the audio in the session recording was very poor, so here’s an outline of what I presented.
Recently I came across a ‘register’ page on a Drupal site that was obviously Drupal (in a bad way). I thought – I wonder what it would be like for people who don’t know anyone in the Drupal community to come to Drupal.org and try to find how they can contribute their time, skills and experience to fixing the design of that page.
Try this exercise – go to Drupal.org homepage and log out. Now imagine you’re here looking to help out in whatever your area of expertise is (if you can’t think of anything, just pretend you want to help fix the usability and layout of that register form). Where would you go?
If you headed into Support and Community (which is probably the most sensible option) you’re hit with walls of text, no keywords that confirm that we want people like you and where you should go. Very little sign of a community at all, basically just a list of channels. It’s less than inspiring and a little intimidating.
IRC is not a solution – it scales badly, it’s intimidating and unfriendly if you’re new and unknown, and for a great swathe of us, it’s very unfamiliar.
Groups – try going there and logging out. This is also a pretty poor introduction to the community for newcomers.
Forums are also pretty haphazard and not really a recommended entry point.
If you decide to ‘register’ (for what, it’s not really clear) you enter a process that is riddled with small but unrelenting errors or bad experiences – from the lack of client side validation on the forms, to the ‘access denied’ heading once you’ve completed the form successfully, to the personality free email you receive (and the fact that we have even designed the sign up process this way – making the user do the work to reduce the spam on Drupal.org presumably)
Having completed the registration process, you’re left pretty much stranded on the final page (which announces that it’s unsubscribed you from a mailing list you’ve never heard of) – the dashboard for newbies doesn’t take advantage of a great opportunity to help you get started. Fortunately, in the journey that I was exploring – search does work, and if you make your way to the Usability Group page (which has been pretty well thought out and structured to be newbie friendly), you’re set – you can actually find some likeminded people and start finding your feet in the community.
These are all little things – things that could reasonably easily be fixed. And some might say that if you can’t handle this then you’re probably no use to us anyway – Drupal gets a whole lots hairier than this! And that’s a fair point – afterall, if you do make it through the onboarding experience, sooner or later you’ll meet the issue queue….*gulp*
The onboarding experience into the Drupal community on Drupal.org is a bit of a car wreck. Sure, it’s just a series of little things that could be relatively easily fixed – that’s not the point. The point is that we either have never bothered to check that the sign up / onboarding experience is any good, or it’s not high on our priority list. No one owns this job. This tells us some interesting things about the Drupal community and sends some messages about what we value:
- We don’t really value our newcomers or care about the experience that new people coming to join our community and contribute have when the try to get involved.
- We don’t really care about the quality of the products we create and the spaces we reside in (there’s no broken windows policy on Drupal.org), we don’t take pride in our flagship(?) website.
- People who do manage to get involved using this process are to be admired for their determination!
- There is an alternative onboarding experience – person to person mentoring and hand holding, particularly for those who have been hired by a Drupal shop or are working in an organisation that is adopting Drupal. This is a good process – perhaps it’s the one we really care about? Perhaps we don’t really want people to randomly stumble into the community? Perhaps – these are all questions to think about…
We need to work out what our position on all of this is.
- What kind of people do we want to have in our community?
- How do we want to ‘recruit’ them – do we want random people coming to the community from our website? (hobbyists etc?)
- What kind of an experience do we want it to be to sign up to be a part of Drupal?
- What kind of experience do we want to be to be an active contributor to Drupal?
- How important is this to us? How much do we care?
It’s ok if we decide we don’t care about it so much. The right answer isn’t necessarily ‘the user experience must be fantastic’ but we should stop paying lip service and actually not doing anything about it, and not committing any resources to it.
We need a vision for what we want the experience of Drupal.org for new and long term contributors to be like.
Backcasting is a great exercise that helps us work out what we’re aiming for and then a roadmap/strategy to work towards that outcome.
For me, I think this is important. I believe that the way our spaces are designed is very influential on the way that we behave within them. Drupal the community and Drupal.org are both pretty good at tactical problem solving, but both pretty rubbish at defining and agreeing and acting on larger strategies.
This is what the Prairie Initiative is interested in – ways that we can design social spaces on Drupal.org that are more conducive to giving new contributors a better onboarding experience and that makes it a better, more productive environment for longer term contributors.
The Prairie Initiative is not a project. Rather, it is a family of projects that share a connection to a common set of goals. The goals of the Prairie Initiative projects are:
- to improve the collaboration tools on Drupal.org so that we can do more and work better together and make Drupal better, faster; and
- to grow the pool of contributors by making Drupal.org a better and easier place to become a contributor – to make it less intimidating to people who want to get started contributing.
Some of the projects within Prairie that we are moving forward with at the moment include:
- Topic page – a place where activity from across the Drupal network can be aggregated and people interested in this topic can ‘follow’ the topic. This allows people to self identify their expertise, people to find likeminded peers in the community, people to find mentors, people can more easily keep up with activity on Drupal.org related to their topic.
- Profile page – a better designed profile page allowing us to share our expertise and experience and interests and activities within and without of Drupal more easily, and a way to make the reputation system known to ‘insiders’ accessible to those who are new and as yet not well connected to the community.
- Issue Queue - exploring ways that we can change the issue page so that it lets us work more effectively together.
- Notifications – exploring how we can make it easier to keep up with activity on Drupal.org you’ll probably be interested in without requiring you to be on IRC, have people ping you links, or be scouring issue queues and groups endlessly to keep track.
I’ve been trying to do as much of this as I can in my spare time but – realistically – I’m not a great candidate to help lead this project. It really needs someone who works in a Drupal company and who gets some ‘gardening time’ (or equivalent) to work on community work without having to sacrifice income or time with their kids.
Having asked around a little to see if there might a chance of getting a little financial support so that I can work on this in place of client work, it seems clear that Prairie is currently not a very appealing investment.
I probably need to work on my pitch, I guess, but that’s pretty demotivating. Especially when you not only need someone like me doing cat herding, ‘product management’ and some UX work, but we really also need a tech lead (someone like this who, unfortunately, is much the same as me in terms of having no gardening time).If you’ve got time and inclination to take this on, step up. Otherwise, regretfully, it’s likely Prairie will flounder, as it has for the past month or so after an initial cracking start (this is entirely my fault and not for want of people willing to contribute their time).
I know this sounds like a huge critique of the work that was done by the redesign team and by those who continue to work on Drupal.org – please know that there are many, many things that need working on and people like Neil Drumm and Lisa Rex and others are doing great work that goes largely unrecognised and unthanked. This is absolutely NOT a criticism of their work and I’d like to thank them and the others who are working with them for continuing to incrementally improve Drupal.org.
We might have re-THEMED the entire site but there was a LOT that never had the chance to be reDESIGNED. These are very different things.
We still have much work ahead of us – if we decide we care, enough.
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)
- Facilitation at a glance: Bens (Leisa’s bible. Available in a spiral bound edition!)
- How to run a great workshop: Highmore Sims (an alternative to Gamestorming)
- 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).
Other people’s write ups
If we’ve missed any others, please let us know and we’ll add it here.
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?
Are you in?
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”
The AlphaGov project responded, setting out two overarching objectives:
- 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‘.
In a recent blog post about their agile methodology Project Manager Jamie Arnold describes exactly what this ‘obsession with user need’ entailed:
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’).
The team sets out a really thoughtful understanding of what it takes to make a service properly 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.
As you may know, I’m working with the Drupal community on a (voluntary) Social Architecture Project called the Prairie Initiative.
We’re looking to tune up Drupal’s collaboration tools so that it’s an easier, more efficient and more collaborative place for all the different disciplines that Drupal needs to be great.
If you’ve got any experience attempting to, considering or actually contributing to Drupal, I’d really appreciate if you’d come take our sentiment survey. We’re taking a benchmark now and will check back every quarter to see if and how any changes we make impact this and some other metrics.
I’m taking a couple of surveys to explore our priorities and experiences hiring and being hired as UXers.
If you’re a UXer: Come tell me what you think about when you think about taking a new job.
If you hire UXers: Here’s a survey for you
This came out of an interesting exchange on Twitter the other day with a colleague who posted a Tweet about job opportunities at his company and promoting the opportunity to work on big brands if you worked with him.
He also has an awesome team working with him. I suggested to him perhaps he should be promoting that as well or instead.
I got to wondering (again) how how other people saw the world – what was important to UXers when they were thinking about a new job and what the process was like for finding, interviewing and taking a new job.
Being a good UXer, it was only logical to take the next step and do some research.
I’ll collate the results and share them back in a few weeks.
I was in Chicago the other week and out with a friend who has multiple, severe dietary allergies. She can’t eat dairy, eggs, wheat, and a bunch of other stuff. Eating out is a bit of a pain for her but, if she doesn’t get it right, a whole lot more pain later.
We were in one of those posh grocery stores with its own little cafe and, after much deliberation, decided what to eat. The girl who was taking our order had a desk that was positioned in a way that made it easy for me to look over her shoulder at the interface she was using to take the order.
Taking a standard order was pretty easy – you just pressed the button that said ‘thai chicken salad’. Simple.
Then it came time to take my friend’s order. First she had to press the button that said ‘thai chicken salad’ and then my friend asked that she make a special note for the chef about her allergies. To do this, the girl had to press the notes button and then type the special request in. No assistance from the UI whatsoever. And that’s when the trouble struck. Spelling.
Without wanting to ridicule her – she failed to spell ‘dairy’ even to the point that you might guess what she intended. There was no way she was ever going to accurately convey my friends requirements to the chef. I watched, quietly, as she tried and failed to type the instructions and eventually sent the following note through to the chef:
Here’s the thing. Our order taker is far from an edge case. Jonathan Kozol has written extensively about illiteracy in the US (and there are similar problems in many parts of the world). He says:
Twenty-five million American adults cannot read the poison warnings on a can of pesticide, a letter from their child’s teacher, or the front page of a daily paper. An additional 35 million read only at a level which is less than equal to the full survival needs of our society.
Together, these 60 million people represent more than one third of the entire adult population.
The largest numbers of illiterate adults are white, native-born Americans. In proportion to population, however, the figures are higher for blacks and Hispanics than for whites. Sixteen percent of white adults, 44 percent of blacks, and 56 percent of Hispanic citizens are functional or marginal illiterates. Figures for the younger generation of black adults are increasing. Forty-seven percent of all black seventeen-year olds are functionally illiterate. That figure is expected to climb to 50 percent by 1990.
Fifteen percent of recent graduates of urban high schools read at less than sixth grade level. One million teenage children between t velve and seventeen percent cannot read above the third grade level. Eighty-five percent of juveniles who come before the courts are functionally illiterate. Half the heads of households classified below the poverty line by federal standards cannot read an eighth grade book. Over one third of mothers who receive support from welfare are functionally illiterate. Of 8 million unemployed adults, 4 to 6 million lack the skills to be retrained for hi-tech jobs. (more here)
This is a big problem. This is not an edge case. And, before you say it, the answer is not icons. (The number of times people have told me that the solution to designing for an illiterate audience is icons. Now make me an icon for ‘vegan’).
I don’t have the solution, but I do have a couple of guiding thoughts.
- People are better at recognising words than they are at making them from scratch. My 3yr old can recognise words in books that he is familiar with but he can’t read (no matter what he tells you). This is true for all of us. Recognition is far easier than recall. Think about foreign languages – most of us can read a lot more than we can speak, right?
- Think about mission critical tasks. Things that, if not done right, could hurt people or have significant negative impact on people or business. Don’t give people a blank box to fill in when you’re designing these tasks. Give options (in words, not icons). Let people recognise and select, don’t make them remember how to spell stuff.
Jan Chipchase has done a lot of design research work with Nokia in the area of device design for illiterate end users and supports the view that making the interface easy to ‘learn’ (which largely means ‘remember’ for people who are less literate), is the best approach – better than icons or audio menus or all other apparently obvious solutions.
This presentation is worth a flip through if you’re interested in his experience and outcomes.
None of this is new, granted. But it’s not something I hear us talking about anywhere near enough. Watching that poor girl struggle with that interface and because of the poor design put my friend’s health at risk was a real wake up call and reminder to me of how wide-spread and significant this issue is.
I’m resolving to be more aware of this in the future and I hope you will to.
(And, if you’re in the UK, consider signing the Save Bookstart petition – this invaluable service puts books into the hands of young children – having books in the house in childhood is a key indicator of later literacy).
I’m excited to be making a start on my current contribution to Drupal which to help drive a project code named Prairie. This is a project with two big, ambitious goals:
1. to improve the collaboration tools on Drupal.org so that we can do more and better work together and make Drupal better, faster.
2. to make Drupal.org a better and easier place to become a contributor – to make it less intimidating to people who want to get started contributing to Drupal, coders and non-coders. To increase the number of Drupal.org members who are actively contributing and to recognise a wider range of contributions.
This started out as a ‘Redesign the Issue Queue’ core conversation at Drupalcon in Chicago, but rapidly increased in scope so that it’s now really more accurately described as a Social Architecture project.
For those amongst us who are actively contributing Drupallers, comfortable with the Drupal Groups infrastructure, there’s a group you can join and contribute to.
For those who find the Groups Infrastructure perplexing or just plain frustrating (and you can count me among that number – you’ll find Groups Usability as part of the scope for this project), I’m going to try to keep you up to speed here and I’m experimenting with sharing some screenshots that we can annotate together… we’ll see how well that works – at any rate, I do want to try to open the discussion up outside of the Groups infrastructure so that we’re not just a bunch of insiders talking amongst ourselves.
The issue page – Designing a tool to fit the task
So the first thing I’d love for you to give some attention to are some initial ideas on redesigning the Issue template.
The ideas in this rough wireframe draw heavily from Quora and Open Ideo and try to address opportunities for us to make our discussion more comprehensible and focussed, as well as to make sure that they move through the stages of problem solving (possibly with custom designed interfaces for the specific requirements of each phase) to make it easier to ‘call in the troops’ from the various disciplines when they’re required and also to create spaces that are more appropriate for each discipline in turn (rather than all trying to squash our requirements into the one UI). It also introduces the concept of collaboratively naming an issue and providing a summary for it.
You can take a look and provide your feedback on this wireframe and these ideas here (or in the group if you prefer).
For those who are wondering, no, I’m not being paid to do this work. I’m a freelancer, so I have to take time off consulting, playing with my kids or sleeping to do this work.
I’d happily take sponsorship to do so though, if you think the work is important enough for me to be able to dedicate more of my time to working on it. Let me know if you’re interested.