An empirical approach through customer journeys in web projects


One of the keys questions facing teams developing customer facing application is how to avoid developing something only to find that it isn't needed. A 'traditional' backlog often fails in this regard as it is a list and as such is:
  • Hard to visualise
  • individual features not related to a customer journey or goal.
  • Can lead to a waterfall style analysis with little testing of ideas
  • Leads to the highest paid person in the room dominating what should be done next
  • Does not engage with people effectively
A training exercise to build an ecommerce site -
Could we use this approach in the 'real world'
Recently I was asked to help with a project as a Product Owner and I wanted to use a new, rapid and iterative approach to design. I had experimented with Customer Centred Design for some time and wanted to run a follow up experiment. My hypothesis was base on some training I did with teams unfamiliar with developing a product in an iterative way. 

The training exercise was to build a web site in around 6 hours. The team were about 50/50 technical and non-technical so we couldn't "build" the site in HTML so we set the the goal to produce a "working" site using the material s they had in the room - paper, stickers, string writing materials. I was inspired by the results, in fact the comments were "I cant believe we came up with so many end to end ideas".

Stories mapped to wireframes
A first attempt at a journey from numbered stories
We tried some ways to record the stories and dependencies. One try involved numbered stickers. Another involved numbers and we linked them together in a separate flow chart. The separate flowcharts were not effective as they were not related to the visual journey.

An initial user journey through wire-framed components
The latest experiment

But this is not really about that exercise but about taking that approach and putting it into a real project. After all a lot of project get stuck on agile design and creating valuable customer journeys.

So I tried it on the next project, refined it and tried it again on the next project. We did some sketching and wireframes and then walked through some journeys reusing common web components to create the user experience.

The key parts of the approach was:
  • The customers identify their goals based on half a dozen customer profiles
  • The customers draw how they would fulfil the goal
  • The sketches and drafted as rough wireframes the same day
  • The airframes are stuck in the wall and the journey shown with arrows
  • The points along the journey are marked with stickers
  • The stickers are numbered
2 user journeys ready for validation
Another set of users are brought in to provide feedback on the goal and how it was achieved. The most successful journeys were identified as those that would be developed

Any stickers that were essential to achieving the journey were highlighted and none essential stickers were left as they were.

At this stage no development had been done

The next stage was to create enough backlog to get the developers going. This was where the designer started testing some ideas how the site would look with the users. "Flat" mockups were created in photoshop and put around the wireframes.

At this point we had a whole lot of users invited in to have a walkthrough of the main journeys which once again confirmed we were on the right track.

Next steps were usable HTML templates. Here is a picture of one that didn't make the cut ;-).

We followed up with alpha and beta releases to closed groups of users as the minimum viable product was to remain secret until live release. This made it difficult to get good feedback but we managed through closed groups of users who securely accessed the site.

The results

Overall the results have got better each time. Later usability workshops and beta releases bore out our original findings. The strange thing was that other competitor site always missed the fine balance in tone.

I don't think we could have made this product happen in the time available. However there are always things to improve.

Things I would do differently next time 
  • Get some more users from the street in earlier to give feedback at the earliest stage possible
  • Push more for an early open release
  • Get rid of the "features" that weren't important (just throw them away) when reviewing
  • Don't create any backlog until the journeys were agreed.
  • Don't follow up with a prioritisation session - just get building.
Can't wait to try this a different way next time!

Comments

Popular posts from this blog

In sprint cumulative flow in Jira

Great leaders respond in adversity

Agile is not different words for the same thing