Q&A

Q&A with Billy Hollis: Getting Started with Design Thinking for Developers and Managers

• By David Ramel
• 01/27/2023

Many developers believe "design" is synonymous with "visual design." But there are many different ways that design and design thinking can help teams produce more valuable applications, and visual design is only one of them.

Billy Hollis, a noted speaker and author who is firmly grounded in both the development and design camps, will explain all those different ways in an upcoming presentation at the Visual Studio Live! in-person event being held in Las Vegas March 19-24. Hollis will impart his knowledge in a 75-minute presentation titled Getting Started with Design Thinking: A Guide for Developers and Managers.

In addition to fleshing out the various levels of design effort, Hollis will share with attendees tips on applying design thinking to their own projects, from basic do's and don'ts all the way through facilitating organization-spanning innovation. What's more, resources and guidelines will be supplied to learn the various components of design thinking, including design principles, selecting a process for design suited to your level of design effort, listening and facilitation to avoid design roadblocks, and techniques for dealing with inertia when trying to apply design innovation.

To learn more about Hollis' thinking, we caught up with the Nashville-based "agent provocateur" to learn more in a short Q&A:

VisualStudioMagazine: What are a few basic do's and don'ts when applying design thinking to projects?

Hollis: First, the team must believe that a design thinking approach is needed, and have confidence that it will result in more valuable apps and more productive and satisfied users. Status Quo Bias almost guarantees that there will be pushback from some of their stakeholders. Innovation can be extraordinarily valuable, but the more innovative a project becomes, the more disruptive it can be. If the team doesn't really believe design thinking and innovation are well worth the effort, it's hard to push through to success against the resistance they will see.

Second, if the team does not have much experience in injecting design thinking into their projects, for larger projects such as replacing an entire legacy app, they should turn to outside expertise. That's particularly important for facilitation and leadership of the various groups involved in the project. I've seen too many design projects flounder because the team lacked someone to drive it to necessary decisions. The team starts to thrash over decisions because of differing opinions, or because no one wants to offend a strong-willed manager. Progress stops, sometimes for months.

It's fine for developers with limited experience with design to try their hand at designing small isolated parts to improve a legacy app, either alone or in a small group. But larger-scale projects have too much risk for developers and managers to be learning design skills as they go.

Finally, if the organization's leadership hasn't bought in to the need for innovation driven by design thinking -- and prepared for the investment required -- success is very uncertain. Getting leadership on board with design thinking sometimes takes years. Gaining some small design successes is often necessary before taking on the more disruptive, innovative efforts.

How have you come up with your techniques for dealing with inertia when trying to apply design innovation?

The more a team tries to innovate, the harder it will be to overcome inertia. To lessen the problem, start with lots of listening. Users and stakeholders will offer a lot less resistance if they believe the design team is genuinely interested in making things better for them.

The team should also foster an approach that is iterative and geared to experimentation. Coming up with new ideas is addictive. Anyone involved in the design process that sees one of their ideas taken seriously, and improved and refined by others on the team, develops a psychological stake in the project's success. They come to realize that their objections based on their familiarity and comfort with the old system can be overcome.

This is another place where high-quality facilitation is critical. Everyone involved should feel that they've been listened to, and had a chance to make their case for their design ideas and preferences. If they don't, they feel marginalized, and are more likely to exhibit inertia by pushing back on new ideas.

Regarding the traditional developer/designer divide, are the two camps working together better lately?

Developers today better understand the importance of design, and mature designers who take a strong design thinking approach appreciate what developers bring to the table, especially their domain expertise. So the situation is considerably better than it was five or 10 years ago.

More visual, intuitive types of designers do still sometimes struggle working with developers; they expect developers to just accept their intuitive conclusions. But developers in general don't go for touchy-feely intuitive design. They want more logical reasons for design choices. Besides, true design thinking goes beyond intuition, leveraging measurement and analysis too.

It's therefore generally a bad idea for a more intuitive, visually oriented designer to lead a design team containing developers. While those designers are valuable members of a design thinking team, their disconnect with developers and their bias towards intuition over analysis means they should not be running the show.

Why has "design" become synonymous with "visual design" and how does the latter fit in?

Visual designers have a vested interest in fostering that impression. Some developers are happy to go along with it because it gives them an excuse to delegate any responsibilities concerning design.

It's also a simple and tangible concept for managers to get their heads around. The visual nature is something they can see immediately. More sophisticated forms of design take more effort to understand.

Visual design is important. No one wants to use an ugly app or web site, and good visual design helps increase app acceptance and overcome inertia by creating a good first impression. But visual design is a small fraction of the design projects we do.

One of the main education responsibilities of the design community is to communicate the different levels of design effort, particularly to help decision-makers understand the possibilities for leveraging design (see graphic below).

Interaction design (folding in how the user navigates and flows through an app) is a level that goes beyond visual design, and that phrase has gained some traction. The phrase "design thinking" has done even better, though it suffers from considerable variation in its definition by different community members.

What is involved with selecting a process for design suited to an individual's level of design effort?

A design process varies the most based on scale of the changes being made. Redesigning isolated parts of a legacy app can be informal and take a few hours or days. It can be done by individuals or small groups with a minimal process that mostly involves observing and listening to users, some sketching to generate design ideas, and an evaluation phase that seeks feedback.

At the other end of the scale, design thinking that reimagines workflows across an organization needs to have a lot more structure and can take months. Business needs must be clearly understood. Innovation should be a built-in part of the process.

Every team needs to seek the right balance in their process. To get ideas of what to incorporate, I have a white paper on the general structure of a typical design process, and the book "101 Design Methods" can provide additional ideas.

What are some key concerns of developers who attend your presentations on design thinking?

The No. 1 concern I see is stick-in-the-mud managers and executives who are stuck in a previous generation of thinking. My session specifically talks about dealing with that problem. However, I can't promise universal solutions. There are some stubborn and risk-averse managers out there.

Another common issue is what I call the Flamingo Fallacy. Some developers have this idea that design can only be done by special, colorful creatures, and that developers are too dull and unimaginative to do design. Not true. Almost everyone has latent stores of creativity that allow them to do design, especially as part of a team with a facilitator to lead them through it.

What are the main factors holding back adoption of design thinking by more teams?

By far the No. 1 reason decision makers don't get enthusiastic about design is that they have no idea how much money they're leaving on the table. Part of my session explores how to estimate how much money design can save and generate. it's not uncommon to see 100x returns from design thinking focused on innovation.

The lack of mature design expertise is also a constraint. We have plenty of visual designers, but more advanced design skills, particularly design facilitation, are in short supply. And, as always when demand outstrips supply, hucksters rush in to fill the gap. Decision-makers are justifiably skeptical of grandiose claims about design. They worry that they're just wasting their money, and software development is already too expensive.

This lack of expertise will get better, but it will take time. I'm starting to see design degree programs push design instruction beyond traditional, intuitive design into comprehensive design thinking.