Battles that would rage, angrily, for months – dying down when the provocateur was busy with other work but rising up as soon as they had a little time on their hands – these battles began to go away. Long frustrating and unproductive sessions of trying to explain, defend, rationalise why the design that I suggested had more merit than the many and varied suggestions (or requirements) coming from stakeholders all but disappeared. People who would usually sneer derisively at the design team became participating members of the design process.

It’s not perfect, it’s no silver bullet, but for me, it’s been a transformation.

And it’s pretty simple. To embrace experimentation you just need to stop talking about design in a Socratic way (other related but less civilised methods are also very common) and start formalising hypotheses and tests.

Stop having meetings to argue about which design approach is better  - endless meetings with stakeholders full of defensiveness and crazy arguments where the people who tend to win are those who are loudest, most persistent or highest paid. Start making decisions based on lightweight research that provides evidence (sometimes stories, sometimes numbers) to support the design that most strongly supports the agreed goals.

Goals. That’s one pre-requisite you need for this experimental approach to work. You need to have agreed what your goals are for the design. What success looks like. Without this agreement, no change to methodology will save you.

The experimental mindset is an egalitarian approach to design. It allows that anyone can suggest a design solutions and, rather than argue endlessly about whether it is better or worse than other approaches, you design a test. Find out how to find out which design works best.

Hypothesis, prototype, test.

There are loads of tools you can use to test ideas quickly – from some quick in person user research, to some A/B testing (if you’re not set up to do A/B testing, meet your friend Google Content Experiments and get onto this immediately), to an online card sort, to one of the range of tests that places like VerifyApp offer. The methods for testing are limited only by your creativity and are mostly inexpensive.

Sure, you can’t design from the ground up this way – you will still need a good designer that you trust get you to a good starting point from which you can experiment up, but once you’ve got the framework in place, don’t waste time and goodwill bickering about the details but encourage experimentation throughout the entire organisation. You’ll raise the overall ‘design IQ’ and happiness quotient of your company, your design team and, most probably, even yourself.

With respect, I disagree. UX Developers are definitely a thing, and more than that, they’ve become an essential part of my project team mix, especially when I’m working on the UX of an application style system (which is more and more the case).

I’ve been fortunate enough to work with front end developers who have plenty of sensitivity to creating good user experience for as long as I can remember, it makes perfect sense that most front end developers are more interested in UX than those whose work doesn’t touch the UI. These are great front end developers, but, by my definition, they are not UX Developers.

A UX Developer is all of that – a front end developer with a sensitivity and talent for crafting a UI that is going to be better to use – but in addition to that they have a declared interest in understanding more about the User Experience work that goes ahead of the UI design. I doubt many of them would ever be happy doing pure user research, but they’re probably keen as mustard to run some of their own usability tests, guerilla or otherwise. They’d probably go nuts having to do some of the workshops and stakeholder communications that forms a key part of the garden variety UXer’s role, but they want to understand the strategy and customer insight that is driving the bigger picture product decisions.

There are different layers of user experience – these layers sit on a continuum between the pixel and the person.

UXers like me sit further toward the ‘person’ end of the scale, focussed on understanding end users, stakeholders, and what is going to work well for them as a wholistic experience. UX Developers are situated much closer to the pixel. If you’ve met a UX Developer, you will not be surprised to hear them tell stories of videoing a transition in an application so that they could slow it down enough to understand how it was working so they can recreate it. It’s what they do.

UXers like me (and I’m all about Prototyping in Code, I’m just not particularly good or fast at it) work very well with UX Developers. Trying to get the finest details of the UI right is not something that someone with my rudimentary development skills should be doing, and frankly, it’s not where my real strength lies. With a UX Developer on my team, I can involve them in the strategic / research aspects of the project as a second pair of hands, then work with them to create prototypes quickly, moving from sketches direct to code – and really nice feeling code – quickly. Eliminating the need for putting myself or my stakeholders through the wireframing process and being able to iterate on the ‘how it works’ part of the design from almost the very beginning.

The UX Developer, having been involved in the UX process from the beginning of the project, understands the rationale behind the product and design approach and is able to make good, consistent, UX decisions without needing every piece of UI defined. In fact, in my experience, they’ve probably made better design decisions than I would have made… well, sometimes.

Is UX Developer a synonym for interaction designer? Perhaps, except that it makes strong front end development a critical part of the skillset, which I think creates a completely different team dynamic and quality of interaction than an interaction designer who uses prototyping tools like, say, Axure (and there are still plenty of those). If you can’t produce high quality, production quality code, then I don’t think you’re a UX Developer. (Although, you may well be a perfectly competent Interaction Designer ).

How do you work with a UX Developer?

• get them involved in the strategic parts of the UX process – defining the product, the audience, the research, all the fun stuff. Let them increase their UX skillset and make sure they understand WHY things are happening the way they are in the project.
• sketch together and get prototyping in code as quickly as possible. This is not a senior/junior relationship, this is the dovetailing of compatible skills to get to a better UI, faster.
• share ownership of the UX, don’t feel like you have to make all the design decisions, let them own the finer details of the UI and you focus on the bigger things (that are actually pretty hard to stick to when you do get to obsessing about the details on the interface)
• allow yourselves to push and pull focus from the strategic ‘person’ level to the pixel level – it is difficult for one person to maintain focus on both ends of the spectrum at the same time – a team like this helps enable this rapid shifting of perspective more effectively.

A UX Developer is not a silver bullet. You can’t work this way on all kinds of projects for all kinds of people, and it can be hard to find a good UX Developer to work with. I’m a freelancer, so I used to travel solo from project to project, but since I’ve started working with UX Developers, I now like to BYO team (where possible) and an essential member of my UX posse is a great UX Developer.

Works for me, your mileage may vary.

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!

It’s as simple as it sounds – rather than writing user stories that nominate members of your project team, instead write them nominating the persona they are designed to most benefit.

For example, on the Project Verity backlog I’m working on with the team at Mark Boulton Design we have the occasional ‘as the developer, I want to…’ but the vast majority of our stories lead with ‘as Verity, I want to’, or occasionally ‘as Verity’s boss…’

This is, in theory, a teeny tiny change, but in practice I find it has two big effects.

Firstly, it keeps your personas alive and actively in use – this has always been a big challenge for UX people in agile and non-agile teams alike – here is one big opportunity where agile teams actually seem to have the edge.

Use your personas in your user stories and your personas can’t be left on a shelf to gather dust, instead they effectively become active members of your project team. If the stories don’t make sense with the personas, then either your story or the persona is at fault – the team needs to sort out which is at fault and make the appropriate adjustments. Which leads me to…

Secondly – it’s much harder to write a rubbish user story when it’s grounded in a persona. Let’s face it, there are plenty of user stories in most of our backlogs that are really management feature requests disguised as a user story. Transform your backlog so that the user stories that are supposedly there to help the users are given to a persona and suddenly it becomes much easier to interrogate feature requests against real users.

I can’t tell you how many user stories I’ve ended up throwing out because when I try to write the ‘so that I can…’ part of the user story it becomes impossible to make a compelling case because I have to make it gel with the agreed persona attributes.

I keep thinking – because I haven’t heard of people using this approach very much – that there must be some fatal flaw I’ve not thought of or come across yet… if so, perhaps you know what it is?

Making Agile & UX work together can certainly be tough, but this strikes me as one of those opportunities that Agile offers UXers to actually practice our craft all the more rigorously and visibly in our teams. I think I’ll be doing a lot more of it in the future.

On a project like this, however, a highlevel view is really the only one we *can* give because, in all honesty, we’re not exactly sure what we’ll be doing in 2-3 weeks time let alone 2-3 months time. We have a mud-map though, and this is roughly what it looks like.

We are working with the team at Acquia on this project and they run an Agile shop, so we’re going to be trying to synch into their iterations as best we can.

One of the biggest challenges for User Experience and Design work in an Agile environment is getting the strategy and vision of the design worked through – to that end we are very thankful that our friends at Acquia have been flexible enough to give us a nice big chunk of time which we’re calling ‘Iteration Zero‘ and in this time we are doing a whole load of thinking, and strategising and talking with you to work out what our overall strategy is. This is why we’re asking about audience, and tone of voice and those more ‘abstract’ questions.

By the end of Iteration Zero, which for us is around 14 April, we hope to have an overarching strategy and ‘framework’ for the proposed interface for D7 in the form of some pencil sketches and a sitemap, an agreed experience strategy, audience matrix and tone of voice. We will have tested framework using some low fidelity (paper) prototypes with a range of participants across the spectrum of our audience matrix and we will feel confident that we know what we are doing and where we are headed.

During this time we will be working closely with the Drupal community to understand *how* our framework can best be implemented for release with D7.

The remainder of our time on the project, (which runs until around the end of July) will be spent working through exactly how the strategy is implemented, looking at the very many fine details and issues that will need to be resolved, whilst also testing and iterating the work we have done based on the results of our testing.

How and when can you get involved?

During iteration zero – it is VITAL that we get the foundations of our strategy correct so please engage and continue to engage with us as we work through the strategy, audience and tone issues. This will be mostly in the form of you reviewing what we’ve come up with and providing us with your feedback.

Get involved with the framework design – we’re going to be posting (very soon) some initial sketches that show the direction we’re heading in – we would love to have your feedback on that.

As we did with the d.o redesign project, we’ll be doing a CrowdSourced Wireframe activity that we would invite you to participate in where we’ll be asking you to take a part of the Drupal Admin you think needs work and drawing up a solution (or, if you’ve done it already, why not submit a screencast to ‘Pimp Your Admin’ on our YouTube channel!)

We are also going to re-launch the Crowdsourced Usability Testing for this project – this time with a little more warning and some more structure – so we would invite you to help us test our designs with people around you and contribute to our understanding of what is working and what is not, and help validate our approach. In the coming week I will be releasing a lot more information around this, including some timings, so it would be great to have you on board with this exercise (and it would also make a great exercise for interns, students, people new to usability/UX who want to get some experience doing usability testing).

As the Acquia team start to take designs from us, they will also start releasing a working prototype that you will be able to review and comment on – I’m not sure on timings for that but I’d expect probably mid-late May (I’ll update when I know more).

So as you can see – there will be LOTS of ways for you to contribute all the way through the project, and, don’t let us limit you! If you have ideas we need to see, or other ways you’d like to contribute – please let us know!

Any questions? Comments etc.?

X-Posted from: d7ux.org/project-process/

At any rate, here’s a refresher. The Agile Manifesto says:

We are uncovering better ways of developingsoftware by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Seems almost straightforward, doesn’t it :) Deceivingly so, of course. There’s all kinds of complexity wrapped up in that simple manifesto, some of which we touched on recently and which requires so much more exploration.

Add in the UCD (User Centred Design) aspects and the questions only multiply!

Let’s start with this really easy one – who is the ‘customer’ in Agile UCD?

I would hazard a guess that your response would depend on whether you’ve been doing more Agile or more UCD lately.

If you’ve been doing lots of Agile lately, your answer would quite likely be that the ‘customer’ is the person who is paying the bills. The company or department who has commissioned the work that you’re undertaking. And that, as such, they essentially get a seat at the table as the development goes on, to have their input as decisions are being made minute to minute, and to request changes as they see fit. With any luck, this person is actually a real decision maker within their organisation and their input won’t be completely over-ridden as soon as your work is presented to the wider client team.

If you’ve been doing lots of UCD lately, then your response will probably be quite different. You’ll probably be thinking that ‘customer’ means ‘end user’ – the people who will ultimately end up as the beneficiaries of all your hard work. The people who you’re observing in order to generate your design work and who’s needs and characteristics are influencing decisions about the product functionality.

They’re two very different types of customers, aren’t they. With very different demands and expectations and requirements of you as a designer or developer of a product.

So, what to do?

Well, frankly, in Agile UCD, you need *both* of these types of customers. A successful project takes into account both the business requirements and the user requirements and having direct input from both sources directly is incredibly valuable.

Is it really necessary and valuable to have a member of your ‘client’ (which is what we’ll call the people who pay the invoices you send for this work) as a part of your day to day project team? I don’t think so. I think that ‘clients’ should be highly involved at the beginning and end of each iteration/sprint and on call throughout this time, but I don’t think that either the project team or the client gets much out of them having a permanent seat on the development team. I’d much rather see the team being left to get the work done and the client doing whatever it is they do best – which is very rarely being part of a design or development team. (Hands up if you think I just committed some kind of Agile heresy?)
On the other hand, one of the key reasons for moving Agile to Agile UCD is to add in involvement from actual end users. Traditional flavours of Agile simply haven’t allowed for the type of observation that we do in UCD and that serves us so well as designers to be included in the Agile process. This is why we are seeking to building in scope for contextual research and usability testing activities as iterations occur – rather than just at the very beginning of the project and at the very end.

So, in fact, there are two ‘customers’ in Agile UCD – but perhaps we’re better calling them the ‘client’ and the ‘end user’. One of the challenges of working out how Agile UCD should work is to determine the best way to involve each of these parties in our cycles of work so that we get the best from them and they give us the information and insight we need to do the best work we can.

You’ve seen some of my ideas about how this might work… what are your thoughts, ideas and experiences?

I had the opportunity to present a talk on the power of iterative methodologies over waterfall at dConstruct last week (a.k.a Waterfall Bad, Washing Machine Good). This is an extended re-mix of a talk that I gave very briefly at the IA Summit earlier this year (I also presented a similar talk at UX Week recently).

I will put my slides up as soon as I can get the file size low enough to get them loaded on SlideShare – will need to get in and optimise those post-it note photos I’m afraid! In the meanwhile, here’s the slide that most people have expressed interest in!

Not to make any excuses, but this is a really tricky talk to give. To get to the meaty bit – the bit where the UCD and the Agile come together, requires a base understanding that Waterfall methodologies (or sequential methodologies) suck, and that iterative and incremental and collaborative/cross-disciplinary methodologies are the way forward. It also requires that you have a working knowledge of Agile.

Lots of people assume that everyone has both of these things, but I can assure you they don’t. If everyone *knew* this, then there’d *be* no waterfall shops out there, right?!

Nonetheless, the most interesting part of this talk is getting down to tin tacks on HOW we can give Agile more UCD flavour – to actually integrated UX activities into a sustainable agile pattern. And this can be pretty tough.

I have to say that while I’m 100% committed to the overall idea of Agile UCD being the methodology of choice, I’m more or less committed to some of the assertions I made in my talk… (is this naughty? I just wanted to take a position for the sake of conversation, and I had plenty of those post-talk!)

For example – one of the things I said was that I think that Agile cycles (or sprints or whatever you call them where you are) need to be longer than 2 weeks. That it takes that much time to fit UX activities into a cycle. I *think* I believe that this is true, if you’re going to do solid UX work in an Agile environment as well as be there in a ‘paired’ environment getting the functionality built. More than one person suggested to me later that perhaps the same end could be achieved by just doing less in a two week sprint. Perhaps.

I don’t think there are any clear rules on this yet… at the end of the day, what I *do* want from this discussion is for UX practitioners to feel comfortable engaging in the discussion about how long a cycle should be with the rest of the Agile team and to not back away from the discussion when rebuffed with a simple ‘well, that’s the rules’, or ‘that’s just the way Agile works’ argument. Again – if your team doesn’t do this then consider yourself fortunate. There are lots of designers out there trying to eek their way into an established Agile environment who come up against this kind of resistance all the time.

There was another series of questions that I got from LOTS of people – and a very valid and important questions they are too…. I’m not sure I have the best responses so I’d love to get feedback from you on what you’d do and say.

The questions are around how do we sell Agile UCD to our organisation and to our clients? How do we manage the fact that this agile approach takes away the security blanket of knowing what you’ll get and when you’ll get it that Waterfall apparently provides.

When I was talking with people about this at dConstruct, I found myself saying these two things repeatedly, and it seemed to elicit nods and smiles and general agreement/enthusiasm.

The first is that whilst in waterfall you might know what you’re getting at the beginning – you have no reason for confidence that you are getting the *right* thing at the end of the process. And, in Waterfall, there’s no real mechanism for changing your mind or learning from the project itself as you go. You can very easily end up with the wrong thing, and then spend a whole bunch of time and money changing everything around so that it’s right – and you’re changing things at the most difficult (read: most expensive) time to be changing things!

So, what this means is that the ‘security’ that Waterfall appears to offer is really, in many cases, false. And although the budget for the project may be fixed at ‘x’ – no one knows what work will be required once the project is completed to get it into it’s correct state. Or the cost to the business of not having got the project as good as it could have been.

Make sense?

The second point is that we can ‘charge out’ Agile in a very different way to Waterfall. Although it would be nice, your client doesn’t *need* to commit to months and months of development work in an Agile environment. They don’t need to commit to the full budget. In fact, they *could* potentially just commit from cycle to cycle. Your company/department can calculate the cost of a cycle, then with the client, negotiate what work will be undertaken in that cycle… rinse, repeat etc.

Of course, this is not really the ideal way to be running a business and you’d hope that, over time, as your clients got more and more clued to the benefits of working Agile rather than Waterfall, they’d be more willing to make longer commitments to the project, making your cash flow a little less precarious!

Fact is though, you do need clients who are clued into the benefits of Agile and Agile UCD for their projects. If they don’t get what’s in it for them (and there is plenty!) then there’s no way you’ll sell them on it. So, knowing those reasons yourself and then educating your clients is a big part of the process.

It’s not easy though, and we’re not going to be in a state where we can be all happily Agile UCDing tomorrow, next week or even next month.

It is, however, without a doubt the ideal way to run your projects. It’s going to require a lot of thought, a lot of work, a lot of trying things out, and a lot of educating our clients and other people in our organisations.

I think it’s going to be worth the effort!

In the meanwhile, lets start sharing ideas and experiences.

How would *you* answer these questions? What questions do you have? What’s been your experience with Agile and Agile UCD?