Becoming everyone’s problem

We’ve just had quarterly planning again. It is a big event that involves bringing all of the App teams together for two days. Lots of presentations, lots of discussions, a fair amount of negotiation. During these events, my normal role has always been to float around between teams as a roving advisor. For the last two editions, my energy has been focused on working with our native transformation team to distill their plans. In this latest instance, that pattern has flipped itself inside-out and I am now once again roving around, this time on behalf of the native re-platforming team. We need to get other teams – who have never really worked on properly native software before – to start thinking about how they’re going to redo their bit of the app in native code.

The planned changes mean designers must rethink how their parts of the App function. Native apps work differently than websites – something I don’t think we’ve ever fully internalised. With the web version sharing a codebase with the mobile app version, everything had to work in its lowest common denominator setting (the web). In a world where the NHS App exists as three codebases and leans more heavily on mobile app design conventions, that’s no longer good enough. Teams will need to take platform differences seriously and design everything three times. This sounds bad, but it is also necessary: this is how we get the best out of each respective platform we build for, this is how we raise the quality bar.

Everyone seems up for the challenge, which is encouraging, but it is still a real challenge. New skills need to be learned and old habits need to be un-learned. That isn’t a surprise, but it is real work.

I began the process of getting people into the right headspace several weeks before quarterly planning started and continued that work during the event. Thus far, I’ve spoken to five teams about the topic. Some of them have an entirely new project to work on. For them, it makes sense to start by designing for the native app to come. These projects should be quite fun: they get to start from something like a nearly blank slate, inventing new ways of designing App stuff. (Have I mentioned that we don’t have a design system or anything like a settled approach yet?)

Other teams need to make smaller changes to extant features and services. During this process, they can and should translate their area of the App into the more app-y future state. This will cause work that initially looked small to become significantly larger. That condition has led me to start prepping product and delivery managers about how this work will affect their timelines and capacity. I don’t think I’ve made too many enemies here, yet – the work has the full-throated support of senior leadership (bit of a plot twist, that) – but I am mindful of being the “well, actually” guy, slowing people down. This is a new way of working and we haven’t developed processes or muscle memory for it, yet. We’ll get there.

After planning was wrapped up, I dipped in to the NHSE design huddle to spread the word amongst the wider design community. I covered the origins of the work, what we’ve done over the past year, where we’re at now, and where we think we’re headed. Overall, I got the impression that people were enthusiastic about the work, but there were some very good (read: hard) questions raised about what this means for approaches to design and prototyping:

Will all designers need to learn Swift and Kotlin?

No, but people working on features or services for the App should! While it remains entirely possible to design in layout tools like Figma, I don’t think it is a good idea. Everything I’ve done over the last six months suggests that understanding a technology, platform, or channel is best accomplished by working with it directly, by getting your hands into the machine. Designers will need to develop new skills and that will take time, but I am not convinced you can really get the feel for how designing a native app is different from designing a website until you’ve wrangled the specific technologies used to make them.

Will there be a new, native prototype kit?

We think so, but we don’t know what it will look like yet. The NHS Prototype Kit relies heavily on Nunjucks, but there aren’t many analogues for native code. Things like Stencil and GRMustache.swift exist, but I’m not convinced they will offer us much benefit (it also isn’t clear whether these are being actively maintained). SwiftUI and Jetpack Compose are relatively expressive and easy to grasp (imho), so it might be better for designers to just work directly with the code and skip using a templating language. For now, we have teams picking up the prototypes we’ve made and trying to figure out how to reconfigure them for their needs. I am guessing that we’ll learn a lot about how to create reusable tools by watching how teams get on over the next few months.

How do you use native prototypes during user research?

Thus far, all of the research we’ve done has been in person. We’ve run a combination of lab (participants come to us) and pop-in (we go to participants) sessions. I’m not sure if that approach will be required of all teams forever, but the possibility of that being true is a concern for us. Teams getting out into the world more to meet users where they are is a good thing, but it takes more time to organise and execute compared to online sessions, and the COVID-induced approach of doing all research online has been hard to shake.

For remote research, the big challenge is getting a native prototype onto a participant’s device, and then making it easy for them to share their screen back to the session. We need to investigate tools like Appetize – it looks promising, if also not quite what I am looking for. With everything going on right now in AI-assisted development, this feels like a market opportunity for some enterprising young person. (If you make this, please tell me!)

So yeah, lots to work out. One nice development is that the week before last I attended the first cross-gov mobile apps meet-up, organised by the HMRC app team. (Visit the #mobile-apps channel in cross-gov Slack if you want to get involved.) About 25 people from across government attended. After a few demos, we had a mini-workshop in which we discussed future topics for the meet-up, many of which mirror the questions we at the NHS App have been trying to work through. It’s nice to know we aren’t in this alone. Perhaps the answers we develop to the questioned listed above can help other teams across the sector. After all of the planning and negotiating, I’m rather appy indeed.