Natalie Hanson Filling the Void
Filling the Void
Dan Willis, Consultant, U.S. Digital Service
From the Design Operations Summit website:
When we talk about DesignOps, the focus is frequently on scaling existing design systems and supporting established design teams. But the U.S. Digital Service’s Dan Willis will tell a different kind of story about a federal agency that used DesignOps practices to address a multi-million-dollar business problem. With years of system-centric development, the agency had accidentally opened a giant void between the functionality of their enterprise software and the people who depended on that functionality to do their jobs. This talk will explore how to introduce and maintain design operations even where none have existed before.
Different situations require different implementations of Design Operations. It’s pretty rare to build from scratch; a more typical situation is that you start by doing good work, and then start to introduce DesignOps concepts. A more troublesome situation is wedging DesignOps into development. But what about really, really difficult situations like where no intentional design procesess have existed before? That is the story he is goign to share today. They had to fix their development processes before design / design operations could be successfully introduced.
The UK did digital services before before the U.S. did; here is was Obamacare that drove the changes. That resulted in the U.S. Digital Service (USDS). There are all kinds of rules for contractors, which don’t apply because they are employees, and they don’t report into the agencies they serve. That gives them a lot of flexibility to work differently than other government employees. USDS only involves them when things are really messed up. This agency had accidentally created a gaping void between functionality and the people who needed it to do their jobs.
They were transforming a decades old paper system into digital, which was phenomenally complex. They had had many vendors, business analysts, but there had been no UX involvement. The project had a long history of big mistakes – one example was spending $800M to launch a single form (which was later de-activated!).
Things die in black holes. User needs died in that void early on, as did UX designs (except the most superficial ways). They tried pattern libraries, but those died too – mostly because of the way the developer contracts were scheduled; everything was about story points completion, so they were not willing to adopt it.
How do you spot a black hole? Through indirect feedback – technology issues were actually misdirected UX issues. Tough to get to end-users. But if there was any doubt about the void, there was outright open revolt. The end-users stopped development for an entire year – unprecedented in the government space, but it opened the way for really different approaches.
There are opportunities in chaos. They wanted to introduce an end-user centered product development system.
Lesson 1: Lower your Expectations. Their recommendation was not the best possbile outcome, but it was the best they could make happen. Better to have an average idea that was implemnted than an ideal solution that can’t be implemented. They came with a good start, knowing it would have to change over time. The plan also had to be resilient. It took about a year, with stakeholders coming and going, with support ebbs and flows. The solution was complex BUT easy to explain.
Lesson 2: Think Outside the Void. If you look at the void you will only come up with a partial solution. We had to understand sub-systems and how they interact – that was the only way to get lasting.
Lesson 3: Look both Forward and Back. There was no do-over. So, every time they talked about functionality, they had to connect old and new.
Lesson 4: Build Space for Survival. Created a safe space with role definitions and more so new designers didn’t fall into the void.
Lesson 5: Leverage Everything (except the toxic stuff): They were doing Agile, kanban, and related artifacts. So they kept that. But they were using SMEs instead of users – adn there they put their foot down.
Lesson 6: Make the User Unavoidable. They did this by creating a System Must, SYstem Shall stuff, and defined everyting from the users’ perspective. Impossible to treat the user as a nice to have.
Lesson 7: Identify the Tipping Point. Look for signs that they have gotten past that point, and then you can let up.
On this project, he thought they had passed the tipping point. Two months later they shut the project down (after a four month pilot). In retrospect, he doesn’t think it was a failure. Using Blockbuster as an analogy, you went to pick our VHS and later DVDs. It felt like the endpoint of entertainment. Now he realizes that binge-watching on Netflix may not be the endpoint either.
He has taking that perspective on the USDS. This is an interesting field – it’s called civic tech. Like Enterprise UX, but there is time – change in U.S. democracy happens in decades, or even centuries. How does what you are doing relate to that final solution? That organization’s language changed about users and design, and the designers kept churning stuff out. Whenever you’re doing something this ambitious, if you take them through it they can’t unsee it, so that is the beginning of a change journey.
Natalie Hanson 
Pingback: Design Ops 2018 – Recap | Natalie Hanson