I had the pleasure of mentoring at the first Design Jam in London today. The event brought together about 50 UX designers from student to seasoned professional to form teams of about 4-5 to design a solution in response to a design challenge.
The challenge for today was:
What is the ideal interface to keep track of previously viewed online content, across multiple devices and locations?
You can see what the teams came up with by checking out each of the team wiki pages.
It was a lot of fun running around from one team to the next seeing what they were working on and, hopefully, helping to guide them towards a solution to present at the end of the day. It was really interesting to be able to observe nine teams approaching the same design question, and to see where the common challenges emerged. Some observations and advice:
Spend less time choosing your idea and more time defining it. Specifically, what problem are you solving?
Peter Drucker, a business management guru said ‘Ideas are cheap and abundant; what is of value is the effective placement of those ideas into situations that develop into action.’ Nowhere is this truer than at DesignJam. If you want to have something interesting to present at the end of the day, you need to quickly identify a specific problem that you can solve, and then you need to be able to describe that problem in a concrete story. ‘ Keeping track of previously viewed online content, across multiple devices and locations‘ is so broad as to be meaningless from a designer’s perspective. But, being able to re-find a hotel website I saw a week ago when considering a holiday, or the location of the event I’m going to tomorrow, or finding the link to that funny website my friend emailed me about the other day – those a real, concrete, solvable problems.
It doesn’t really matter which one of these you choose, what matters is that you quickly identify a relatively small, concrete problem that you can solve and that you can describe the problem clearly and believe that the problem is real, and describe how life will be better for people with this problem resolved.
The elevator pitch technique is one method you might want to consider to help get yourself to a stage where you *really* *clearly* understand what you’re working on and why.
I really can’t stress how important this part of the project is – this is the foundation on which all the rest of your work is built on, and the most important thing is not *which* idea you choose, it’s about how clearly you’ve defined the problem you’re going to solve and the value you’re going to deliver – your value proposition.
Define your audience by understanding the important behavioural characteristics.
Ah, the vexed issue of personas.I saw a lot of personas at DesignJam today and very little evidence of them being used as part of either the problem or solution definition. Personas *can* be very valuable but only if they’re used in the right way and that is as a tool to help you understand what are the behavioural differences that are significant to your design problem, preferably informed by real data points (your mum, husband, grandfather do count as data points in a DesignJam scenario!).
Time is precious in a DesignJam environment (as it is on all the project we work on, right?) – we need to make sure our time is being spent in the best possible way. I witnessed too much time being spent making personas because it felt like the next logical step in the design process. In most cases, I would have preferred to have seen groups spend time defining usage stories or tasks and then, if it became clear that there were divergent behaviours and we needed to choose to support one kind of behaviour or another, then capture that somehow – and perhaps a persona is a good way to make that behaviour more understandable.
Having said that, one of my favourite designs today emerged in response to an ‘extreme’/edge case persona – so persona’s can be a starting point – but what drove this design was not the persona as such but the behaviours we were able to identify that were specific to that persona (and very different from our own) – in this instance, the use of links in email as a primary trigger point for viewing websites, also getting relatively few emails from relatively few senders.
If you must do personas, then do as few as possible. If you’ve got more than three personas, I want to know why.
If you’re going to spend time making personas, then I want to see you actually using them in your design process.
Get sketching! Generate and evaluate lots of design solutions before you start wireframing
So, all that time you probably spent trying to come up with A Good Idea, spend it here instead. Quickly generate as many ideas as you possibly can. I reckon it was at least 2pm before I saw people starting to sketch out ideas at DesignJam today (teams started tackling the design problem at 10am and were supposed to present at 4pm).
A really popular approach to generating lots of ideas at the moment is to do 6-up wireframes another technique I quite like is Design Consequences. However you do it, the key is to get as many ideas as you can onto paper. And then – once you’re out of ideas – to use your clearly defined design problem and whatever user behaviours or personas you have defined to evaluate which aspects of which ideas are strongest.
Once you’ve evaluated the first round of ideas and you’ve got fresh ideas in your head – do another round of visual brainstorming. Rinse, repeat until the answer becomes obvious. Eventually, it will. Then everything will start falling into place.
A group is a resource and a liability (user your numbers, appoint a facilitator)
When you’re designing with a bunch of other designers (or actually, with any group at all), there are two key things to remembers – firstly – use all the people in your team, get them all actively designing, make sure everyone is sketching and contributing ideas, remember to do things quietly and individually sometimes and to do things collaboratively and together at other times.
Secondly – make sure that someone is driving the team – keeping you on a schedule, working out how you’re going to get from here to the end of the project, making sure that you’re staying true to the project problem you’ve defined, making use of the personas you’ve defined, keeping everyone focussed, on track, and working productively. Have this discussion at the beginning of the project rather than waiting for a ‘natural leader’ to emerge (especially if you’re working somewhere where politeness is at a premium and potential leaders might be nervous of treading on other team members toes)
Pitch clearly and persuasivelyThe day wraps up with each team presenting their design to the larger group – for me, this is as important as all the design work you’ve done throughout the day. A clear, focussed and compelling presentation enables you to convey to the group what you’ve been working on, what problem you’re solving, who you’re solving it for, and finally, to show the design solution you’ve come up with.That clear value proposition and the user stories or tasks that you’ve defined come in handy yet again and show be key to framing your work in a way that is understandable and compelling to your audience.
Don’t think of this as ‘just the presentation’ – as much as any of the design work you’ve done throughout the day is great experience and practice for your day to day design work, the same couldn’t be truer for this part of the process. As designers, we’re only ever as good as the design we can convince our client/team to implement and this means that we’re constantly presenting our work – explaining what the problem is, why we’ve done what we’ve done. This is something that, as designers, we should be able to do at the drop of a hat because of the preparatory work we’ve done earlier in the design process.
While these thoughts are specifically in response to the DesignJam day, I think they’re pretty much universally true to any design project and very common issues that come up on projects I’m involved with. The hothouse environment of DesignJam brought it home, yet again, how difficult it can be to facilitate a team around designing a solution – it’s tough work but very rewarding.
I’m having another one of those moments where I feel terror and delight in equal parts. This is a feeling I’m becoming increasingly familiar with and almost welcome as a good omen. The reason, this time, is that I’ve agreed to write a book for the team at Five Simple Steps which will be called A Practical Guide to Strategic User Experience.
This is not the first time I’ve contemplated writing a book, but it’s the first time that I’ve actually managed to make the commitment to spend my time doing this and not something else – the main reason being that I’ve found that on the projects I work on these days, the biggest impediment to getting good UX work done is almost always strategic.
The funny thing about strategic work, though, is that there isn’t a process for doing it. There isn’t a series of methods that will always work. It’s more a way of thinking, a way of seeing things, a mindset. It’s really hard to ‘teach’.
I really noticed this when I thought about how I might do a workshop on Strategic UX for the upcoming UXLX conference. Subsequent conversations with a few people who I thought might have some easy answers for me (see my earlier post re: mentoring) also seemed to indicate that this might be an area that needs some work done on it.
There’s a lot of writing out there on strategy, on design thinking, on organisational change, and – of course – on user experience. There’s a growing body of work out there on customer experience and service design. There’s not much for those of us still want to be really great user experience practitioners, but who want to be influential in the way that our company (or our client’s company) thinks about our users’ experience beyond the interfaces/flows that we might be tasked with designing.
So, that’s what this book will set out to do – to give you a grounding in strategy from a range of different perspectives, to help you acquire the skills you need to to be effective in influencing strategy at an organisational level, and to learn how to facilitate the creation of an experience strategy and then help drive that strategy both outwards and throughout the organisation, and to apply that strategy to the day to day, tactical work.
And now, to my request for help…
… I’m really interested to talk to user experience practitioners with strategic UX war stories. I’d love to hear about:
what you found most challenging,
where the biggest problems lay,
what techniques really worked for you, and what didn’t!
I’d love to hear stories from ‘innies’ (inhouse design teams) and ‘outies’ (consultants),
I’d love to hear from big companies and small.
I’d love to hear about how being strategic has changed the way you do user experience (or not).
If you’ve got a story/thought/rant you’d like to share, please either leave a note in the comments below or drop me an email: [email protected]
In the book, the author advocates using the term ‘customer’ rather than ‘user’ because your business colleagues will both understand & value a ‘customer’ more than a ‘user’. This is not really the reason that I would consider the change, though. It’s actually more about me and the kind of work I do.
The main reason that I would consider changing to a Customer Experience Consultant is because I’ve found that more and more the scope of ‘experience’ that I need to access and can have an impact on goes well beyond the website. Despite the fact that I have much more expertise in engagement with customers in digitally interactive environments, more and more the holistic experience that the customer has with the business I am designing for is relevant and important in the strategy, recommendations and ultimately design work that we do.
By defining myself as a ‘User Experience Consultant’ I am effectively signaling that my scope, interest and usefulness starts and ends at the digital border (however fuzzy that border may be becoming these days). I don’t think this does anyone any favours.
I’m also on the record as not being a huge fan of the term ‘user’, because there are so many more descriptive and humane alternatives. It would be a nice fringe benefit for me to get the word ‘user’ out of my job title.
Of course, there are downsides to this. ‘Customer’ is also a fairly limiting term, it implies consumer focus, it doesn’t allow for differentiation between the person who is ‘buying’ the product/service and the ultimate end user (who can sometimes be very different people!), and it is often too generic and not descriptive enough for companies we engage with, where ‘customers’ are called ‘members’, or ‘readers’, or ‘subscribers’ for example. (Were I working inhouse I could tailor my title to suit, but as a freelancer this is more challenging!).
Another downside of this change is that it creates yet another definition for us (the IA/UX/IxD and however else we already define ourselves) to argue over, it is another title for clients to learn, and it doesn’t give any clues around ‘usability’ which is still something that a lot of clients look for when they are really looking for user experience (but don’t yet know it exists).
I’m not really one for labouring over definitions of what we do, and I don’t think I’m going to go out and change my business cards tomorrow, but it’s something I’ll be mulling over for a while I think. My gut feel is that there is something important here, but also a bunch of problems. I’d be very interested to get your thoughts on this as well, included suggested alternatives.
As you may know, I spent a few months this year working with Mark Boulton and the Drupal community to try to make Drupal 7 (their upcoming release) a Great User Experience. I’ve spent the past weeks reflecting on that experience and trying to understand what we learned from that project and with any luck this will be the first of several reflective posts.
It is all to easy to make excuses for why designing in an open source community can be tough. Certainly there are lots of communication challenges and we don’t necessarily have the right tools. Some people focus on the relationship between designers (minority) and developers (majority) in these communities – I think to do so is to focus on a symptom of the problem and not the cause.
We faced many challenges with the D7UX project, but the greatest of all was to convince the community that the changes we were suggesting were actually going to result in an improvement to their project. There are many who steadfastly resisted our approach and who continue to do so.
It would be very easy to take this personally and to argue about the details of the way the design works (and I most definitely include Information Architecture when I say design). This would also be a fairly typical Drupal thing to do. Actually, I think almost all the issues stem from a much more fundamental place – defining the real purpose of Drupal and it’s real primary target audience.
From the very outset our goal with D7UX was to make Drupal more accessible to people outside of the Drupal community and less technical people – people who didn’t even know what PHP was let alone how to code it. Verity and Jeremy who emerged as part of this definition embody the target audience that the design work that Mark and I were doing in this project. This approach is representative of the goal to make Drupal more of a ‘product’ – an out of the box CMS solution that non-technical users can drive. This is key to the goal to increase the reach of Drupal, as Dries outlined in his keynote at the recent Drupalcon.
There is one big problem with this approach, particularly if it touches the very core of Drupal. The changes that are required to the interface to really achieve the goal that we were tasked with – to really make Drupal understandable to Verity & Jeremy has the consequence of making Drupal a less efficient and enjoyable place for Drupal developers to build cool stuff.
Drupal developers (and some designers!) who want to build cool things with Drupal are the core of the Drupal community. They are the people who make Drupal the incredibly vibrant community that it is. Without these people, Drupal becomes a shadow of it’s current self. These people are more than an important audience, they are the most important audience. What this audience wants is not Drupal as a product that Verity & Jeremy can use out of the box, they want a developer toolkit that gives them more and more flexibility and capability to build cool stuff, and to push Drupal way beyond the realms of a simple Content Management System.
And so we have this tension. Drupal as a ‘Consumer Product’ and Drupal as a ‘Developer Framework’. Currently, the official direction is that the project is going to attempt to be both. I think this is a serious problem.
The target audiences for each of these objectives are so far removed from each other in terms of their tasks & goals, their capabilities, their vocabulary, their priorities. An attempt to devise an interface to suit both will result in an outcome that I expect we’ll see in the release of Drupal 7 – that is a compromise to both parties. Verity is still going to need a lot of support to get anything done in Drupal 7. If Drupal 7 had been designed primarily as developer tool, it would be a much more focussed and efficient tool for developers. As it is now, it is hopefully an improvement on Drupal 6, but certainly not the best that it could be for developers.
For Drupal to really succeed, a decision has to be made, and I think there is only one decision that can be made. Drupal 8 should be designed with developers as the primary target audience and the language, tools, interface should be designed to support them in their goals of building really amazing stuff using Drupal.
That doesn’t mean that there is not still a lot of work for the User Experience people in the Drupal community to do – there is still an enormous learning curve even for those new to Drupal who have great PHP and other technical skills. It’s going to be much easier to address that learning curve with a more finely targeted audience in mind – or more importantly, with the right target audience in mind.
So what of Verity & Jeremy? How will they ever come to know and love Drupal?
There are a number of ways that we can address the experience of non-technical users of Drupal and to ‘productise’ Drupal as a content management system. The most obvious is to design and develop an admin theme that is specifically targeted at these end users that can be applied by developers once the development work is done and the site is being handed over for administration.
I’m not sure where the incentive to design and develop this theme comes from (given that it doesn’t exist today it strikes me that there is a problem here incentive-wise).
There are also opportunities to be explored with installation profiles (see above though re: the fact that they don’t really exist now and no one seems motivated to work on them, where is the incentive?).
And, of course, we have the emergence of tools such as Buzzr from Lullabot and Gardens from Acquia, perhaps also products like Open Atrium from Development Seed can included in this list.
A tough decision but a necessary one
I know that for many people the idea of making a Drupal that Verity can love, making something that can actively compete from a UX perspective with the likes of WordPress, is a grand aspiration. So it is, but unfortunately I also think it is the wrong aspiration for Drupal core.
The sooner we focus on the core target audience of Drupal core – the developers – and commit to making a user experience that supports them in their use of Drupal, the sooner we’ll really have actually achieved a really Great User Experience for Drupal.
If that is really our goal, then let’s get focussed, let’s re-write the design strategy and principles, and let’s take the work we’ve done already and refocus it more tightly on the community we know and love. Focussing on the strength of Drupal and then looking for new and innovative ways to create and motivate the Drupal community to do a better job of looking after our Verity’s and our Jeremy’s.
My name is Leisa Reichelt. I am the Head of User Research at the Government Digital Service in the Cabinet Office.
I lead a team of great researchers who work in agile, multidisciplinary digital teams to help continuously connect the people who design products with the people who will use them and support experimentation and ongoing learning in product design.
If you're interested in working with me or would like to talk more please email me