What is this series about again?
We’re talking about systems design for NPOs. Answering the question: How should we think about operational improvements in nonprofits, given that there are so many moving parts?
In the first post in the series, we explored three ways to consider, at a high level, what it takes to capture and assess data for impact measurement. We identified the biggest categories of moving parts, and how they inform each other. In later series, we’ll dissect some the details. In this series, I want to stay higher-level and talk about designing solutions in general.
To recap the first post: Nonprofits are like any other organization. They have a reason for existing, they want to know if they’re doing what they think they’re doing, and their operations are the activities that support the reason for existing. That’s all formalized in a logic model, and results in a nice structure from which to enter into the operational considerations of data capture, efficiency, assessment and improvement.
Introducing Two Friends: UX and Service Design
Now that we have a good grasp of the ecosystem and general needs we’re designing a system within, we can focus on how to create a project that has some potential for succeeding. For this post, I want to talk about the user experience (UX) design and service design worlds.
For a fun introduction to Service Design, check out Yosef Shuman’s “What Is Service Design?” video:
Operational improvements almost always require technology – to capture data, to enhance efficiency, to build reports. As I wrote long ago, technology is not the solution. And technologists – that is, the geeks who love electrons more than people – are the worst people to implement an operational improvement, but the ones who have to. What do we do?
We look to service design, UX, and human centered design to teach us how to bridge the gap. How to listen to people’s stories and needs so we can then use our technology expertise to construct a more optimal solution.
One of the most prominent ideas in software design is the Minimum Viable Product (MVP). The idea is that people need just enough to get their hands on, so they can suggest the features that are really necessary rather than what some geek somewhere thinks is useful.
It’s an idea that has revolutionized software design, and has reach well beyond – startups are encouraged to just ship or just launch, and the rapid-iteration pressure reaches the NPO sector too. The UX gurus over at Digital Telepathy think that the focus on functionality is incomplete, and I do too. A colleague brought this post to my attention (warning: the language in the title may offend you).
The thing that stood out like YEAH to me was their pyramid diagram:
Their pyramids are moving the reader through the standard software design stages, or parts of the software lifecycle. In the pyramid on the left, emotional design is left until last, with coders focusing on functional, then reliable, then usable.
The pyramid on the left is how everybody thinks of MVP, and it’s totally wrong. Functionality alone isn’t what matters. The pyramid on the right shows us that what matters is slicing across all sections of the lifecycle. Why? Because a functional product won’t get used if it’s unreliable – trust erodes. It won’t get used if it is hard to use – ain’t nobody got time for that. It won’t get used if nobody cares or sees a need for it.
If you want people to engage in your software, you have to engage them emotionally, find a real need, and focus on the slice of the world that can be made functional, reliable and usable. Even if it’s tiny, even if it’s just a button, that one button can transform someone’s workday if it always works as expected. A cross-cutting MVP can make more impact than a functionality-focused one.
Cross-cutting MVPs and NPO System Design (We’re up to 4 pyramids)
The next entry in this series will wrap us up. You can probably see where this is going – there’s a direct correlation between excellent MVP design and a nonprofit operational project’s chances for adoption.
We talked about what moving pieces exist in nonprofits in part 1, and we talked about a successful approach to other, similar design problems in this part. Obviously all that’s left, in part 3, is for the pyramids to align and unlock the secret knowledge, just like in all those bad sci-fi movies I might or might not have spent a lot of time watching.