Making a more engaging UK UPA

UPA Affinity Sort

Having been a vocal critic of the UK UPA in the past (by which I mean the organisation and it’s activities over the past five years not the current or recently past committee), I was really pleased to be invited to facilitate a workshop or two at their March event ‘Crowdsourcing the future of the UK UPA’.

There were a wide range of workshops held that evening, the one I was facilitating was focused on gathering and prioritising concepts that the UK UPA could act on which would make it feel like a professional organisation that we felt more aligned with and wanted more to be a part of. There were two workshops and the participants included UPA stalwarts and newbies, UXers and ergonomists, people from London and beyond.

The workshop used an incredibly rapid fire KJ Technique formed of individually listing items relating to how engaging the UK UPA was/was not for us and why that was so, followed by a quick post up and affinity sort, dot vote for issues we felt most strongly about.

Both workshops were characterised by a mixture of frustration and an energetic desire to be more involved and for the UK UPA to continue to grow and be an influential voice and resource for people who are currently active or interested in usability.

Aggregated Priorities
Once we aggregated the issues that most resonated across the two groups, the following priorities emerged:

1. Let us contribute: It was noted that the activity that the UK UPA is able to achieve is limited by the time that the committed yet otherwise busy committee members are able to contribute. There was an almost universal desire for members to be able to contribute meaningfully – whether by contributing content, updating the website, setting up Special Interest Groups that could hold their own events, and many other ways.

This requires the UPA giving up a little control – the current model of ‘tell us you want to help and we’ll delegate something to you’ sucks the enthusiasm and motivation out of even the most committed UPA fan. The net benefit would be a much more active association achieving a lot more for and with it’s membership, and a greater sense of involvement and community amongst the membership.

2. Teaching people who are new to usability: there was a general perception that the UPA could play a big role in educating people about what usability is, what usability work entails and why this might be a rewarding career option for young people and career changers. There was a particular passion for outreach into schools but also for providing tools to help educate colleagues with other specialties.

3. Have an opinion: participants also expressed the desire the the UPA have an authoritative voice on matters relating to usability, particularly high profile and particularly contentious issues. People wanted to be able to turn to the UPA to see what they thought about things.

4. Different event formats: participants also expressed the desire to mix up the event formats a little so there was less ‘lecturing’ and  more participation – debates, design jams, social events were suggested as options. Special Interest Groups were also mentioned in both workshops.

5. Learning more by sharing our experience: The ability to talk to each other, as members of the UPA and attendees at the events was something that participants would value – both online and offline. People wanted to be able to ‘find each other’ online after an event and continue conversations. An emphasis of events and content that showed real practice was also valued.

6. More friendly: Some participants noted that attending the events could be quite scary and intimidating and that more could be done to help alleviate this, also to help facilitate networking between participants. Some participants noted that they had attended several UPA events but not actually made any more connections with usability professionals as a result. (Related to points 4 and 5 above)

7. Who is the UPA? Participants wanted the UPA to more clearly articulate the position it wanted to occupy with our profession and the role it wanted to play and consequently, what our expectations should be. Development of a clear ‘value proposition’ or mission statement for the association.

8. More than just UX As a part of her introduction to the evening Chandra Harrison, current president of the UKUPA went to some lengths to make it clear to us that the UPA is about more than just usability. She may actually have gone so far as to provide the value proposition that people were looking for (ref: point 7 above) when she talked about the UPA being the organisation that brings together people from across all kinds of industries and professions who have an interest in making all kinds of things easier and better to use.

As it happens, participants (particularly in one group) found this a very appealing proposition and wished that they actually saw more content from across these various professions/practices as a part of the events program, more participation from people outside of UX at the events and more content helping us to understand the similarities and differences that are experienced across these audiences.

What’s next?

Another thing that Chandra made very clear in her introduction was that the committee are very time poor and already working very hard on projects for the UPA and that – although they were pleased to be holding this event and inviting ideas – they were not able to commit in any way to moving forward on any of the points that came out of the event. I understand from talking to members of the committee that many of the issues raised above are in the process of being tackled right now and, as it happens, by addressing the first one on this list, this problem actually starts to go away a little (although, no doubt, it also introduces a few more challenges).

Attending another UPA meeting confirmed for me though that actually achieving these objectives is going to require more than just a series of committee led initiatives, it’s going to require significant cultural change.

I’m optimistic that the very fact that events like this can take place under the auspices of the UPA is reason for us to have hope.

Why bother? Why do I care?

You may not identify as a usability professional. I don’t either. But we’re not the only ones who get a say in this. As long as other people look at what you do and call it usability (and you know a lot of people do), then this is our professional association.

Call yourself what you will, the way the UPA conducts it self is a reflection on anyone who rightfully or wrongfully gets lumped under the usability banner.

As long as this is the case, I want an association that I can be proud of. That demonstrates good usability practice in the way it presents itself online, that doesn’t feel completely out of touch with contemporary practice – UX, Ergonomics, whatever else you do that is affiliated with usability. I have enough on my plate trying to fight the good fight with people who don’t know any better, I should be able to count on the UPA to support me in this, not to undermine me.

So, this means that I’ll be critical. Constructively so wherever I can.

But it also means that if you want me to help out – and not just as someone you can delegate some tasks to, but on something that can actually properly make use of my experience, passion and abilities – then the UPA is welcome to call on me. As they did last week.

I hope you care too. And I hope the UPA can do exactly what it apparently wants to do – bring together people from all different professional circumstances who care about usability so we can learn more and do better and make this a better world to live in.

And on that evangelical note… why not go check out some more photos from the crowdsourcing night.

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 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. 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 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.