For the past couple of months, Richard Warner and I have been working with a number of teams to help them better work together. Each of the teams contains a Product Manager, UX Researcher(s), UX Designer(s), and Big Data Analysts who are working in an Agile manner.
Last week Richard and I sat down to work through one of the problems we are facing. A number of teams are using some kind of “Agile Canvas” derived from the start up community. It was our feeling that these canvases are driving the wrong behaviour in the teams. The most popular canvas with our teams is the one taught by Roman Pilcher.
You start with a strategic statement of intent. Then you list the Target Group (Customer Segment/Market), Needs, Product, and finally value. As Richard and I were chewing this over, we realised that although this was a great canvas for a start up, it lead to the wrong behaviour for enterprises. Value is an after thought. For a start up, you establish your product in the market and then think about revenue models, which often means being bought out by another more established company (The Instagram approach). As an established enterprise, this is a risky approach as you may develop a product that is not sustainable. If you pull the product, your customer will stop trusting you which will impact your existing business. At this point we decided to use “Break the Model” from Feature Injection to model the different order in which you perform the tasks. We realised that there are a number of different valid paths you would take based on the nature of the insight driving your discovery process.
We realised that a design hypothesis that we test potentially contains a number of sub-hypotheses.
A design hypothesis needs to contain each of these sub-hypotheses. However the order in which you build up the design does not matter as long as the Feature/Design is the last thing you consider.
Richard and I looked at all the different combinations of order in which you could create the design hypothesis.
So here is our working hypothesis. Depending on your insight, you need first to establish the outcome, market and needs. Once you have these three, they form the design brief for the UX designer to design the “feature”.
The feature should always be the last part of the hypothesis. If you start with a “request for a feature”, this should be regarded as an insight (tea-bag). If we end with the outcome, customer or needs, they will likely be ignored. If you end with the outcome, you may be subject to reputational risk if you have to pull the feature because it is not sustainable (not a problem for startups who are looking for an IPO exit). If you end with the customer, you will not know who should like the feature and who should not. You may lose an important customer segment without realising it. If you end with the need, you may deliver a product that nobody wants, like Segway or Betamax. Betamax was higher quality but did not satisfy the need of fitting a movie on a single tape.
The PM is responsible for establishing the correct outcome. Data Analysts and UX Research are responsible for providing insights and customer segmentation (market). The PM/UX Rearcher/Data Analyst and UX Designer “pair” to identify the customer segment and associated insight that is most likely to deliver the outcome. From the insights, they create hypotheses about the customer needs to be satisfied. Note that sometimes, the process starts with an outcome, sometimes with a need, and sometimes with a customer segment. It should never start with feature. If the starting point is a request for a feature, this should be treated as an insight.
The combination of Outcome, Customer Segment (Persona) and Needs form the design brief. e.g. In order to increase blah, as a blah, my need is blah. ( A Job Story ). There may be several job stories. e.g. The need to learn quickly at the expenses of a slower process, and the need to learn slower in order to have a faster process. Each design brief may result in several designs.
It is the responsibility of the PM and UX Researcher to confirm whether the designs have achieved the design brief. The designs can then go through Melissa Perri’s “Bad Idea Terminator” process. We start with the fastest and cheapest ways to invalidate a hypothesis, gradually moving on to more expensive methods. (e.g. Team/Expert review, Usability Testing, then MVT, and finally full production)
As soon as we get a UX design, we can create the Given-When-Then scenarios to describe it’s behaviour.
This process will help us split the design (Epic) into several Epics. Once we have the Epics with GWT scenarios, we can easily slice them into user stories.
At this point it is pretty easy to identify the APIs (services) needed to deliver the application.
This whole process is summarised as follows:
Richard and I are looking for feedback on where we got it wrong. :-)