Category Archives: Agile

The problem with Lean UX is …

By | Agile, Lean, UX | 2 Comments

The other day I wrote a quick response to the question ‘What are the weak points of the Lean UX design methodology?’ on Quora. A couple of people have asked me to explain a bit more about my post so I thought I’d elaborate a little.

The app I’m currently working on is focused on developing a Minimal Viable Product (or MVP)  for use in schools. Unfortunately the project has had strict time and budgetary constraints imposed on it so, from the outset, there was a real pressure to deliver as many stories as possible in the given time. (In a true Lean environment MVP wouldn’t be a deliverable as it is here but a state of flow but thats the situation we have.)

Due to the restrictions of this project its concentrated a lot of the Lean UX implementation headaches into a short period of time which prompted me to write this post.

One of the many problems with the ‘feature first’ approach is that in order to include as many features as possible any UX and design consideration is stripped so far back whats implemented could have a negative impact of the usability of the feature in question. While none of the changes made are huge compromises the cumulative effect can be damaging to the experience of using the product.

The other problem is that in order to deliver as quickly and efficiently as possible any delighter or exciter elements often get removed in order to fit the feature into the sprint. Once that happens there is almost zero chance of it ever getting retrofitted.

Andy Budd summarises the problem well in this blog post from a couple of years ago

“In the rush to deliver a minimum viable set of features (the threshold elements in the Kano model) we often ignore the elements that make the product really great (the exciters and delighters in the Kano model). As quality gets stripped back in preference for functionality, we slowly see our products become ever more minimal and ever less viable. It’s very rarely one thing that does it. Instead MVP often turns into death by a thousand paper cuts.”

In order to mitigate this problem each story or feature should come from the users themselves and should have a hypothesis which we, as a team, should seek to validate.

For example say I wanted to introduce a new brand of ketchup to the market. The hypothesis could read something like:

“We believe that lovers of spicy food will want to use our new brand of super spicy ketchup as a condiment with their food.

We will know this to be true when:

– We see a week on week increase in sales of our ketchup in supermarkets

– Our customers tells us they like the taste”

(not a great hypothesis but you get the idea!)

To continue with this rather clunky analogy – If we imagine that our ketchup is in the wild and our test supermarkets put it on a high shelf, out of reach for most people, we would probably find that hardly any ketchup is sold. From this you might assume that no one wants the new ketchup and the product is a failure. If however you put the same ketchup on a shelf which is easier for people to reach then we may find that more people buy it and our hypothesis has been proved correct and people love super spicy ketchup.

The point being if the feature we our trying to introduce isn’t given a fair chance by being implemented as well as it could be then we shouldn’t be surprised if hardly anyone uses it and its widely ignored.

So whats the solution? Well the bad news is there isn’t a silver bullet which will cure all the ills, more a few things that, if implemented well, may help.

  • Better integration between the devs and UX. This first one is a no brainer. Work together to design easily implmentable features with minimal overhead.
  • Spend more time talking to the PO so when they are grooming and prioritising the backlog they have the full picture and understand what the implications of their decisions are.
  • A key hypothesis for new features. What problem is this feature we’re implementing solving and how will we know when its succeeding? Include a hypothesis not just for the product but for each story and also include a KPI to test that its doing what its supposed to. Which leads nicely onto…
  • Once a feature is live keep testing it. Keep questioning its validity and seeing how the experience of its usage can be improved for the end user. Schedule points to revaluate features and see how the experience could be improved through iterative design.
  • Ditch the burn down chart. Burn down charts are only useful for management types who like graphs. The proof of progress should be in the features and stories which you’re pushing live which users using. (Theres a blog post in there somewhere but I’ll save that for another day!)
  • Continuous deployment – Don’t wait till the end of the sprint to release new stuff. Release early, release often.

Theres probably a bunch of other things that you could do but thats all I’ve got for the moment.

For the record I love Lean and Agile as a process for designing and building products, it just feels that sometimes in the excitement of getting stuff out there, we lose sight of the detail which separates the ok products from the great ones.

Empathy Quoting – A new take on the Risk Register

By | Agile, UX | No Comments

In the bad old days of Prince 2 project managers would cobble together a document called a Risk Register. The purpose was to try and predict anything that could go wrong with a project and then come up with a plan to mitigate the problem. While the sentiment was sound these documents were focussed around business need and (in my experience) were rarely designed with the user in mind. They are also (by their nature) very negative, which isn’t a great way to start a project!

Newer Agile and Lean methodologies do away with the need of the Risk Register because the iterative nature of development means that the project can roll with the punches but I still believe that getting the project team to give some thought to possible project outcomes (both positive and negative) isn’t necessarily a bad thing.

With this in mind I designed a quick workshop exercise that I used last week during the final stages of Sprint 0. Feel free to adapt and let me know if you have any suggestions. (Hat tip to Gamestorming from where I borrowed the game format)


TITLE – Empathy Quotes


OBJECTIVE – The objective of this exercise is to get the team to think of possible user reactions to the launch of your product. It also gives all team members a chance to air any possible concerns they have before a project starts.


NUMBER OF PLAYERS – 3-10 (if possible include all the project team including stakeholders)


DURATION OF PLAY – 15-30 minutes


HOW TO PLAY – Firstly get the team to identify all the parties who have an interest in the outcomes of the product and write these up onto a whiteboard. (The product I’m currently designing is for schools so our groups included students, teachers, parents and, because of the business importance, we also included senior stakeholders.)

Next hand out sticky notes to all of the team and then give them 5 minutes to individually write down as many likely quotes as they can think of from all the various parties both positive and negative.

When the 5 minutes is up get the team to take turns to read out their quotes and encourage the team to discuss their thoughts on the quote. The quotes can then be posted up under the various party titles and duplicates can be grouped.


Empathy Quote Board

Real example of an Empathy Quote board

Close up of the quotes

Close up shot of some of the quotes we captured as part of the workshop

STRATEGY – Get the team to talk about the quotes and give special attention to areas where the quotes have been grouped. Get the team to think about how they can capitalise on the positives and possible strategies for coping with any negative issues that may arise further down the line.

Keep hold of the quotes for the end of the project as they could also be used to refer back to when the product is launched.


Brighton UX Slides Now Up

By | Agile, UX | No Comments

Thanks to everyone who came along to hear me talk about Agile UX at Brighton UX last week. I really enjoyed myself and there was some great stuff from the other speakers. Even though we hadn’t really coordinated our talks there seemed to be a lot of crossover and some recurring themes which was good to hear.

The focus of my talk was Agile UX from a UX persons point of view. I want to get people out of the mindset of lumping all of the UX work into Sprint 0 and for the UX person to ‘own’ the project from the beginning to the end. Its worth downloading the slides from Slideshare to get the notes so that they make more sense. In the coming weeks I’ll expand and explain a bit more about some of the concepts in the slides.


About Agile, UX and Sprint 0

By | Agile, UX | One Comment

Now I’m a few posts in I think its probably a good time to start talking a bit about the agile ux process we’ve been developing at the BFI and the lessons we’ve learn’t along the way. So lets start at the top with Sprint 0!

Like it or not Sprint 0 is a well developed practice within Scrum. For developers its the time when they get to do all of the setup and prep work they need to do before they can start coding features and stories. In the bad old days of Scrum it was also the time when the UX part of the project got dumped. As a freelancer I’ve worked on a number of agile projects and been asked to produce the IA for a new website which has been shoe horned into Sprint 0 along with all the other UX deliverables. This approach makes life very difficult for the IA as they often have to work with an undefined set of requirements and quite often its also the last time you see these wireframes before they get pulled apart and turned into user stories for the backlog, changing beyond all recognition as the project develops.

We decided against taking this approach for the BFI redevelopment project and opted to treat UX the same as dev in Sprint 0. Getting all the initial user research done ahead of starting the project proper  would help the IA and design process when we move into the development phase with the IA getting developed in conjunction with the development effort. In case you’re interested our Sprint 0 lasted a couple of months.

Here is a list of the work we did, roughly in order. YMMV:

Personas – As with any other user centred design project the first place to start is with the initial user research and getting personas developed. If you only ever take one thing away from this post then make it this. In an Agile UX environment personas are worth their weight in gold! I’m sure you’ve worked on projects in the past where personas have been tacked onto the side of a project as an after thought and never used again. However in an Agile world where the backlog and user stories are constantly being validated and reassessed having personas to sense check these decisions against is invaluable.

The personas were designed in the normal way and amongst other things we’ve used them in this project for:

  • User Journeys (more on this in a bit)
  • User Stories (the bits that make up the backlog)
  • Recruiting participants for user testing
  • Team building (I’ll tell you about this in a further post!)
  • Backlog Prioritisation (more about this here)

Site Map – Before we could start writing user stories and looking at the first Sprint we had to develop a site map. All of the UX deliverables we have produced are flexible and are based on our knowledge at the time, they may (and often do) change over time and the site map is no exception. To date its been through 9 revisions as our knowledge has increased and is likely to change again before launch. To develop the site map we conducted a content audit of the site (to give you an idea of scale we stopped at 9 levels down and logged nearly 1000 pages!) We then took a digital red pen to the audit cutting out huge swathes of redundant content only leaving the good stuff behind. When we had reduced the audit down to something more manageable we then added sections for some additional site content for the site that we were aware of. This was then passed through an open card sort with prospective users of the site who were recruited against the personas and formed the basis of the site map.

You’ll see from the site map we produced that we went for a slightly different, non hierarchical approach to the map for a couple of reasons. The first was that we didn’t want to give the impression to the stakeholders in the organisation that one section was more important that another and the second was that because the content of the map is always changing it is easier to not bog ourselves down with details around where content should fit in the hierarchy at this stage.

User Journeys – The final stage of our UX sprint 0 was to develop typical user journeys for the new site based on the behaviours of the characters in our personas. We developed about 12 journeys and a typical journey looked like this:

1. Book tickets to a screening

Nick has heard that Tron 3D has been released and loved the original, so has convinced his friends to go see it with him next Friday. He Googles to see if it’s on at the IMAX. One of his friend is a student and want a cheap ticket.

Main journey:

Google > BFI, What’s on > select 5 tickets for the best seats on the xxth of Sept early evening (inc student ticket) > Pay > Get confirmation >

Further routes:

> Watch trailer/read (Sight & Sound) review/director interview (BFI live)

> If you like this, you may also like…

> subscribe to newsletter (upcoming films of same type?)

> become a member (emphasis on cheap tickets / how to save on tickets next time?)

> Explore the collection ‘Science in films as threat or danger’  (Special Collection) > Watch videos”

As with the site map we published these stories with a huge “This will change over time!” caveat but they were useful as a way of guiding the stakeholders and Product Owner when we started looking at the development roadmap. In order to develop the roadmap we prioritised the stories according to business goals, ease of development, and our knowledge of the organisation (the BFI has been through a massive restructuring during the lifetime of the project). The prioritised list of user journeys was then used to guide what went into the first sprint.

If you’re interested in reading more about using user journeys Jeff Patton has blogged about this.

So there you go. That was our Sprint 0. For seasoned UX professionals there’s nothing exactly earth shattering in there but from an Agile perspective it was definitely the right way to go about for this project and getting this stage of the project right helped the rest of the project no end. You’ll also notice that not one wireframe was produced during this phase!

In a future post I’ll write about how we work with Agile and UX in our sprints….watch this space!

Looking for UX design and research help with your project? Get in touch