Design Thinking vs. Experts

At zu, we use Design Thinking in the process of building digital products and services. This ensures what we produce will be well-received, appreciated, and easily adopted.

In observing things in my daily life, however, I see many examples of brand new things failing to meet the needs of users. Though designed by experts on the specifications of senior decision makers, these innovations, nevertheless, fail for intended users such as employees.

Learn from your users.

I was recently giving blood at the new donation centre in our city, which replaces a more densely organized operation downtown. Located in a strip mall, the new facility has ample parking and an attractive, sweeping interior design. From a glance, it appeared to be an improved set up.

I asked the nurse jabbing me, “Were you in the old place? Is this a lot better?”. She proceeded to point out deficiencies such as: the curved shape creating wasted space and awkward placement of necessary equipment, loss of storage areas, smaller staff lockers that are expected to be shared (doubly impractical with winter clothing), the staff bathroom not accessible via the locker room, and so on. “Did the designers have any sessions with you frontline folks?” “No,” she replied, “only with the supervisor”.

Despite the modern, architect-portfolio-enhancing design, there were major issues inadvertently introduced by a lack of engagement with users. These deficiencies may impact the clinic’s operational efficiency, employee engagement, and overall job satisfaction. A decrease in the general enthusiasm of staff may, in turn, impact the donor experience. Had the frontline folk been engaged via a process like Design Thinking, the same space and budget could have easily accommodated their suggestions.

In zu’s own building renovations, Toronto-based engineers designed our HVAC system. Local installers after-the-fact pointed out the system had many practical issues including outdated equipment choices. This has led to costly issues. Even a brief engagement with the stakeholders of the system – in this case, those who would be maintaining it – would have provided useful and cost-saving insights that improved the experience for the end-user: zu.

So, what can we learn?

So what do these observations tell us? Whenever you are building anything intended to meet the needs of a user other than yourself, you are going to get it wrong, by a little or a lot, if you don’t engage users in the design process.

This is a Fallacy of Assumed Competency. Folks in charge of the budgets and plans tend to rely too much on their own smarts, and on the wisdom of hired experts. They choose to exclude the messiness and time commitment involved in organizing engagement with users and stakeholders.

While expert involvement was totally necessary in these examples, the successes achieved were incomplete. They both missed an engagement step, which would have uncovered what users actually wanted. It’ll always be a partial win when management expects employees to be happy with what has been created for them. (Imagine the result of decorating your teenage daughter’s bedroom without involving her).

Many projects, devices, and software systems can be produced to do similar things for a similar price point. The “best” one, ultimately, is the one that users prefer. With Design Thinking, we start by going through “all the trouble” of uncovering what users want. We offer expertise to understand limitations and necessary interactions. With users, we go through multiple rounds of design ideation. We create prototypes. Then it’s back to the users for prototype testing and then more testing during development. In early stages, we are weighting opinion and resulting direction about 2/3 users, and about 1/3 experts. (It occurs to me this might just be a really, really long way of saying: Measure Twice, Cut Once.)

Experts are necessary in almost every undertaking, but they are not where projects should start or finish. The old approach will miss key insights. The assumptions of the boss/expert-only team will introduce risks, costly do-overs, increased training requirements, and require longer roll-out periods. High expectations will be replaced with employee disappointment. Projects will achieve only partial success – or worse – when decision makers plan, design, and innovate without involving actual users.