Shokunin

In Japan, you encounter a lot of restaurants and shops that do just one thing. Often they do that thing really well. Tonkatsu, onigiri, shaved ice, you name it. I sought out quite a few of these places while travelling around Tokyo recently and two weeks ago I ate this bowl of soba noodles:

Everyone I could see in the restaurant was eating the same thing because it is the thing the restaurant does well. There is nothing inventive or groundbreaking about it. It is a well known type (sudachi) that you can get in a few parts of Japan when the citrus is in season, and it is amazing. It is the kind of dish that I imagine you can only arrive at after many rounds of making small tweaks until you achieve something with clarity and precision.

There are a few words and phrases in Japanese that you can use to describe this approach, though shokunin seems the most apt. So far as I can surmise, it means something like “a person who has dedicated their life to perfecting a skill or craft, in which the work of refining one’s craft is as important as the output produced”. I don’t think it would be terribly surprising to anyone I know well to say that I identify rather strongly with that concept, and yet it often feels at odds with working in contemporary digital spaces.

Refinement through iteration toward some perfected state sounds a lot like the agile manifesto, and yet that isn’t how things feel at work most of the time. We ask teams to peel off thin slices of work so that they can release quickly and repeatedly, but finding time to improve those slices post-release is notoriously difficult. The daily imperative is to add more and more and more, but constant addition comes at the cost of improving what we already have, or – dare I whisper it – removing things when needed. That situation is difficult to square with the feeling of wanting to do things right, whatever that might mean.

The possibility of achieving “rightness” is one of the reasons the new work we’re doing to examine our approach to using native code is so exciting. It is a chance to step back and reexamine many of our fundamental design choices and ask whether they can be improved upon. The work at hand gives us a specific set of tools for asking that question – native code libraries and design systems from Apple and Google – and we’ve written the project brief to ensure that we focus on reusability, maintainability, and performance (as opposed to just making it look cooler).

One likely output will be a new design system. The good news is that Apple and Google have already done a ton of work to develop libraries that we can leverage. We’re now three days into sprint zero and one of the designers on the team (Dave) has already put together a functional, code-based catalogue of iOS design components that we can use later to test and refine ideas. Reviewing said catalogue, it is immediately obvious how much we can lean on system defaults while maintaining a close relationship to the NHS’ web-based design system, so that’s good news.

Hopefully this alpha will provide the springboard from which we can develop a new set of tools (be they technical or process-based) to induce refinement, clarity, and precision across the entire app. The hard part will be figuring out how to do that in a way that works for all of the myriad services and data sets that the NHS App contains.

Noodle soup and apps are obviously rather different propositions. Achieving focussed perfection with soba might lead to something incredibly specific and quirky, but that is fine because there are always other kinds of soba to choose from (even if you need to go to a different shop to get it). Doing the same with an app that purports to be the one digital front door for an entire health ecosystem might not be possible. It might also be an entirely foolish impulse, and yet I can’t help but want to try.