This is Part 3 of a Design Story from Mollie Callahan and Michelle Pomorski. You can start with Part 1 here.
Technology is Not the Solution
Despite working for a software company, Michelle maintains that technology itself is almost never the answer to a client’s problems. Careful observation can reveal the problem behind the problem — and it’s usually a process that is the key.
Oftentimes, especially in the software industry, it’s assumed that technology is the solution, but it never is, on its own. It’s really about the idea that design is more than just an interface of some sort, or even an experience — rather, a huge part may be designing a process. I’m thinking about one of the clients we’ve worked with recently, an attorney who came to us wanting us to design a way to automate a certain kind of legal document writing. We have a good relationship with this attorney — he’s come to several of Menlo’s tours and classes, and he’s taken a lot of Menlo’s approaches and adapted them for his own firm. Design is more than just an interface.
Design is more than just an interface.
The writers had to make work-arounds in this open environment, in order to be able to focus for that 80% of their job. One gentleman literally surrounded himself with plants, to create his own “green cubicle.”
One gentleman literally surrounded himself with plants, to create his own “green cubicle.”
There is often a problem behind a problem, or a problem next to the problem. Human nature is to think in terms of solutions.
Human nature is to think in terms of solutions.
Human nature, too, is to think in terms of solutions. So when a client comes to us with a solution, we always have to take it with a grain of salt. Because sometimes they haven’t even dug down to the root of the problem, and they’re just thinking about what will help ease this immediate pain that they’re experiencing or seize this opportunity that they’ve identified.
And not surprisingly, they usually think in terms of technology.
It sounds like clients often come to you with a preconceived idea about a solution, and then you tell them that it might not actually be the solution. Have there been times when that has not gone well?
We’ve had several recent experiences where we’ve had to deliver hard feedback, to the point where we’ve been a little bit scared to deliver it, but we’ve gone in and been very vulnerable and honest, because we had the data to back it up, and we truly believe that we’re delivering value. Whatever it is they think the solution is, our job is to deliver value. In most of these cases, clients have come back and not only said they appreciate it, even if it’s a simple insight, but they’ve actually told us, “That is why we continue to work with you.” Because if we simply followed through on what they thought they needed, we’d just execute it without really understanding the problem. If we simply followed through on what they thought they needed, we’d just execute it without really understanding the problem.
If we simply followed through on what they thought they needed, we’d just execute it without really understanding the problem.
In my early days at Menlo, there was a company that came to us saying, “We really need our sales force to be sharing sales leads across departments, and we need a new CRM [customer relationship management] system to facilitate that.”
However, our team went in and very quickly realized that the problem was caused in part by the reward system that they had set up. People and departments were being rewarded individually for their sales, and there was no way they were going to share this information so that some other department could get rewarded instead of them. It kind of mirrors the education system.
It’s sort of like teacher pay-for-performance in schools. You can’t just design different screens and expect people to behave differently.
You can’t just design different screens and expect people to behave differently.
Exactly. That was, as you can imagine, a very hard story to tell. And we basically worked ourselves out of the software part of that engagement by saying, “Any sort of technological solution isn’t going to help until you’ve solved this other problem.” Ultimately I think they were very grateful for not making that mistake, but it was nonetheless a hard conversation to have.
People often say “we want you to design us a software solution” as a way of trying to create change within their organization. But software can’t be a solution on its own. You can’t just design different screens and expect people to behave differently.