I’m excited to be making a start on my current contribution to Drupal which to help drive a project code named Prairie. This is a project with two big, ambitious goals:
1. to improve the collaboration tools on Drupal.org so that we can do more and better work together and make Drupal better, faster.
2. to make Drupal.org a better and easier place to become a contributor – to make it less intimidating to people who want to get started contributing to Drupal, coders and non-coders. To increase the number of Drupal.org members who are actively contributing and to recognise a wider range of contributions.
This started out as a ‘Redesign the Issue Queue’ core conversation at Drupalcon in Chicago, but rapidly increased in scope so that it’s now really more accurately described as a Social Architecture project.
For those amongst us who are actively contributing Drupallers, comfortable with the Drupal Groups infrastructure, there’s a group you can join and contribute to.
For those who find the Groups Infrastructure perplexing or just plain frustrating (and you can count me among that number – you’ll find Groups Usability as part of the scope for this project), I’m going to try to keep you up to speed here and I’m experimenting with sharing some screenshots that we can annotate together… we’ll see how well that works – at any rate, I do want to try to open the discussion up outside of the Groups infrastructure so that we’re not just a bunch of insiders talking amongst ourselves.
The issue page – Designing a tool to fit the task
So the first thing I’d love for you to give some attention to are some initial ideas on redesigning the Issue template.
The ideas in this rough wireframe draw heavily from Quora and Open Ideo and try to address opportunities for us to make our discussion more comprehensible and focussed, as well as to make sure that they move through the stages of problem solving (possibly with custom designed interfaces for the specific requirements of each phase) to make it easier to ‘call in the troops’ from the various disciplines when they’re required and also to create spaces that are more appropriate for each discipline in turn (rather than all trying to squash our requirements into the one UI). It also introduces the concept of collaboratively naming an issue and providing a summary for it.
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.
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.
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.
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.
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! ;)
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.
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.
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).