Technology is Not the Solution

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.

Michelle:

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.

At his firm he’s built a very collaborative work environment, which is very unusual for that field. But as we started doing observations to understand the process around writing the documents, we started noticing other things about how his firm was running, and we brought those insights to him as well. One of the things we noticed had to do with the physical office space. Normally in a law firm you’d expect cubicles and private offices, but he wanted to foster collaboration across his team, and, inspired by Menlo’s open environment, his firm’s office was very open. Also, inspired by the pair work that is the norm at Menlo, his employees would partner on writing the documents. We had expected that a lot of a person’s time would be spent actively working with a partner — maybe not all or even most of the time, but at least half, we thought. However, when we actually observed what the pairs were doing, around 80% of the time was spent separately, heads-down, writing.

The writers had to make work-arounds in this open environment, in order to be able to focus for that 80% of their job.

Many of them had headphones, and one gentleman literally surrounded himself with plants, to create his own “green cubicle.” And when my partner and I were reflecting and debriefing in the office space, we felt like we had to whisper. I felt like you could speak louder in a library. So we went back to the client and said, you really need an open environment for that 20%, but the majority of your physical space should account for this 80% of their job. And he appreciated that insight, even though it wasn’t what we were ostensibly there for. So we’re always seizing opportunities for improving processes, and thinking about design work as more than “what’s a user going to do with this interface.”

Jeff:  

There is often a problem behind a problem, or a problem next to the problem.

Michelle:

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.

Mollie:

And not surprisingly, they usually think in terms of technology.

Jeff:  

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?

Mollie:

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.

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.

Jeff:

It’s sort of like teacher pay-for-performance in schools. 

Mollie:

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.

Michelle:

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.

Next: Why We Love Being Completely Wrong