Designing User Interfaces
One of the biggest criticisms leveled at open source projects is that the user experience of open source products sucks. This post is about an attempt to introduce design standards into an open source project, particularly one without designers. If you already know how personas are used in a development product, you might want to skip this post. Otherwise, read on!
Anyone who's been within shouting distance of myself or Paul Downey over the past six months will know that we embrace the mantra laid out in "The Inmates Are Running the Asylum" by Alan Cooper (free preview available on Google Books). For those who haven't read this book, the main contentions are:
I still think there's plenty for us (the open source community) to learn from Cooper's book. Even for those who think open source is all about scratching your own itch. If you want other people to use your product (open source or otherwise), it will greatly improve the chances of adoption if you try and understand the end user's goals, and design the user interface to help them meet those goals.
Cooper provides guidance on how to achieve this. We use personas. We make up pretend people, and design for them. We attribute them with believable characteristics, give them goals and motives, and then base the user experience around those goals.
It sounds simple, but creating good personas is an art, and this is my first attempt. But I have tried to learn from Cooper, as well as my former (rather talented) colleagues at LBi. Below you can see the two personas I've developed for the next phase of RippleRap development. I'm publishing these for the following reasons:
Dan - "Fastidious Notetaker"
Sally - "Social Butterfly"
The next stage is paper prototyping. We're developing RippleRap for BlogTalk on 3/4 March 2008. Watch this space.
Anyone who's been within shouting distance of myself or Paul Downey over the past six months will know that we embrace the mantra laid out in "The Inmates Are Running the Asylum" by Alan Cooper (free preview available on Google Books). For those who haven't read this book, the main contentions are:
- Products should be designed based on end users and their goals, rather than on the underlying system or code
- Features shouldn't be included just because they're easy to add. Unnecessary features result in a bloated interface and a poor user experience. Features should help end users reach their defined goals. If they don't, maybe they should be removed.
- Developers aren't well positioned to design great user interfaces because they have too intimate a relationship with the underlying code.
I still think there's plenty for us (the open source community) to learn from Cooper's book. Even for those who think open source is all about scratching your own itch. If you want other people to use your product (open source or otherwise), it will greatly improve the chances of adoption if you try and understand the end user's goals, and design the user interface to help them meet those goals.
Cooper provides guidance on how to achieve this. We use personas. We make up pretend people, and design for them. We attribute them with believable characteristics, give them goals and motives, and then base the user experience around those goals.
It sounds simple, but creating good personas is an art, and this is my first attempt. But I have tried to learn from Cooper, as well as my former (rather talented) colleagues at LBi. Below you can see the two personas I've developed for the next phase of RippleRap development. I'm publishing these for the following reasons:
- Developers who are new to the concept of personas might find this process interesting, and might want to develop their own personas (in which case, read Inmates first! You can copy my format, but would be much better off developing specific personas for your product. Here's a decent introduction)
- People interested in RippleRap might be curious why our development priorities are changing
- People with more experience than I might weigh in with suggestions (fingers crossed)
- We want to be open about our process to see what we can learn from this transparency
Dan - "Fastidious Notetaker"
Sally - "Social Butterfly"
The next stage is paper prototyping. We're developing RippleRap for BlogTalk on 3/4 March 2008. Watch this space.
Comments
Real = representational of existing user base. As a way to understand their need.
Hypothetical = Representational of anticipated user base.
In case it is hypothetical, how do you avoid the risk of 'Doctors running Asylum' - which is not exactly a fix for 'Inmates running the Asylum'.
Kerry: That's an interesting article. I can empathise with this point of view. There are developers out there who are capable of doing great user centred design without the need for personas or other design tools. But in over a decade of managing development projects, I can tell you they are rare beasts indeed. Perhaps they have several such people over at 37Signals?
Regardless, I think they're a great tool, have used them many times before, and think that Osmosoft will benefit from them. Time will tell, eh?!
Labsji: In an ideal scenario, personas would be based on ethnographic research. There's more about this on the Wikipedia page on personas.
Established best practice is that personas are hypothetical, even when based on ethnographic research, because they are representative of a target group, while an individual in that group will never be properly representative (i.e. general, useful properties can more easily be assigned to a fictional character).
Given the time available it made sense to quickly create the personas I've shown, and then invite feedback. The biggest risk here is that (as the person who wrote the personas) I've designed the 'users' according to my convenience. Which is why I'm very much open to *specific* criticism about the characteristics I've assigned e.g. a student wouldn't want a Mac.
Keep the feedback coming!
As for the concept of personas in general, I have to admit I don't quite get the benefit. There's little I can draw from these documents that couldn't have been expressed in a much more concise, focused way.
In fact, the whole idea sounds like something a marketing department might be interested in, but less so a developer or UI designer... !?
Don't get me wrong, I do think that usage scenarios are important in understanding and designing a product - but this somehow seems too limited to me.
I've used personas with some particularly tricky clients to cement the focus on user goals rather than the business' assumptions about what their customers want from a digital experience. And if they're built on primary research (which I'm sure yours are, Phil?) then it's hard to argue with 'em.
Of course, they do take time to develop, and in certain situations, I could see how pen portraits of customers might be a more cost effective and just as adequate exercise...
FND, as Stephen mentions, the focus is on the goals, and the UI should be designed around them. But all the other stuff - the detail that gives our persona character - is still useful, because this context makes the persona believable. And when the persona is believable, UI designers become passionate about meeting their needs (much more so than with a set of standalone goals). In my experience, empathy with a persona is repeatedly a surprisingly strong tool in the design process.
Stephen, I wish we had the time and money to base our personas on primary research! This is definitely their biggest shortcoming (see my comments above). But given that we only have a month to incorporate work into RippleRap v2, I decided that creating my own personas and inviting constructive criticism was better than having no personas at all. Also, bear in mind that we're trying to use and create tools that the average open source developer can use - and I'm really keen to gather intelligent suggestions as to what can be done quickly and for free that can improve the design process under these conditions.