I’m sure that many of you will have heard about the very worthy Alpha.gov.uk project, the first prototype of which was released earlier this month.

If you’re a user experience practitioner, this should particularly interesting to you.

By way of a quick background, the AlphaGov project was formed in response to findings from a report by Martha Lane Fox, Revolution not Evolution into Government online services and opportunities to improve. (As a tangent, I’d love to see her in a cagefight with Lou ‘The redesign must die‘ Rosenfeld)

In this report she recommended the introduction of

“a service culture, putting the needs of citizens ahead of those of departments”

The AlphaGov project responded, setting out two overarching objectives:

1. To test, in public, a prototype of a new, single UK Government website.
2. To design & build a UK Government website using open, agile, multi-disciplinary product development techniques and technologies, shaped by an obsession with meeting user needs.

See. It doesn’t get more UX-interesting than that right? It reminds me quite a bit of the D7UX project I worked on with Mark Boulton and the Drupal community, so I’ve been following it’s progress with a keen interest.

Now, go have a play with the prototype and see what you think. I’m actually not going to comment on the UX of the prototype today, partly because it’s actually quite difficult to do so. I’ll get to that later.

What I want to talk about today is the responsibility that playing out a project like this in public brings with it and how, in my opinion, AlphaGov have let down both the UX and Inclusive Design/Accessibility professional communities.

What you do, not what you say

Let me start by saying that I have a lot of admiration for the the ambition of this project. There is a lot that is good about it. There are also a lot of smart and talented people on the team.

The first thing that strikes me as strange is that on a project that claims to have an obsession with meeting user needs, the team contains a visual designer and a content strategist, a general strategist and multiple search analysists but NOT a user experience lead.

That’s right. We have an obsession with meeting user needs but not so much that we’ll actually hire someone who has extensive experience in actually making that happen.

Now, the project was fortunate in that it had Richard Pope, who I first met when he was a very UX-savvy developer at Moo and who  played the Product Lead role on AlphaGov. As far as UX resources go, you could do a lot worse.

The team also recruited Paul Annett later into the project. Paul also has some UX experience but, as I understand it, his role was primarily as visual designer, making the interface a nicer place to be.

Without commenting on the interface itself, the lack of a rigorous approach to user experience is very evident in the way that the team talk about the work that they have done and their ‘design rules‘.

In a recent blog post about their agile methodology Project Manager Jamie Arnold describes exactly what this ‘obsession with user need’ entailed:

We spent the first two weeks in February recruiting a team from inside and outside of government, talking through the scope, agreeing some design rules and agreeing a vision for the Alphagov product based around the recommendations of Martha’s report.

We ended those two weeks with a list of prioritised user needs (based around search analytics from Directgov, Hitwise and departments),

We roughly grouped into functional areas and stuck to the wall. Each card (or user story) represented a user need, prioritised roughly from left to right and top to bottom.

Crucially also there was a fair amount of @tomskitomski and @memespring‘s product experience. All this was more than good enough to get on with twelve weekly development sprints.

More than good enough, eh? For many projects this would have been more than they ever had to work with.

But this is not just any project. This is a groundbreaking, whole of government initiative that claims to take a User Centred approach and be obsessed with knowing and supporting the end user need.

I think a project like that needs to demonstrate User Centred-ness a little more rigorously. For example.

Who is the audience?

At no point that I saw did the AlphaGov team ever apparently think deeply about what kind of an end user they were going to prioritise. They talk about ‘thinking about who our users were’ and having a ‘user-base of all the entire adult population of a country’.

As User Experience practitioners we know that although you might want the whole country to use whatever you’re designing, you need to put a ring around the kind of users you MOST want to support.

As designers we always privilege some behavioural attributes over others, even if we don’t articulate it. By not thoughtfully articulating this, you risk either an incoherent approach to the experience design or resort to self-referential design (designing for your own behaviour – something that is incredibly difficult to overcome).

You can’t take a User Centred approach to design when your user is ‘Everyone’. You need to define who your users are. You must clearly identify the behavioural characteristics that you most want to support and focus on designing to best support these.

There are many valid design approaches that do not require such a clearly articulated definition of the end user, but these are NOT user centred approaches. Thinking generally about ‘users’ while we design is not doing user centred design. I think it’s pretty irresponsible to suggest that it is.

AlphaGov sends a message that you can say you’re doing User Centred Design but you don’t have to show any evidence of a UCD process – audience definition, research, user involvement, design principles that actually track to specific behaviour attributes.

For example, it would have been great to see some personas developed and shared for this project – even hypothetical ones that drew on the data/insight available to the team. As well as helping the team avoid the problem of the ‘elastic user’ (particularly problematic when you do think your target audience is everyone), it would also help us be better able to evaluate what is good and bad about the prototype. It would also have demonstrated that the team was actually practicing User Centred Design.

(Elastic user, for those not familiar with the term, was coined by Alan Cooper to describe the way that while making product decisions different stakeholders may define the ‘user’ according to their convenience, often resulting in self-referential rather than user-centred design. More here).

This leads us to one of the complexities of the AlphaGov audience which is that, in reality, rather then being obsessively user-centred, the project had two competing audiences. The largely undefined end user and, often more importantly, the stakeholders who would ultimately decide the fate of the project – public servants. These two audiences have VERY different motivations and goals for this project, and the impact of the latter on design decision making was never clearer than when the accessibility topic came up.

On Accessibility and a conflict of interest

Again, from what I know, there was no formal expert accessibility (or inclusive design as I prefer to call it) consultancy on the project team. This is not to say that the team didn’t have quite a bit of knowledge about the mechanics of accessibility (the impact of technical decisions on whether something could be certified ‘accessible’).

The team sets out a really thoughtful understanding of what it takes to make a service properly accessible:

Accessibility should start with research and consideration, not with box-ticking or sprinkling a few standard accessibility features – especially in a government context where a user journey regularly extends into the real world (Booking a driving test? You’ll probably want to know the facilities at the test-centre).

Ultimately, the AlphaGov prototype doesn’t make any significant attempt at achieving accessibility (particularly making a site that works fine even with JavaScript is switched off) apparently due to the short timeframes and ability to ‘retrofit’ accessibility later (hrm).

Actually, what I picked up from discussions about this on Twitter and elsewhere was that actually, it was the other target audience – the stakeholders – who most influenced this decision. If they put the focus on accessibility, they’d have to take away some of the ‘shiny’ – AlphaGov would end up feeling like Just Another Government Website. Rightly or wrongly, the shiny would help excite the public servants to approve and fund a beta version of the prototype.

Perhaps it was a noble sacrifice… who knows. Point is, it’s far from transparent.

The message that the world takes away from this exchange is that accessibility, even when your audience ‘entire adult population of a country’ is optional. And that accessibility can be ‘done later’ not, as they had first set out, built into design considerations from the outset.

These are really bad messages to be sending and, given how publicly visible and lauded this project is, sets the work of many amazing inclusive design specialists back considerably.

It’s hard enough to sell in good accessibility work already. AlphaGov just made it harder.

Activity Based Design and Search Analytics

OK. So I will talk briefly about the prototype… but mostly to discuss how the data you have access to can significantly shape your design.

The team have published very little information on the data that has guided their design decision making for this project but we do know that search activity has influenced it heavily. A team of sixteen people included no UX lead (sorry, did I mention that already?) but two people doing search analysis.

In the design rationale blog post, Richard Pope implies that search logs strongly influenced the design and information architecture strategy for the prototype.

we spent the first couple of weeks scouring search logs and analytics for the various central government websites; thinking about who our users were and generally discussing the kind of thing we were setting out to make

Based on what we learned from looking at search-logs, we knew that there was a relatively small subset of tasks that require the majority of people need to interact with government online. So we should do less and focus on tasks.

Since for the vast majority of people their web journeys (finding out the date of the next bank-holiday, or reporting a lost passport) start with a search engine rather than a direct visit we should think of Google as the homepage and we should also feed Google, Bing and other search engines nice friendly urls.

If someone is just landing at a page on your site then it’s helpful to start thinking of every visit being a new user, assuming they have no prior knowledge of the structure or content website they have landed at.

It is really difficult to evaluate this prototype from a user experience perspective, given the competing target audiences. The best you can do is try to recall the last few times you interacted with a government website and try to reenact that here. Every time I do that I come away with a lingering feeling of disengagement. There’s something that search logs probably don’t really show which is that this is MY government. For better or worse, I have a long term and multifaceted relationship with this government and yet, every time I encounter this site it (by design) makes me feel as though this is my first visit. I find that really unsatisfying and kind of perturbing.

Now, this is not a professional design critique, this is a qualitative research data point of one. But it’s not something that you’ll ever pick up from search stats and analytics. I could bore you further with how I find the promise of localisation with this infinite noob status even more perplexing, but you’d have to spend time with me to understand it. And then spend some time with a bunch of other people to see if this is a common theme or just me being an edgecase.

And people will never post this kind of feedback on GetSatisfaction. (Most people can’t really articulate this kind of weird feeling and wouldn’t think that it was important enough to comment on compared to, say, a bug. You need a good facilitator to extract this kind of data).

To do really good user experience design you need a mix of data points. If you privilege one set of data, you’ll see that in your design. I think we’ve got some of that going on with AlphaGov.

Quantitative data is fantastic. I’d love to see more of what the team had to work with and how they applied it in their design process. But it’s just one kind of input. Qualitative research helps you better understand your end users and thereby to design better for them.

People who do User Centred Design do Qualitative Research.

User Experience is a Time Soak/Non-Agile

Which leads me to the final problematic sub-text that I felt emanating from the AlphaGov team which was essentially that ‘we’re as user centred/accessible as we can be given that we only have 10 weeks to build this thing’. This perpetuates the myth that User Experience can be a time soak, that it slows you down, that it doesn’t really have a place in an Agile methodology.

This is where having an experience UX practitioner on the team from early on could have been helpful.

It is certainly true that historically, Agile and UX have had a fairly vexed relationship but these days many practitioners are experienced and adept at including both user research and ux design into the most demanding agile iterations. We have a toolkit of lightweight qualitative research approaches that work beautifully in this kind of fast paced and responsive environment. UX does not have to be a laggard either at the outset or in the throes of an agile project.

The ten week project timeframe is absolutely no reason to not include real practice of user experience in the process. You may need to find someone who has experience working this way (not all UXers find this kind of project much fun), and you may need to be creative in the way you structure the work, but you should definitely be doing it. Particularly if you’re setting an example of how projects should be done, as the AlphaGov team certainly was.

In conclusion

I want to repeat again, this is a very worthy project and many of their design principles are, I think, sound. For many commercial projects, the methodology that they’ve applied and shared is absolutely appropriate. But the bar is set higher here.

By doing this project in public, by making such a big deal of putting the end user needs and their importance to the project, the AlphaGov team have set themselves up as rolemodels. They’re sending messages about the the way things should be done. They’ve made quite a rod for their back.

If I was just a member of the community, I’d probably be nothing short of delighted with what they’ve achieved. Unfortunately, as a User Experience practitioner, I feel kind of glum. This project has talked the talk of caring about the end user, of placing their needs at the centre of the project and above the needs and desires of government, but at every step, they’ve done little to set a good example for how others should actually do this.

I hope AlphaGov does move forward into BetaGov.

But I hope, if they do, they take a moment to think about what the public performance of AlphaGov and then BetaGov means for their professional community.

Either stop calling the project User Centred, or hire someone to really focus on user experience and do more to share how they’ve integrated real user insight into their design strategy and implementation.

There’s a big opportunity to set a good example to a big audience here. Let’s take advantage of that opportunity and show the UK Government, digital industry, hell, the whole world what projects really look like when they’re user centred, – that they don’t have to be cumbersome, expensive and slow.

Imagine that, a properly user centred government website that was agile, and shiny and amazing. Now, that’s something to get excited about.

And so it was that we ended up working on one of the most intensive design and research projects I can remember working on. It was hard work, but good work and – in the end, we got the job done. I thought it might be useful to share the format we used so you can consider potentially this approach if you find yourself in a similarly time challenged situation some day!

Important note: this is not a sustainable way of working. You can do this for a week, you can’t do this week in, week out for a year.

The challenge:

We started the week with lot of data/content in a database, a target audience (digitally excluded), a content management system (SharePoint 2010), an accessibility goal (triple A) and a logo.

We needed to end the week with a high fidelity prototype that could be taken into production the following week.

We wanted to do this taking a user centric approach, ensuring that our concepts were evaluated by members of our target audience throughout the design process.

The team:

It was evident from the get-go that this was going to take more than me. I’m a freelancer, so this mean that I had the pleasure of hand picking a team to work with me on this.

I asked Mark Boulton to help bring our prototypes up to high fidelity. Mark & I have worked together a bit in the past and he is really comfortable in that grey area between wireframes and finished design – this is an area where designers can butt heads a little, so avoiding that was going to be very important in this project.

I also asked Andrew Travers to be the second UX designer on the project – I knew we’d need two pure UX people on this project as we were aiming to both design and research in the week. Andrew brought some brilliant subject matter expertise and accessibility know how to the project, but more importantly, he was brave enough and flexible enough to contemplate such an ambitious/slightly mad project plan. (Andrew has also written up his thoughts on this project).

We pretty quickly realised this was a great opportunity to invite an intern to work with us. Not only could we really use an extra set of hands, it was a rare opportunity to see pretty much a full UCD project in the space of a week. We were thrilled when Lisa Drake took a week of holidays from her job to join us. It was a great decision – both to invite a mentor and to choose Lisa, who was fantastic.

In addition to this we also had four members of our client team on site for the entire week including decision-making-enabled representatives from marketing, content, technical and their project manager.

Finally, we had a daily call scheduled with the Shaw Trust who were going to review our work each day and make sure we were on top of any accessibility issues that emerged as our prototypes developed.

The venue:

We needed a space that would allow for our team to be onsite, to do workshops, design work and to conduct research. We booked some space at the London User Research Centre: a research lab and observation room and another workshop room with day light. This gave us the research facilities we needed and enough flexibility in the space to be able to accommodate the range of activities and people that we needed to house in the space of that week.

On the final day, we de-camped back to the client’s offices to wrap up our work and prepare for a presentation to the larger client team.

The format:

The general shape of the project was this:

• 1 day of UX ‘foundations’ and initial concept development
• 3 days of prototyping, researching, iterating
• 1 day of completing templates, annotating and preparing presentation
• a day or two in the following weeks to finalise any outstanding work.
• 3x UX resources for all 5 days, 1x ‘visual’ design for the last 4 days (+ several extra days in following weeks)

The general shape of the day tended to be:

• project team ‘kick off’ meeting in nearby cafe around 8am
• full team kick off in labs around 9am
• work, work, work, work, work,
• full team debrief at end of day
• project team continue work/debrief at pub/over dinner that evening.

Preparation:

There was limited time for preparation, and this largely consisted of agreeing a recruit brief for research, briefing recruiters, reviewing existing materials that the client had (mostly from an aborted previous attempt at this project), and project planning – working out a rough idea of what we were going to do on each day and a fairly specific plan for day one.

Day one: UX Fundamentals

This day had to provide the grounding for the rest of the weeks work – we needed to:

• clearly articulate the value proposition
• clearly identify and describe the priority audience(s)
• understand the primary scenarios of use  that we wanted to support
• come up with some concepts for how we might present the our content to this audience to support these scenarios in a way that clearly expressed and supported the value proposition.

Our approach to the first three items entailed extensive use of post it notes, individual brainstorming, collaborative affinity sorting and prioritisation. Our approach to the final item involved a lot of group sketching (including our client team, of course), discussion and ranking.

As we left the lab at the end of the first day we did have a couple of concepts we were going to move forward with but we weren’t feeling particularly inspired by them. Upon decamping to a local pub that evening (in preparation for meeting and briefing Mark who was joining the team that evening) it became clear that we had quite a bit of affection for one of the concepts that we’d dropped while in conversation with the client – it was perceived as a little too risky. Over a pint, we did a little more work on this concept and got it into a sufficiently good shape to include as an option to present in research the following day. We then went to get pizza and bring Mark up to speed.

Day two:

After our morning kick off, Mark took the client team off to start work on the ‘look and feel’ of the site, starting with a mood board exercise. Meanwhile, in the observation room, the UX team were frantically building prototypes of 3 concepts (using Flairbuilder, mostly for speed) and preparing a discussion guide in time for the first research session at midday – the first of 14 interviews scheduled in this next three days.

By midday, three very rough prototypes and one very unrehearsed discussion guide in place – the research began. We saw six people in the rest of that day – tag teaming research between Andrew & myself, clients watching every moment of the interviews, and design happening on the fly meaning that no two participants saw exactly the same prototypes.

By the end of that day, we had learned a lot. We’d abandoned one concept entirely, introduced another, were pretty sure two concepts were not right and that the concept we’d rescued in the pub the night previous – the risky one – was going to be the right way forward – but it still felt a little scary. We needed more evidence it was right. We didn’t have much to show the Shaw Trust for them to advise on.

That night, we were all pretty nervous.

Day three:

Four more research participants today. At some point it becomes evident that the ‘risky’ version is definitely the way forward. A whole range of participants have now managed to identify personally with it (beyond our expectations) when our initial fear was that it would be alienating. We leave Mark to grapple with increasing the fidelity of the design and move onto tackling the more content rich templates and, as it turns out, the content itself.

We uncover a range of information architecture issues, particularly around terminology/labelling on a freshly ‘redesigned’ content model, we completely reshape the way the content is presented and in the process get very excited about a fancy faceted navigation system.

The Shaw Trust remind us that people with cognitive disability will struggle to make sense of our fancy faceted interface. We realise we’ve gotten excited about an idea and forgotten about our audience (who are not necessarily cognitively disabled, but who are the least experienced web users). We prepare to kill our darlings.

Day four:

Another four participants today. Having sketched all the way home yesterday and back again this morning, over coffee before our kick off meeting I have a feeling I may have replaced yesterdays darling facets with a much simpler solution that properly matches the needs we’re hearing coming out of research.

Our clients are more energised and excited about this project than they were at kick off and this is in no small part due to them having the chance to actually witness the people they work to help every day, actually using the system we’re designing for them. These people are stepping out from behind stereotypes and suddenly feeling a lot like us – but with the specific needs they have more clearly articulated than ever.

We test the newly simplified data-rich interface and struggle to keep a straight face when the participants describe the hard to make sense of page they’re expecting to see, then react with visible delight when they see our stripped down page, designed to focus specifically on the content they are seeking. (You don’t get those proper delight moments often, we cherish those).

We copy and paste ‘high fidelity’ designs into our prototypes as parts of them are ‘ready’. Headers and footers first, then bits of content as it starts to feel like it’s working.

We’re having all kinds of difficult discussions with the client about corporate colours and logos, but we’re also able to test our variations as we go – to understand which fights are really worth having and which are less so.

Even now, we rarely show the same prototype twice. Constantly refining.

We leave the lab on day four feeling pretty amazed at how confident we feel that we’ve actually, really cracked this. That it’s actually going to work.

Day five:

We’ve got a meeting room at the client’s offices. We make a window full of post it notes of outstanding tasks, we prioritise and allocate the tasks. We make tea. Lisa, miraculously, produces a packet of chocolate biscuits.

We work as fast as we possibly can to work through the details of the templates, to make sure we can map the database to our templates, that we can make any ‘massaging’ that needs to happen to the content relatively painless, that we’ve thought through various states and orders in the flows.

We put together a presentation of the work we’ve done over the past week, our rationale and our designs. We do this so quickly it takes less time to make the presentation than it does to give it.

We kick off our presentation by showing some of the profiles of participants we’d met that week – young single mothers, people suffering from mental illness, people who are now or were recently homeless, or in prison. People who really need us to help make access to services easier to find – especially as more and more of those services go online.

Our client is happy with the work we’ve done, but we’re not really surprised because they’ve been there, with us, helping make decisions and seeing how and why decisions were being made the entire time.

Wrapping up and next steps:

Not everything happens in a week. The following week we put the wireframes into a more formal document with annotations and some notes to capture the general principles of the design approach and content strategy.

Mark has more work to ‘design’ all the wireframes into developer-ready templates. We’re still struggling with the homepage … we know the components that need to be there but getting them to work visually is tricky.

We do a handover meeting with the client to talk through everything including any questions they have outstanding. There’s a bit of work required to properly map the database to the templates. We agree there is a whole other project required to look at the information architecture and bring it into alignment with our new findings and approach.

What we learned:

• your team is everything – you need a good, flexible, friendly, committed team to work this way
• having the client on site is invaluable. This approach would probably not have worked (or at least, worked so well) if they hadn’t been there participate, observe, field our questions, respond to our challenges.
• you don’t need to sacrifice research just because your timeframes are short. You will have to be flexible and not get hung up on process, but you will learn what you need to make good, informed, decisions. Also, you give your client the opportunity to see their ‘customers’ in real life. Both of these are invaluable.
• although you’re in a hurry, you need to take time to communicate.
• if you want to work like this you need to be brave and confident, you can’t be a perfectionist, you have to be careful with your client seeing you making mistakes and being wrong (all part of the process)
• not only does an approach like this work but it works well. As a team, we were inspired and energised and felt we’d probably done some of our best work because of the way we were working not in spite of it. I think we’d all be keen to work this way again. (As soon as we get leave from our families who we saw very little of that week).

Photos by Lisa Drake. Thanks to Start Here for being brave enough to work with us this way!

I reckon they’ve missed out on at least $50 from me, which is not much I guess. But I’m far from alone.

What’s the problem? Well, it’s a two stage thing. If I’m missing something obvious (and with that, two years of pro-membership) please do let me know.

The first problem – I want to pay with my credit card.

The credit card I previously used has expired (as they do). The only option I’m given around credit card payment is to EDIT the card, which I select. In order to proceed I then have to re-enter the card number OF MY EXPIRED CARD! Now, show of hands, how many people actually hold onto expired credit cards and would actually be able to complete this task? Anyone?!

larger image here.

After going backwards and forward searching for the part where I can simply add a new card I give up and go to plan B – using PayPal. I use PayPal all the time, I used it last week on eBay and it worked fine. And yet, when I try to pay for my Flickr account using PayPal this is what I’m told:

larger image here.

‘The email you entered is not associated to this payment agreement you are trying to confirm. Please try again’.

That isn’t even a sentence, right? I think I get the gist of what they’re saying but even with my advance PayPal skills (I moved from one country to another and still have a PayPal account – anyone else who has done that knows exactly how much more you know about PayPal than you ever wanted to) I’ve tried everything I know and can’t get this to work.

At any rate, I’ve now spent way more time on this than Flickr is worth to me. My once great love of Flickr is now dead. Yahoo has not only lost my $50, they’ve also lost my emotional connection to their brand and my previous evangelism – worth way more than all the pro subscriptions I’d ever pay in a lifetime would be worth.

But – here’s the point of the story (because I don’t really want to waste your time moaning about one company’s crappy user experience, where would we stop!) – this is a revenue point. This is a place in the user journey where money changes hands.

If you have a product that has interfaces like this – places where people are giving you money – please pay particular attention to them. Make sure they are working. Make it as easy as possible for me to give you my money.

There’s an old saying, ‘take care of the pennies and the pounds will take care of themselves’. I don’t think it’s entirely true – I think the pounds actually need their own special UX strategy but having lots of pennies come into the coffers to support us as we come up with great new ways of making lots of pounds is eminently sensible and a great way to STAY IN BUSINESS!

Don’t let easy money like this leak away. If you have interfaces like this one that might also be leaking, go check them now.

And, while you’re at it, make a note to check on them regularly.

Meanwhile, if you want to see my baby pics, I’ll be over at Facebook. I’m still looking for a new place to share my UX pics. Suggestions welcome.

Drupal/Economist Project – Sprint 2 Demo from Leisa on Vimeo.

Today is Demo Day at The Economist, where all the various SCRUM teams will show and tell what they’ve achieved in their latest iteration. I thought I might see if I can get into the habit of pre-recording my demo so I can share it with you here and ask for feedback & advice! So, here we go!

In the past two iterations (this project runs on 1 week iterations) we’ve done a combination of research, design and testing the publishing tools that the editorials staff will use to administer what is known as the ‘Channel Index Pages’ – these are pages that you’d land on if you clicked something in the navigation that said, say, Business & Finance, or Science & Technology, and their job is to pull the most interesting current content to the top so that readers can access it more easily.

These pages are made up of a range of elements, most importantly for this demo are News Packages (consisting of a lead story and related stories/media files) and what is known as the Bloggy Chunk (an editable text area that section editors can freely input their own content, it is still very much a work in progress and is variously used as an aggregator for recent interesting stories that The Economist isn’t covering in depth or to highlight interesting reader comments, it may in the future show content from an RSS feed).

Although working within the SCRUM methodology, I am trying to take a systemwide approach to the design as far as possible, so there has been a whole range of questions that I’ve had to consider that aren’t strictly in the ‘stories’ for our sprint (logging on, activating editing, for example), and similarly, I’ve tried to devise interaction approaches that will be reusable across the other parts of the system that we have yet to design rather than just customising the design approach to this individual problem set.

The design approach shown in this demo is still quite lo-fidelity and ‘broad brushstroke’, it will become much more precise over time, at the moment my priority is to try to work through and communicate the ideas as quickly as possible – giving me more time to explore a range of approaches, and to iterate approaches which has been very valuable.

So, if you have a moment and are so inclined, I’d really love to get your thoughts on the approach we’re taking so far. We’re also about to embark on starting some development work on this – to make sure we can build it in Drupal without too much difficulty – so if anyone has any guidance on how best to approach this, modules we should take a look at, anything else you think we might need to know, I’d love if you could share it here!

Look forward to hearing from you and thanks in advance!

(apologies to anyone who saw the first version of this blogpost with the screwy audio synching)

Economist/Drupal – Intro to the Publishing Tools Project from Leisa on Vimeo.

Some of you may know that The Economist is in the process of moving their web content management over to Drupal and I am really excited to be joining the team working on the implementation of these publishing tools over the coming months – my mission is to wrangle the Drupal6 interface such that journalists will be able to spend more time doing what they love to do – chasing and writing stories – and less time doing what currently drives them mad – dealing with content publishing tools.

There are a few reasons that I’m excited about this project:

1. it’s The Economist! – it’s a company full of clever people writing thoughtful, well researched material
2. it’s Drupal! – also full of clever, thoughtful people
3. it’s a really logical progression from all the work that we’ve been doing on d7ux throughout the year which has really been focused on transforming the Drupal admin interface to be more friendly to content producers
4. it’s a big deal – getting this right is really important to The Economist being able to realise their potential and ambition in the online space
5. it’s Agile – we’re doing SCRUM in 1 week iterations with an experienced scrum master and even a scrum master master! I am a big fan of well run agile and always looking for opportunities to experience design working well in Agile projects
6. it’s end user focussed – each one week iteration includes user research/design evaluation (ah, the luxury of known and easily accessible end users)
7. we’re sharing the process – when The Economist signed on with Drupal the community and open source philosophy was a big part of this decision. We think this is a great opportunity to contribute a case study and some more exposed design methodology back to the community, along the lines of what we’ve done with the D7UX project, so I’m going to be sharing our work on the project here in the coming weeks and months (if you’re interested!)

To kick off the sharing process, I asked Kerrie Lapworth, Production Manager, and Barney Southin, Managing Editor of Economist.com to give you an introduction to the project in the video above, and I look forward to sharing more with you as we move forward!

Here’s a few ‘social skills’ we learned:

1. you need to take responsibility for the way that your community behaves: it’s not in any way productive to associate the way that a community is responding to you by blaming the community or even the individuals in it. If you respond that way you’ll never be able to improve the situation. As with every relationship, the only person you can change is yourself. If you’re getting a bad vibe back, the first thing you should do is check your tone and content – what are you saying? how are you saying it? can YOU improve the way you’re communicating. The onus is on YOU to get it right.
2. tokenistic involvement is a waste of time: if you don’t really care what the community has to say on a subject, don’t ask them. If you do want their input, take the time to design a way for them to interact with you in a way that gets the best from them. Be creative, put a bit of thought into it. Avoid polls and and use surveys with care – you might feel as though you’re involving the community because you have ‘numbers’, but do you have real involvement. Ask yourself what the community knows that you can benefit from, then consider the best way to help them share that knowledge and experience with you.
3. ask for specific feedback: if you want to get good feedback from your community, tell them what you want feedback on. We *didn’t* do this much during the Drupal.org redesign – instead I was trying to keep it ‘neutral’ and not influence what and how people gave us feedback – we learned that by asking for specific direction we not only got excellent feedback on the issues we highlighted, but others as well. Without direction the discussion tended to be less helpful and was more likely to get personal (not in a good way!) This will also help you to get feedback on more than just the homepage.
4. give examples: if you want a particular kind of response from the community, it is important to provide an example for them to follow and really great instructions to participate. For example, when we were doing the ‘crowdsourced wireframing’ I included a picture of one of my not very elegant wireframes so that people had a sense that their submissions didn’t have to look ‘designed’. If there are instructions to participate, make sure these are as clear as possible. Then make them even clearer.
5. wait… wait… wait… engage! once you post something for feedback, go away and make a snack and do NOT get involved in the conversation immediately. This is probably the most difficult rule to follow and one that Mark and I had to coach each other on (and occasionally police! – step away from the computer!) throughout the project. If you dive in and start responding to the first few comments, what you unintentially do is skew and retard the conversation. Rather than exploring a broad range of issues and allowing key points to gradually evolve, the discussion focusses on whichever points you have responded to, everyone starts to focus on those few issues. The richness of the feedback is lost because you dive into detail too quickly. Rather, wait until at least a half dozen people have posted (or 12hrs has elapsed, whichever is soonest) and see what the trends are in the feedback, then start getting more involved in the conversation.
6. admit errors quickly: the only exception to the rule above is if you’ve stuffed up. In this circumstance you should admit the mistake quickly so that the conversation doesn’t focus on your error. In one iteration of our redesign we accidentally omitted a very important call to action (I know… how could we?!) As you can imagine, that oversight dominated the feedback we received and by the time we responded (way too late!) things were getting a little frenzied. We should have been keeping a closer eye on the situation and stepped in as soon as we realised our mistake.
7. don’t go dark, but don’t respond to everything: there is a balance in the correct volume of response that you need to aim for. It is really important that you don’t disappear (even if you get really busy) – the community needs to know that you are there and that you are listening. On the other hand, don’t feel as though you need to respond to every comment that is posted – unless you are only getting a handful of responses. As a rule, aim to respond to trends and issues not individual comments. Feel free to occasionally respond with a simple ‘I’m here and listening, I don’t have the answer yet’.
8. lead by example: it’s an oldy but a goody - interact with the community in the way that you would like them to interact with you. Be polite and respectful. Others rudeness or bad behaviour is no excuse for you to let loose. It’s up to you to set and maintain the standard of communication you want the community to engage in.
9. assume good faith: it’s a general rule of interacting with others online, but keep it at front of mind especially when you’re putting your own work out there for review and, therefore, more likely to feel a little defensive. Text is a tricky medium for communication – people might sound like they’re being mean or overly critical or agressive when they’re just not great at communicating (or you’re feeling defensive and read everything as an attack!), or being a little lazy with their words, or created unintentional meaning. Always assume that people are trying to be friendly and constructive and helpful if there is any room for doubt at all. In fact, even when it is evident that they *are* being a little mean, it is often useful to deploy this rule – play dumb and be extra nice. Don’t waste time fighting or being a smart ass, or just being mean, or engaging with others who are. Focus on the task at hand – doing good design.
10. be a human: I think this is the absolute most important thing – don’t assume a Voice of God, don’t pretend to be infallible or to know everything. Don’t feel as though you have to use very big words all the time. Swear occasionally (if your community is ok with that). Admit that you are nervous (or outright terrified, if that’s the case). All of this is allowed and encouraged. Communities are made up of people, of human beings and you are but one of them. Use your real voice and speak honestly. Be open.

Respecting conventions doesn’t mean that you have to slavishly follow them, that would be boring and unnecessary, BUT if you *are* going to break with convention then make sure it is very well sign posted, otherwise people will make mistakes.

I give you terminal 5 at Heathrow. 

Firstly a quick question – how long before an international flight do you need to get to the airport? 

The vast majority of people would say that the conservative answer is 2 hours but they don’t usually give it quite that long. 

Another quick question – how long before a flight to a European destination do you need to get to Heathrow? 

Again, most people will give you an answer around the 1 hour mark.

Now… you may already know this, but if you want to fly from London Heathrow Terminal 5 to Istanbul in Turkey (as I did the other day – yes the weather is beautiful, thank you!) they want you to get there not one, not two, but THREE hours before your flight.

We arrived an hour before our flight the other day and were severely reprimanded and had to be given ‘permission’ to proceed from the check in desk to try to get our flight. Fortunately (for us) the entire security software system crashed and massive queues meant that most flights (including ours) were delayed and we made our flight with plenty of time to spare.

So, given that getting to the airport 3 hours before the flight is apparently a big deal for BA, and given that T5 is relatively new, and given that in all my years of international flights, I’ve never been expected to be anywhere any earlier than 2 hours before the flight, you might expect that BA would make a big song and dance about this 3 hour requirement.

You’d be wrong.

They *do* make a big song and dance about the fact that we were leaving from T5 and that T5 is a new terminal. I definitely knew that because they advised me at almost every interaction I had with them regarding this flight (and these days there are quite a few touchpoints between purchasing the ticket and boarding the flight). But what did they tell me about time?

This is an excerpt from the email they sent me one week before the flight, specifically to help me to prepare for my upcoming flight:

IMPORTANT: For flights departing from Terminal 5, you must pass through ticket presentation and security at least 35 minutes before the flight departs. For other important information about passport, visa and UK domestic flight security checks, please visit ba.com/t5information.

So, honestly. Do they *really* expect me to turn up 3 hours early when this is the information they give me.

Perhaps they do, but I can tell you that a good portion of the passengers for the Istanbul flight were stuck in the security queue with us, having arrived much later than 3 hours before. And I doubt that it was because they were being naughty travelers, or that they liked the adrenaline rush of almost missing a flight. They just assumed, as we did, that turning up an hour before a flight from London to somewhere in Europe was the right thing to do, because that’s what we’ve done many times before.

This is what we do as humans. We make assumptions based on past experience and if we think we *know* how something works we don’t bother investigating it in detail, because we could spend our time and energy investigating things we think are new and interesting.

If people are making assumptions about your product, service or interface design and you’re *not* following the conventional approach, make sure whatever you’re doing differently is very clearly signposted. And then signposted again. Otherwise mistakes will happen.

And a customer who is making a mistake is very rarely a happy customer.

(disclaimer – yes, yes. I know that technical Istanbul is both European and Asian, doesn’t really make a difference to the discussion tho’)

Here is a new phone we got the other day. It’s our landline phone. Pretty cute huh? It’s called the Aqua by BT. Don’t buy it. I paid about £100 for a set of these phones. They are going to cost me a lot more than that in no time.

Here’s the thing. How do you end a call on a slide phone (which is what these are)? Simple – you close the slide, right? Well – yes, on every other slide phone that I’ve ever encountered, but not on this phone. Closing the slide does nothing… except closing the slide. So, when I went to make a call last night I discovered that, in fact, a call was still in progress. A call to a mobile phone, that had been connected for 8 hours. Ouch. I am *dreading* seeing this months phone bill because this isn’t the first time we’ve made this mistake. Although, this is probably the worst example.

We keep making this mistake because the slide-to-end-call convention is such a strong part of our model of how a slide phone works. We will keep making this mistake – despite the fact that we will be punished, seriously, by our telco.

As cute as these phones are, they’re going to be returned very soon because the experience of using them is so broken.

Moral to the story – if you’re designing something that has existing conventions associated with it – ignore them at your peril. Otherwise you’ll end up designing something that sucks as badly as this phone. And we don’t want that, do we.

End of rant.

Several weeks later, this arrives:

Dear Leisa

I am not a sensitive person by nature, but I have to say that I am feeling a little hurt. We’ve invited you into our Club, but you’ve clearly decided not to.

So, as a one-off attempt at sheer bribery, I‘m offering you your first, trial Club case HALF PRICE at just £47.88 (that‘s a ridiculously low £3.99 a bottle!). Plus, two FREE gifts, worth £30. That‘s an overall saving of nearly £80.

Sound good? Then click here to claim your HALF PRICE case and FREE GIFTS.

But you‘re probably not ready to join yet. You‘re probably thinking…

I can buy the wines anywhere.

Well you can‘t actually. The boutique wines we reserve for our Club Members never appear in the supermarket. And they are always offered to members at a lower price than non-members get them for.

It‘s just like one of those ghastly book clubs.

Er…sorry, not correct on this one either. Quite simply, you have no obligation to take any wine you don‘t want. You don‘t even have to pay us for any wines that don‘t blow your socks right off.

I‘m not the joining type.

If we explained that the reason we have a Club in the first place is because 40,000 people can buy better than 1, perhaps you‘d change your mind? If you join us, 40,001 people will buy better than 40,000.

Or maybe you‘ve just not got around to it. Which is fine. People who buy wine by the case tend to be busy.

So what would be a good reason?

Here‘s one good reason to test us out right now. We‘re keen to recruit new Members. So, for one last time I‘m offering you your first, trial Club case HALF PRICE at just £47.88

Take our HALF PRICE case NOW, and you‘ll receive a complimentary pair of beautiful Dartington Wine Glasses, completely FREE. Plus, a FREE professional lever corkscrew, worth £20.

Still not sure?

What is the worst thing that can happen? If you don‘t like the wines, I promise to refund you instantly, without any fuss whatsoever. If you agree that these wines are a big step better than you can get in the supermarket, you can look forward to a lifetime of feeling superior to non-members.

So why don‘t you join us now and find out what it‘s all about for yourself? Not next week, but right now.

Cheers

Rowan Gormley
Founder, Virgin Wines
www.virginwines.com/reasons3

0870 050 0305

The insight that the tone taken in this email gives me to this brand is profound, and frankly, I don’t want anything to do with a company who has this kind of attitude in their customer communications.

We’ve spoken before about positive ways to handle ‘abandonment’ – well, here is the flipside, a combination of guilt-tripping (‘I am not a sensitive person by nature, but I have to say that I am feeling a little hurt. We’ve invited you into our Club, but you’ve clearly decided not to’), cynicism (‘So, as a one-off attempt at sheer bribery…’) and smart talk (‘Er…sorry, not correct on this one either…’). Yes, consumers today are media literate and this level of ‘openness’ could potentially work well, but be nice about it. I’m supposed to enjoy buying wine, with this email VirginWine have put me right off my drink!

Take care with your tone – and of course, this applies to any kind of copy that you’re writing. And know that only *very* few brands can be anything but nice to their customer.

Have you seen the Yahoo! Go 2.0 interface yet? I have, although only on my laptop as their mobile beta is currently full… I’m on the waiting list.

Yahoo! are very excited about this interface. Here’s how they describe it:

A revolutionary design. Yahoo Go! is the first application optimized for the “small screen” of a mobile phone that truly makes it easy and fun to access the Internet. Everything about the Yahoo! Go interface is designed to be both visually stunning and give you what you want with the fewest clicks possible.

At the core of the UI is the ‘carousel’ at the bottom of the screen that allows you to switch between the various widgets or applications (such as email, and the typical content streams – news, finance, sport etc.).

The carousel could hardly be described as revolutionary, as it is obviously inspired by the Mac OS UI.

More interesting, I think, is the design of the mobile search and the customisation of content sources.

The mobile search actually sounds pretty clever. Not only have the designed the search results in a way that is more useful for the mobile user:

oneSearch includes more actual content in your initial results than any other search—all grouped by subject matter and relevance, so there’s no sea of links to wade through like with a PC search.

The search engine also has location awareness – both awareness of where you are in the application AND physical location awareness. Now this is getting sexy.

oneSearch improves results based on both where you are in the application and where you are in the real world. For instance, launching a search for “eagles” in Sports will return results for the professional football team first. Similarly, searching for a movie will yield showtimes in your local area.

Ah, can it be – finally – location based services coming to a handset near you! I’ve waited a long time for this!

Content customisation looks as though it allows you to subscribe to RSS feeds to your phone using their interface. Very nice (although probably not so new). So you can choose who provides your news rather than live with whoever Yahoo! has their content deal with.

Another nice looking feature aims to remove the need to type URLs (hooray! this is no fun at all on a mobile).

Yahoo! Go also makes it easy to get to other websites. Simply type in the name of a website you want to visit (like eBay), and oneSearch returns the link to the website. Click the link and you’re there.

Having recently upgraded to a reasonably current handset (review coming soon!), I can confirm that the mobile user experience remains, as it has been for some time now, utterly rubbish. It’s as though all stakeholders are conspiring to make things as difficult as possible – from the product design of the hardware to the installed software to the internet content and design. There are frustrations and errors to be made at every turn.

So far, most compliments have to be paid to one or two browsers that are invaluable in making the internet a vaguely hospitable place for the mobile browser. Yahoo! Go 2.0 will hopefully also make the overall experience a little more palatable.

At the end of the day though, it should be a massive wake up call to us all that Yahoo! borrowing an element from the OS user interface and transplanting it into the mobile environment could be considered revolutionary.

It seems ridiculous to me that it has taken this long for any kind of innovation to areas like search interface for mobile and eliminating URL entry to occur. Sure, I know it’s a technical nightmare to develop for mobile… but it’s outrageous that little seems to be happening to increase consistency across handsets and browsers and operating systems.

*deep breaths*
With any luck I’ll get a Beta invite sometime soon… stay tuned for reports on what it’s like to actually use this interface.

Have you used the Go 2.0 interface yet? How’d you find it?