Personas are for hippies… and transformation and focus

Thanks to London IA, I had the opportunity to share some thoughts on Strategic UX that have been starting to take shape into a book recently.

I happened across this twitter exchange this morning. This is a not surprising response to personas, I’ve shared this response at times and have empathy for both points of view.

Twitter conversation between Tom Coates and Martin Bellam

Here’s the thing… You don’t really want to use personas, do you? They are really a pretty cumbersome way of maintaining your customer’s active presence in the design & product management process.

What you really want is a small, tight team who get who your users are, what they value about your product/service and what is behaviourally significant about them. And you want regular access to them (if you or your boss are representative of your target audience this helps enormously).

Enter reality – the majority of us are not working in this kind of environment. We are working for large organisations who are focussing more on themselves than their users, with people who may not have seen or heard from a customer for years (if ever), whose attention is constantly being focussed on internal KPIs focussed on quantity not quality. Who resist making and decisions in preference to making a sub- optimal decision that can be traced back to them.

Sure, the likelihood of incredible design flourishing in this environment is significantly reduced, but what do we do? Give up?

We can’t all do that, can we? And neither we should.

Many of us have experienced that moment when a team transforms – when they realise what it is like to be their customer and how easy it would be to make that experience better. This most often happens during usability testing. (around the 3rd or 4th participant when the team acknowledges that perhaps we haven’t recruited a bunch of stupid users and maybe we do need to change the design a little).

Well made and well used personas are less able to create this transformation (watching real users will always trump personas) but they can help maintain that transformation and act as a tool to evangelise a customer focus through out the organisation and to create a common language around our users and – possibly my favourite thing – to allow us to reduce usage of the term ‘user’ (so abstract, inhuman and elastic) and replace it with our personas names.

Yes, this does make you feel like a bit of a hippy. I agree. But it helps, a lot, to transform focus from internal processes and priorities to what people actually do, need, want.

You don’t *have* to use personas to do good design. If you make bad personas (made up not researched, focused on demographics not relevant behaviours and attitudes), and if you use then poorly (make them and forget about them, or keep them hidden within the UX team) then you might as well not use them.

But well made personas in day to day use through out the organisation are incredibly useful when you need to gain and maintain focus on the (potential) customer.

Here’s the test:

  • do you have personas for your project/product?
  • are they made of data from real (potential) customers?
  • do they have real names not segment names?
  • do you have fewer than five personas?
  • can you remember all the names of your personas and describe them?
  • do you use them to guide, evaluate and/or explain design decisions?
  • can your boss name your personas?
  • can the developers on your team name your personas?

If you’re not answering yes to the majority of these, there are probably good reasons why personas aren’t really working out for you.

Don’t fret if you didn’t do so well here – most people don’t (out of a room of dozens of UXers last night only one lonely hand remained in the air at the end of this line of questioning last night).

I reckon personas are the best known but most misunderstood and misused tool in the UX toolkit. Don’t throw your personas out necessarily but see how you can incrementally improve how they’re made and communicated.

And if your fortunate enough to work in a project team who doesn’t need personas, well, lucky you – just don’t be too successful or you may find yourself large enough that you’ll windup needing personas after all! ;)

(For help on making good personas, two excellent resources are Designing for the Digital Age or About Face 3)

Ignoring the Android Honeycomb Action Bar Convention

I’m working on the UX for an application for the new Android Honeycomb User Interface (UI). This is the first time I’ve designed for this operating system and we were fortunate enough to have Nick Butcher of Google UK take us for a walk through the new environment and introduce us to some of the UI conventions.

If you’ve not yet had the pleasure, you can take a look for yourself here:

There’s a lot to like about the Honeycomb OS in my opinion, especially once you get to know it a little and learn what the many icons that litter the interface actually refer to, however there is one UI convention that really bothers me, and that in this application we are going to largely ignore and that is the action bar.

This is the action bar (screenshot borrowed from TechCrunch who discuss the UI in some detail here)

Honeycomb Action Bar

So, the action bar is application specific and context specific within an application. The idea is that you put any actions you may need in that part of the application into the action bar where you can then ‘take action’, the more contextually relevant the action, the further to the left, the less relevant and more global, the further to the right.

Now, it is A Good Thing that there is a convention for this, especially in an open source environment where designers/developers play fast and loose with the interface and the overall experience of using the device running this platform suffers as a result (as, having played with a Xoom for several days now, I can report is definitely the case).

The implementation, however, I’m less thrilled with, particularly as I’m confident it will actually encourage designers to ignore or duplicate the action bar’s functionality within the interface… and here’s why.

Tablet Activity Zones - Landscape Here’s a ‘heatmap’ of the activity zones for a tablet in landscape mode from a very useful post by Dan Saffer of Kicker Studios.

Note that the red band labeled ‘reach’ (indicating that you have to reach to access this zone and it is not an easy or comfortable activity) corresponds almost exactly with the Action Bar.

Although the TechCrunch article suggests that you instinctively look to the action bar (which, given that it is visually quite pushed back, seems to me to be an easily learned behaviour rather than a natural one), it qualifies this immediately by saying that you do this only if you can’t locate the action in the applications main UI.

This means that, if you follow Honeycomb’s UI conventions (in the hope of making the ecosystem of applications a good user experience with some potential hope of ever rivalling Apple’s iPad), you have three options: make the actions people need to perform ergonomically awkward (the xoom, for example, is no lightweight and unless you’re resting it on a table or your lap, requires some juggling in order to hit an item on the action bar, this juggling also makes the selection significantly less accurate), duplicate the actions in the bar and in the application UI, or ignore the convention and put the actions that are most contextually relevant in a place that falls with in the ‘easy’ activity zones.

I doubt that the designers of Honeycomb intended the action bar to replace in context calls to action, and neither it should, but it seems to me that it means that the actual use of the action bar is now very ambiguous. The more I design for this environment, the more I’m finding that the action bar actually feels much more suitable to application-wide actions rather than contextual – not the least because it is often visually quite removed from the content it is acting on.

This is a significant iteration on the previous Android software and, as our friends at TechCrunch say: ‘…at least people will actually be able to find these options, which is more than can be said about the options hidden behind the ‘Menu’ button on current versions of Android (which many people never hit).’

At the same time it feels like a rather awkward solution to this problem and certainly one that wasn’t really thinking about the mechanics of using a tablet in the wild.

As someone with an existing interest in design and UX for open source, I’d be really interested to hear what other designers who are encountering this convention are making of it. I’d also like to hear about whether the option of placing the action bar nearer to the ‘easy’ activity zones was considered and how that played out.

I’d really like to see Honeycomb evolve, and for good and clear UX conventions to emerge in this space so that we have a really solid alternative to the closed and ever more controlled world of Apple

(disclaimer: I own Apple gear. I know it’s great).

Five User Experience Initiatives for Drupal 8 (A Drupalcon Debrief)

I had the pleasure of spending last week in Chicago at Drupalcon. I was there to run a workshop and do a talk but, to be honest, I was also mostly there to decide whether it was time to break up with Drupal for good.

My relationship with Drupal is now heading towards the 3 year mark. The number of hours that I’ve contributed (unpaid, in addition to those I’ve been fortunate to be paid to contribute) are really starting to rack up. I was starting to question whether those hours were well invested and whether it was wise to invest any more. Whether in fact it was possible that my contributions might actually constructively lead toward significant improvement or whether, after all, trying to do good UX in open source is really just thrashing.

Well. We didn’t break up. It’s not all roses, but there’s hope.

The first sign of hope came in Dries‘ keynote where he identified not just usability but delightful experience as a goal for Drupal8. Frankly, I’ll be beyond surprised if Drupal8 gets anywhere close to ‘delightful’ by the release of version 8 but as long as we’re tracking in that direction, I’m pleased.

The second sign also came from Dries’ keynote where he started talking of initiatives and distributing leadership throughout the community. I think this a great idea and gives not only UX but other disciplines the opportunity to really stand up and take a key role in the community. I noticed, however, that Dries didn’t mention any specific UX initiatives, so I thought I’d share five that I think Drupal should embrace in the coming months and years.

1. increase the overall UX/Design competency within the Drupal community – help developers (who always make loads of design decisions, in Drupal-land and beyond) make good design decisions.

What does this involve?

- Making and publicising a good pattern library so that developers contributing user facing code can help us maintain consistency and enhance usability.

- Continuing to make the case for good usability through sharing ongoing usability testing and showing how, where and why users struggle to complete tasks

- Increasing the size of the usability team in the Drupal community – here we need to focus on lowering our pretty atrocious attrition rate – keeping the good people we attract rather than just attracting more people only to see them give up and leave, exasperated, in short order.

- Creating an environment that supports and encourages good design practice. More on this below.

2. Incrementally improve known usability problems from Drupal 7 in Drupal 8. Refocus on the Site Builder persona.

There are lots of known usability problems remaining in Drupal7 that it would be great to see nailed in Drupal8. In particular, a lot of the site building tools were not given as much attention as they deserve because of Drupal7′s focus on Content Creator.

At the Usability BoF in Chicago the team discussed refocussing Drupal8′s UX goals on the tasks of the Site Builder and therefore on improving the interfaces that are encountered during the core site building tasks. Regular usability testing on these tasks will also be undertaken during this cycle.

3. Improve Drupal’s ‘Out of the Box’ experience

The learning curve of death cannot continue. We can’t expect newcomers to sign over their first born child before we let them set up a simple website. We need to give them something quickly. Enter the Snowman (nee Tsunami) (see also @eaton’s initial proposal for this project).

4. Improve the experience for Content Creators

Refocussing the UX efforts for Drupal8 on the site builder leaves our Content Creators in an awkward, somewhat unloved position. The challenge remains to find a way to enable the people who run our Drupal websites day to day (and the people who can be incredibly influential in deciding whether or not Drupal is the chosen infrastructure or not) to have a good user experience.

There are several efforts in progress addressing this challenge including Project Verity (the not-drowning-tho’-equally-not-quite-waving project that I’ve been working on with the team at Mark Boulton Design), Workbench (recently released by the guys at Palantir) and no doubt many others that I’m not aware of (yet!)

It seems at this point that the fate of the content creator is in the hands of contrib not core. If you’re looking for an opportunity to really contribute to the future growth of Drupal consider this a worthy cause.

5. Make Drupal.org a better environment for creating good user experience

Nobody I’ve ever met who works on the Drupal project actively wants to create a crappy UX, but our tools don’t necessarily make it particularly easy for us to do so. Drupal.org needs better collaboration tools that encourage us to follow good process (eg. to explore the problem space and possible ideas before we start coding the first one we think of), to get the right people in the room for discussions at the right time (smart but not annoying notifications), to help drive productive, efficient, consensus focussed discussions, and to help ensure we’re all pulling together, not frittering our energy away on related projects that don’t know about each other.

This is the goal of the initiative that Randy Fay & I kicked off in our Core Conversation at Drupalcon, it’s called the Prairie Initiative (also see Randy’s and my slides on this topic aka ‘Redesigning The Issue Queue’ ).

This is where I want to spend the bulk of my ‘Drupally’ time over the coming months (albeit only a few hours a week – I’ve got work, kids, side projects, a mortgage to pay – don’t we all).  I’ve got some unfinished business on the Drupal.org redesign project anyways, the issue queue is my itch to scratch (I’ve moaned about it enough) and getting this right (or at least, a little righter) seems like a fascinating and challenging project to me. Also, I get to work with some of the Drupal community’s finest. Expect to hear more on this in the coming months.

There they are – the five UX initiatives I’d like to see for Drupal 8. I’m not sure how things become official initiatives in our new Drupal 8 landscape but I imagine that if a whole bunch of us keep saying it over and over, form into working groups and start getting exciting stuff done, that’s got to be a good start. If a delightful experience is really what we want to achieve then, IMHO, this is how we get started.

Onwards.

A model for design leadership in the Drupal community

DesignModel

The discussions around the design and user experience objectives for Drupal 8 begin to kick off and will no doubt crank up a gear at the upcoming Drupalcon.  (are you coming? come to my workshop! no ux/design experience necessary)

As much as I want to see us continue the great trajectory for improving the user experience for Drupal that I think the community achieved with Drupal 7, I have some reservations about our capacity to maintain this momentum without addressing some of the structural issues within the community – effectively the environment in which design can happen.

There are bunch of topics that we can explore around this – I’ve pitched a Core Conversation for Drupalcon about redesigning the issue queue, for example. I hope I get to talk a whole lot more that during the coming months. Today I want to talk about a structure of leadership for design in the community and to propose a model.

One of the main reasons that we were able to achieve so much with Drupal 7 was because the D7UX team (which I was privileged to be a part of) were given a mandate, a bit of authority, and a clear brief. If we want to continue to take big steps with Drupal’s user experience (and we still need to take several big steps on this front if we want to be competitive and remain a viable option for a wide audience), we need to find a way to replicate this focus in the longer term.

Currently we have two UX Maintainers – Roy and Bojhan – who are both incredibly dedicated and do great work within the community to promote a better user experience. I have nothing but the greatest admiration for their resilience. There are also, increasingly and largely thanks to Acquia,  more UX and usability resources available within the community.

We have the dual challenge of encouraging existing community members to become more ‘UX-y’ and attracting UX Outsiders into the community in order to grow this team. We also have the dual challenge of making many, many incremental changes that could rapidly improve Drupal’s usability (we call these the ‘low hanging fruit’), as well as considering the bigger, more hairy challenges around defining and understanding target audiences, and finding ways to create good experiences for an incredibly wide set of journeys and requirements.

Eaton recently took a good stab at describing some of the big UX challenges ahead for Drupal 8 and offering a good proposed approach – I recommend reading through this, including the comments, if you haven’t already.

In order to make it possible for such changes to happen, I propose that the Drupal UX Community requires three types of leadership: A UX Maintainer (or two), a Design Pattern Library Maintainer and a Designer in Residence. Let me describe these in reverse order.

The Designer in Residence: This person is tasked with addressing some of the Big Design Problems – the more strategic/structural problems that will impact Drupal’s long term ability to be a compelling choice for organisations in the coming years, that will look at the challenges of multiple platforms from a UX perspective, that will look at target audiences and optimising out of the box experiences/on boarding. This role will benefit from having an ‘outsider’ perspective. This person works with the UX Maintainer(s) to take great strategy and turn them into achievable tasks. This person shares their work with the Drupal community and the UX Community at large, along the lines of what we did with D7UX. They are Drupal’s UX ambassadors to the outside world, they help draw fresh UX talent into the community. They conduct generative research. This is a role that could be rotated every six months or so, getting fresh eyes on the big problems would be fantastic. We could invite people we’d love to work with to take this role from time to time.

Design Pattern Library Maintainer (or librarian, if you prefer): this person leads and coordinates a project to develop an excellent library of design/UX patterns that can be applied consistently throughout core and into contrib. They work with the UX Maintainer(s) to ensure that new patterns are applied/communicated and they take requests from the UX Maintainers to develop patterns that are missing or confused. They might conduct A/B testing to establish optimal patterns. They take work from the Designer in Residence and turn them into patterns as a part of the process of making big design ideas achievable.

UX Maintainer(s): work with the overall community to get the day to day UX work done. Help push things through the queue, coordinate and communicate usability testing, incrementally improve the UX of Drupal by knocking over the ‘low hanging fruit’ improvements, help educate and train up members of the community to be more UX-interested and UX-aware. Works with the Pattern Librarian to see that patterns are implemented well across core and contrib, works with the Designer in Residence to make Big Ideas achievable.

I believe that each of these roles should have clearly identified goals for a defined term (say, six months?) so that they can see and show what success looks like and be able to get useful feedback on the work they’re doing.

I also believe that these roles should be funded positions. I believe that one of the best ways an organisation can support good User Experience in Drupal is to put their hand up to offer sponsorship for a part time role for six months.

If we do this – get the structure in place for good design to happen, and create funded positions to make working on Drupal a viable alternative for good UX people who have so many other competing demands on their time at the moment – I am very excited about the prospects of Drupal’s User Experience in the years ahead.

Something significant needs to happen in the way we do Design and UX in Drupal – along the lines of D7UX but more embedded and integrated and more sustainable. We won’t achieve what we need to by making lists and prioritising them. We’ve still got a lot of big problems to solve and a lot of hard graft to do.

What do you think – might this help make it happen?