I was fortunate to be invited to speak at the recent GeeknRolla conference in London and took the opportunity to share some tips for making your business more user focused with the largely tech start up crowd. I do lots of work with start ups these days so I understand that there are all kinds of ‘resource’ challenges in the early days. That said, there really is no excuse for not making an effort to engage your potential end users in your design and product development effort.
This presentation covers what I consider to be the four main areas of user experience, being:
Choosing an audience. Startups (and small businesses in general) are notorious for wanting to avoid this step, claiming that their product/service is targeted at ‘everyone’ and that they don’t want to ‘restrict themselves’ by choosing a specific primary target market. Big mistake – design for everyone and you design for no one. Design well for the audience you’re most interested in and the rest will follow.Another common problem for starts ups is that they are actually designing for themselves (they are their own target audience) but lose focus by trying to design for ‘users’ without defining who those users are. If you are your own target audience, that’s fine. Admit it and go with it. Don’t lose focus.But probably the most common problem I come across is that while the start up makes efforts to be ‘user focussed’ it fails to admit that it’s *real* target audience, for the moment at least, is the investors who may give them more money if excited enough. What investors want to see and what early users of your service want are two very different things. If you are designing for investors, that is fine – admit it and go with it. You can re-focus on the real users of your service later.
Understanding your audience: there are *lots* of ways to get to know your audience but obversational research (sitting down and watching and asking questions) is far and away the most effective in my experience. Yes, get your metrics in place, do your alpha release, watch your twitter stream, but DO find and observe potential users of your service, and do it regularly. Despite the rumours, it doesn’t have to be an expensive and time consuming exercise – in fact, you can do it yourself and you’ll probably learn more than you’ll know what to do with. There’s no excuse for not knowing exactly how users interact with your product, what works and doesn’t work and – most importantly – why.
Applying your research in design: once you’ve done all the research, how do you make use of it in your design? One simple way is to make some ‘personas’ – basically some pretend users who are based on your research and who can sit around the table with your team and be ‘involved’ in the decision making. This is a MUCH better way of getting good user focussed decisions made than asking ‘what users like/do’ which is a totally nonsense question with no answer. Rather, you can ask ‘would Keith (our persona) like it if we added that service?’, ‘would Lillian (our persona) understand that sentence on the homepage?’, ‘what would Frances (our persona) most like us to do in this next development cycle?’. It might sound a little nuts but it really does work.
The other thing I really recommend is that you hire the best designer you can get your hands on as early as possible, but don’t ask them to ‘design your website’ or application or whatever. Rather ask them to design a visual styleguide that you can then give to a less ‘resource intensive’ team member to apply now and into the future. This is the best way to get great value from a good designer – you let them do the work they do best and you get a road map for the future that will protect the design integrity of your service. The styleguide will include a few key templates but also a bunch of information about the grids that should be use, how colour and typography should be applied and a whole host of other very useful information.
Think big and small: Last but not least I encourage you to look at user experience from the micro and the macro level. Do wonder if that button is in the right place ask whether moving it might improve revenue, but don’t neglect to ask whether people understand the overall proposition of your service and if they’re even going to get to that button in the first place. User Experience is a layercake and it starts with your proposition – it is all too easy to get too close to your product and not realise how inpenetrable it is for newcomers. So, think big and small.
Where do I start?
Most of what us User Experience people do is not rocket science – it’s just education and a whole lot of experience and a passion for what we do, much of this you can do yourself and there is a lot of material in books and online that will get you off to a flying start. The two books I find myself recommending most often to my start up clients are Don’t Make Me Think and The Paradox of Choice (the first one is more hands on than the second, but the second explains a lot of why the first one works).
Another thing I find myself doing more and more often is teaching my clients to fish – that is, doing quick training sessions that give them the essential skill set they need to successfully do the four things I set out above, all by themselves.
If you’re interested in learning these skills (or having someone in your company know them!) and bringing User Experience into the centre of your company then perhaps you might be interested in a one day Hands On User Experience training course that I’ve designed. I’d be more than delighted to show you how I do what I do, and I guarantee you’ll see the benefits in many more places than just the usability of your website/application!
Earlier this week I participated in a panel to discuss the perennial question of ‘why aren’t more women involved in tech and what can we do about it’. It’s always a treacherous discussion to get involved in and if you think you know how it would have played out, you’re probably right, except you probably wouldn’t have expected Milo to have been quite as … let’s go with ‘provocative’ as he was.
It is very difficult to engage with this subject area without offending people, people people feel excluded or defensive – the sad thing is that I don’t think anyone who tries to start these conversations intends to do any of these things (and many thanks to Mike Butcher for finding a place for this discussion in the GeeknRolla program).
What we want is something practical we can do about it.
There was on this panel, and elsewhere, a lot of talk about improving the ‘image’ of tech so that is is more appealing to women and infiltrating the education system, reaching women whilst they are still young girls and showing that tech can be a cool, sexy, creative and rewarding career. I think this is probably the best longterm strategy we can put in place and I’d love to help get involved in making this happen (ping me if you’ve got something going on already or need help getting something off the ground).
I also think there are a lot of women who ARE women in tech, but who define themselves as marketing people, or managers, or PR people or designers, or researchers who just happen to only ever work in the tech sector. I’m not sure if there is something we need to *do* about this, although I’m starting a personal (informal) research project to better understand why these women exclude themselves from the ‘women in tech’ label. Perhaps it’s the information architect in me, but I have a feeling that a lot of this is taxonomy / labeling related.
All of these are long term and somewhat philosophical. What can we do NOW?
I have TWO suggestions for what you can do RIGHT NOW that I think will start to make an immediate difference.
1. That woman you know who works in tech, who is really smart and talented and should be doing more. Give her a nudge and say ‘you could do that’, ‘you should do that’. Be directly encouraging.
I know we shouldn’t have to do this, but in my experience we do. Many of the smartest women I know do need a little encouragement to be a little bolder in the way that they present their work, whether that’s just writing a blog, getting up and speaking at a conference, or starting their own business. Having someone pick you out and say – yes, sure, you can do it, you should do it, just a tiny bit of encouragement and confidence building can be the spark that sets people on their path.
You may think it is obvious that your woman-friend/colleague has everything it takes to be ridiculously successful, but all too often the response you’ll get would be ‘do you think so? you really think I could do that?’
I don’t know why and for the moment I don’t really care why. Let’s just start giving individual people who we *know* have what it takes a nudge, a little confidence boost and see what happens.
2. Write & speak about women in tech, and do it respectfully and supportively
Aside from cold hard cash there are two other incredibly important currencies when it comes to professional success – respect and visibility. The way you choose to write and speak about women can make a big difference with regards to their access to both respect and visibility.
Let’s take a case study. Here’s an article that impromptu panel participant and journalist Milo Yiannopoulos wrote for the Telegraph covering the panel discussion and his thoughts on it. Let’s ignore his pretty woeful argument that there is no place for this discussion at these conferences and the way that he referred to women as ‘girls’ throughout the piece. Notice the difference in the way he treated contributions to the discussion from Sophie Cox and myself compared to those of Joshua March and Paul Walsh. Sophie and I get first name treatment only and no links (despite both being very easily Googled), Joshua and Paul get full names and at least one link (Paul gets two!).
On the surface, this may appear accidental, lazy, coincidental, but that fact is that even if Milo disagreed with the points that Sophie and I were making in the way he has presented us in this article we are utterly unimportant, except that we provide the foil for his argument. Joshua and Paul on the other hand are obviously important voices because of the way they are treated.
If you *really* want women in tech to be confident and successful in tech, then treat then a really great way to start is to give them respect and visibility and if as a part of your trade you happen to be writing then:
write about them
use their full names (and try to spell them correctly, ahem Guardian)
link to them
Sometimes it’s the little things that really make a big difference.
I’ve been known to say in public places that designing with a community is nothing like design by committee. And, certainly that’s been my experience to date. Not to say that designing with a community is painless either! These days I feel as though I have a vast swathe of constantly raw virtual flesh put out for cutting. Checking email is a lot more scary now than ever before!
Recently we’ve been getting some feedback from within the Drupal community that our approach is not open enough. The designer in me finds this devastating – by ‘designer’ standard I think we’re already being profoundly open in terms of both the way that we’re working (our practice) and also what we’re designing (our output). But, by open source standards, I completely understand the feedback. Angie Byron (@webchick) recently left a comment on an earlier post that describes some of the issues that are emerging. I’ll quote a little from that now so you can get the picture:
On something like groups.drupal.org, everyone can be a content creator and make new posts which are equivalent to everyone else’s posts in “primaryness.” While we have tools like “sticky posts” to draw attention to particularly important things, everything else is open to everyone and has a real collaborative (if chaotic) vibe. This is more like “the Drupal community show, with special guests Mark and Leisa.”….
…. But yet, the current model feels to certain members of the community like “shout it out into the darkness and hope someone’s listening” collaboration paradigm, when they’re used to much more direct interaction like pinging webchick on IRC and saying “Hey! I’m upset about something. Let’s talk.”
I can’t help but preface my response by saying that I’m usually available for hours at a time on IRC to Drupalers and more than happy to be pinged with this exact message, although having said that, I’m no @webchick in the Drupal community so completely understand why this hasn’t happened as much as it might.
I do want to share back some of my thoughts on ‘equivalence’ and ‘the Mark & Leisa show’, as the way that this is playing out is not entirely accidental and there is a certain amount of ‘design’ to the way that we are communicating within and outside of the Drupal community (having said that, it is a constantly evolving design and you are probably being party to a big evolution right now!)
Top Down/Bottom Up
Another thing I’ve been known to say in public places is that design projects like D7UX and the Drupal.org redesign project aren’t the kind of projects that can be initiated from within a community, that is organically and ‘bottom up’. I think it’s true. Look at the efforts of the hardworking usability team within the Drupal community – there are some very smart people there and they are working terrifically hard and making a big effort to improve the users experience of Drupal – one issue at a time (using the issue queue infrastructure typical to opensource development). They have certainly taken big steps to improve Drupal’s usability, but (and of course, this is open to dispute) I believe there is a fairly profound change that needs to come about in order for Drupal to achieve what I understand it would like to achieve – that is to make it’s powerful tools more available to people with less or different or, ideally, even no web development skills.
I wouldn’t like to say it was *impossible* for this to come about from within a large community, but I think it is self-evident that it is highly unlikely. It requires a different type of methodology to what is found in open source communities at the moment for this kind of change to be designed, at least, within any kind of useful timeframe.
We need to find a way for a good design methodology to work in an open source environment. That’s one great big hairy challenge.
The Open Design Triangle
Back in my ‘agency’ days, we used to use a diagram of a triangle to try to explain to our clients some of the facts of life around features and cost and time and quality, it is quite like the one I’ve included above except the three corners said ‘Time/Quality/Cost’ and the idea was that the client could choose to move two of the corners but that one had to remain fixed. The triangle couldn’t get any bigger but it could change shape.
I’ve been thinking about this model recently in terms of the way we’re working on the Drupal project, and for open source designing in general, and I think a similar principle applies, except that the corners are now labeled
In *this* project time also equates to cost (as we are being paid to work on the D7UX project) but obviously this is not always the case. And as with the commercial model, you can move any two of these corners but not all three.
Time is a massive issue for us in this project. I would estimate that at the moment we are spending at least 65% of our ‘paid’ time just ‘communicating’ on this project and just 35% actually designing. That’s scary for us – there is a lot to design and not a whole lot of time to do it. We would LOVE to be spending more time designing, but as I’ve said before, it’s fruitless and foolish to do so in isolation.
On top of this ‘paid’ time, both Mark and myself spend a lot of our own time on this project and in that time we are almost invariably blogging or in IRC or responding to email communicate we’re receiving on the project. I’d estimate for myself that I’m probably contributing an extra 20-25% of time beyond what I’m being paid to do on this project. That doesn’t make me any great hero, I know, but that’s the current landscape.
I’ve written in the past that I believe that design is no place for democracy. Open design is amazing because you can have so much feedback and insight piped in throughout the process, and as I hope is evident, we are doing everything we can to encourage this engagement in our process from the outset (where it is arguably most important).
However, design decisions at a system level (like the ones we’re working on at the moment) shouldn’t be made issue by issue and by consensus – not if you want a great design, a great user experience. A good design comes from a strong, unified vision that is articulated by experienced designers. The power of this clear design vision is that, going forward when design decisions do move down into issue queues (which, over time, they will), we are all able to discuss design issues and make design decisions more articulately and more effectively because of the foundations that have been laid, through the ground work that we are doing right now.
‘The Mark & Leisa Show with Special Guests’
As I understand it, there are three main reasons why this impression is being created. Let’s look at them one at a time.
We’re constantly shouting about our work
Especially in the early stages of this project we are spending a lot of time effectively saying ‘look at us, look what we’re doing’. Don’t worry, it feels pretty uncomfortable for us to be doing this, but if we want this project to succeed then we have to do it. The greatest risk to this project is that we don’t engage the Drupal community (engaging ‘outsiders’ is also very important but nowhere near the same level of risk), and that we don’t engage them early enough in the process when the big decisions are being made. There is no way that we can just send out one message and know that we’ve reached everyone. We have to shout, as loudly as we can and often. I don’t think we have a choice if we want this project to succeed.
We’re using video
We chose to use video for a few reasons, partly because ‘show and tell’ is often easier for people to consume than text, and also partly because we want to come across as human beings with feelings (in the hope that people will consider this as they’re drafting their responses).
We don’t often get ‘conversational’ around the feedback we receive
We are receiving feedback and insight from lots of different people in lots of different places – we’re doing this so that we can maximise the level of engagement and involvement that we get with the project. Very often we stay a little removed from the feedback that is coming in, for a couple of reasons.
Firstly, we don’t want to get involved too early – we learned from our work on the Drupal.org project that if we stick our noses in too early we can skew the direction of the discussion, and we don’t want to do that. We love it when conversations evolve amongst the community and we watch very closely how those play out. We need to give a thread time to evolve to see what trends emerge.
Secondly, time. See above.
Consensus Driven Design?
The way that we are currently engaging with the community is very different to the way the community currently gathers to discuss and resolve issues – which is very much consensus driven.
I cannot say often or loudly enough how much we crave communication with the Drupal community on this project, but in order for us to do our job well, we need to engage in a somewhat different way.
We can’t argue every single point at the moment that it is raised. Our process doesn’t work that way (we don’t know anywhere near all the answers at the moment, we’re still devising the strategy to make the questions that we’ll then set about answering, with the assistance of the community). Also, see ‘time’ above.
Having said that, I think that we are striving to work in a consensus driven way. We’re doing this by creating larger artifacts that we can gain consensus around. Things like our Experience Strategy, our Audience Matrix, our Design Principles for example, are ways that the community can gather around the work we are doing and we can get some kind of concensus about the best way to define our strategy.
In the recent release of our Initial Concepts, we specifically pulled out four artefacts for discussion, with the aim of gaining concensus around them before moving forward (being the header, the overlay approach, the inline editing and the ‘direct manipulation’ tool).
It may not look exactly like the way that concensus driven development works, but the principle still holds… at least, that’s the outcome we’re trying to achieve, within the contraints of time and quality (see above).
Where to now?
There is no right or wrong way to do this, yet. The work we’re doing on this project will, hopefully, be used as reference for future projects and I’m sure they’ll look at some of the things we’ve done and say – great! and others they’ll look at and say – rubbish! We’ll probably do this ourselves before the end is reached!
I’d love to find a way to more effectively synthesis all the feedback we’re receiving and to share that in a way that everyone can consume more readily. Again, I’m not sure exactly how to go about that yet, but I am fairly sure it’s not to just talk in one place.
We are listening. I think we need better ways to show that we’re listening. I’m not sure what those are yet. I’m going to think on that some more and I hope you do too and let me know what you come up with.
A final note on Fear
I wanted to wrap by sharing another part of WebChick’s comment, which resonated deeply with me.
some feel like they don’t have expertise in this domain and are really intimidated to jump into the fray. They’re scared to say anything bad because they’re convinced that their opinions will get immediately shut down, and that they’ll offend you guys.
So much of this project and this way of working is about fear. I know I feel terrified by this project almost every day I work on it, for so many reasons. And fear doesn’t often create a great environment for communication. I need to think about this some more (and no doubt have a whole other blog post brewing), but I thought it was worth throwing that out for your consideration.
Thanks for taking the time to read all of this. Be brave. I look forward to hearing your thoughts.
If you’ve been following along with the Drupal 7 User Experience Project (now codenamed D7UX) at d7ux.org you’ll know that it’s starting to get pretty interesting in the project. We’ve been so busy doing the work I’ve been a little remiss in cross posting over here, so, here is a quick consolidated update for you now!
Last Thursday afternoon we posted our initial concepts for the interface model for Drupal 7. You can see an overview in the video above and we describe it a little over here. If you haven’t already given us your feedback I’d be really interested to hear what you think of the direction we’re proposing to take (even if you’re not a Drupal user!)
Crowdsource Usability Testing is Go!
You might also be interested to know that our first round of Crowd Sourced Usability Testing kicked off last week (I know, I should have let you know here too!) – we’re really pleased that we have around a dozen submissions already from all around the world and in multiple languages (which is a challenge we’re still dealing with!). You can see some of the submissions on our YouTube Group. Another round of CrowdTesting is coming up very soon, so stay tuned for that if you’re interested in participating.
A question for you…
As we continue to work on this project we’re continually having to question and refine and experiment with the ways that we work. Up until recently, I’ve used this blog as place to communicate about the project and to ask you – whoever you are! – to participate in the project if you’re interested. One of the reasons I’ve done this is to try to get people who aren’t very experienced, or experienced at all, with Drupal to participate, which we think is incredibly important.
Something different has happened lately, which is that we’ve launched the D7UX website, which is now the primarily place that we’re sharing updates on the project. Since doing that, I’ve gotten some feedback to indicate that people are finding cross posting here and there a little unnecessary…. so I just thought I’d ask what you think?
If you’re interested in following the project, would you rather follow it here or at D7UX?
Are you happy/comfortable to post your feedback over at D7UX or would you rather leave it here?
Do you find it annoying/unnecessary to post in both places?
Do let me know and we’ll tweak our process accordingly!
Thanks in advance for your insight and support on this incredibly exciting yet ever evolving project!
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