(image credit to www.stuffthathappens.com by Eric Burke, sadly no longer with us — the blog, that is. Happily Eric Burke is still with us and happily woodworking at www.ericburke.net)
This is a great illustration, and pretty accurate. I’ve seen similar things with the third version described as ‘Microsoft’…
The Apple and Google version are great if you’re going for the 80% use case. But remember that option three exists for a reason. And it’s not just bad design!
Let me give an example — the Government Digital Service has done an amazing job of taking the highest-volume, online-driven transactional services and automating them. So if you want to register to vote, or claim carer’s allowance, you get a slick experience (see www.gov.uk/transformation — I only just realised that of the original 25, nine are still in beta, and one is still in alpha).
But if, for example, you want to track down the published record of council spending over £500, well — good luck!
There are two main related problems:
1) Just as with public library services (only 5–15% of users are seeking a specific book, and 70–80% of books are issued from the ‘landing strip’ inside the front door), digital services need to cater for the main use case and the ‘expert user’’. And there’s never a business case for the expert case in terms of volume…*
2) To take another distinction — classically (and, to some extent, taking account of the above), digital services seek to follow the 80/20 law — mopping up 80% of demand by the digital (or otherwise cheapest) channel, with the complex 20% of the rest being absorbed by human connection — phone or similar… not a bad strategy overall, but this doesn’t generate the benefits or the savings promised. It’s only when the digital solution is sufficiently flexible and adaptable to deal with something more like 95% of the demand, winnowing out (through good service design) the *truly* complex 5%, that the service really delivers.
Then, of course, there are those who actively want to customise, those who need accessibility options to be able to make use of the service, and those who misunderstand. All of these can be overcome by good design, but at heart there is a difference between products and services and (in my field) a difference between commercial and public services.
The latter might be fringe cases for commercial services, but they are important to inform real understanding of digital service design.
There are additional risks of user-centred design, single use, and ‘appification’. Tight design around the customer — use cases, usually, rather than the user — means that joining up has to happen elsewhere — it pushes more challenges to the enterprise and the platform for technical consistency and organisation of access. And more challenges to the user to join up their various requriements across the multiple possible ways of achieving each task…
Apple and the like have led a design revolution from which we have all benefited. I personally deeply regret the many years I held out as a fan of the BlackBerry — my iPhone, apps and all, is frickin’ amazing. But we tend to get carried away with a simplistic unerstanding of service design — it still has to meet the complexities of life!
This post is in response to an enjoyable LinkedIn status update from Joerg Hochwal — with the comment ‘No further comment needed! Just keep it simple’: www.linkedin.com/hp/update/6131479984411340800
*a footnote to explain the rather compressed sentence:
1) Just as with public library services (only 5–15% of users are seeking a specific book, and 70–80% of books are issued from the ‘landing strip’ inside the front door), digital services need to cater for the main use case and the ‘expert user’’. And there’s never a business case for the expert case in terms of volume…
What I mean is:
a) 5–15% of public library users are ‘expert users’ — they need a specific book and might even use the catalogue (nobody else will) to try to find it — they’ll look in the relevant section of the library, they might ask a librarian, and they might even do a reservation!!
b) 70–80% of the books issued are not only issued based on less ‘expert’ requirements like ‘I want something fun to read’ or ‘I want a thriller for the weekend’, they are also issued from the immediate entry hall of the library. In fact, the place most books are issued from is the returns trolley — i.e.books someone else has returned are more attractive!
I then make an analogy with ‘main use case’ (in service design for digital terms, they group use cases as alpha, beta, gamma in reducing order of volume — the alpha use case is the one which represents the biggest number of users. The service is then designed to meet the needs of the biggest group, then the next biggest group etc etc.
Very often, the service only gets built for the first ‘80%’ of use cases. Those are the ones with the relatively lowest cost and highest benefit to develop… so by the time you get to the ‘rump’ use cases (the 5–15% of really complex cases that need design relatively more like the third example in the image), the cost/benefit analysis doesn’t justify doing the work.
chosen path 