We often have a natural tendency to solve problems with systems. Systems don’t necessarily mean computer systems, in case you wonder, but refer to any and all organized, structured solutions, like a program, an app, a formal document, or a procedure.
This systems tendency in itself is not wrong, as many problems can indeed be solved with a good structure or process. But there are two questions you need to ask before designing and implementing any system—and that’s a step many people forget.
Question 1: Is the New System Disruptive?
Any system you have needs to accommodate patterns people already have. If it disrupts, your chances of them adopting and fully embracing the system are way smaller. Systems need to fit into processes people already have.
Certain apps do very well in this area. Take the MilesIQ app I reviewed recently, which is an app that tracks your drives so you can classify them for tax purposes. This app thrives on the fact that most people have their phones with them anyways when they drive. Since the app is always ‘on’ (unless you change that setting), it automatically detects when you’re driving. There’s no disruption in your process of leaving; you don’t need to add an extra step of reminding yourself to turn on the app for instance.
If the system you have designed requires people to change their routines, you’ll have a way smaller success rate. The best systems fit into existing processes and patterns.
Question 2: Does it Solve the Problem Completely?
This seems like such a given. Right? The reality is that many systems fail at this. They solve part of the problem, but not everything. Or they do indeed eliminate the original issue, only to complicate something else.
One example of this is the law to wear a bike helmet. The intentions were good, obviously, as helmets are known to prevent severe head injuries when biking (I’m talking about bicycles here by the way, not motorcycles). The unintended consequence however, was that wherever this law went into effect, many people stopped riding a bike because they did not want to look ridiculous with a helmet on, or have ‘helmet hair’ when they took it off.
But it can be subtler than that. I volunteer with a national youth organization and was recently introduced to a piece of software they have. The problem this software is supposed to solve is keeping all the volunteers up to date on personal conversations other have had with certain youth. So if I talk to Ricky and he shares something personal, I put a short note in the system for the other volunteers so they know what’s going on in his life.
The first problem of course is that this is disruptive. I now need to remember to log into the system every time I’ve had a personal convo with one of the teens and make a note. That will take some getting used to. Worse, I also need to remember to log on regularly to read other people’s notes.
But here’s the real problem: the system did not have the option of seeing which notes were updated. There was no way for us as volunteers to know if one of the others had updated a note. Not unless you wanted to email the entire note to everyone who had access—which was not an option considering how private some of these conversations are. The system is secure, our email is not.
The idea was that this software would solve a problem: keeping is updated on our teens. The reality was that it didn’t, since I would have to manually check every teen’s note to see if it was updated. Or we’d have to remember to manually email all the other volunteers with a message like ‘I just updated Ricky’s file’.
Clearly, this software is never going to be used until they solve this issue (and a few more, because overall it’s not very user-friendly). And that’s a shame, because our volunteers want to solve the problem of not knowing what’s happening in our teens’ lives. The supposed solution however is too disruptive and too complicated to solve anything.
The moral of this story? Before designing or releasing any system, whether it’s an app or a formal process or anything else, ask yourself these two questions:
- Is it disruptive?
- Does it solve the problem completely?
The answers may not always be easy to find. It may mean running some tests and asking for feedback. But skipping this step may result in an expensive system no one will use.
I’d love to hear some more examples of systems that failed because they were disruptive or didn’t solve the problem completely!
[Image via Pexels cc]
Eric Dye says
GREAT questions!