A template for intensive design

I was recently speaking with a potential client about a project that I very much wanted to work on. Due to scheduling issues (theirs and mine) we ended up with one week in which we could both be available to work on the project. At first, it seemed like the logical thing to do was to walk away and hopefully refer them to someone else with more time on their hands… but we really wanted to work together. We started thinking… could it be possible?

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!

Persona driven user stories for Agile UX

Given how long I’ve been thinking about Agile + User Experience, I can’t believe it’s taken me so long to start doing writing user stories that are centred on the personas we’ve created for the project. Nonetheless, it’s something I’ve started doing recently and I’ve found it to be really successful. I’m not the only one – Will Sansbury has written about it before and Joe Sokohl spoke about it recently at the Agile 2010 conference.

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.

Drupal7 UX – Project Process

As you may have noticed, this is not your typical design project… there are things about it that are pretty unusual, but there are also some pretty standard aspects as well. We thought it might be useful to give you a high level view of the approach we plan to take.

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/