Deliverables / Process and Methods

The Engineering Stakeholder Interview

Posted by

This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

Engineering stakeholders

Try to speak with engineering management as well as the design engineer(s), if such a role exists; it’s seldom a good idea to involve the entire engineering team at this point. If there are no design engineers, a system architect and GUI lead may be the best option for software expertise. When hardware is required, be sure to involve the electrical and mechanical engineering leads, as well as anyone responsible for manufacturing.

Programmers and engineers may initially be wary of designers. They may have worked with people who called themselves designers, but who proposed horrendously difficult solutions that seemed “cool.” Programmers may feel that designers are stepping on their toes, since some currently design screens themselves. You might also encounter mechanical engineers who view industrial designers as stylists rather than problem-solvers. However, any technical group’s reluctance to give up control over design is usually due to the fact that so far, they’ve been the most competent to do it. It sometimes takes a while, but once they see that good designers can actually do a better job than they can, most engineers are delighted to let go of the design.

The focus and length of engineering interviews differs quite a bit between a new product and a revision of an existing one; in the first case, there is more room for the design to drive the technology, while in the second, the capabilities of the existing technology, when combined with the project budget and timeline, may introduce significant design limitations.

However, don’t ask what you “can” and “can’t” do because in a healthy organization, that will be a business decision and not a technical one—although physics really does limit what you can do with hardware, there’s very little you can’t do with software given sufficient time and budget. Instead, ask what kinds of things would be hard to do and why.

Engineers also tend to relax more when you say you’re not trying to get them to commit to anything at this point, but simply to get a sense of what they already expect may be challenging. The following questions are helpful on most projects, though most projects call for additional, unique questions, too:

What technology decisions have already been made, and what’s driving them?

In the case of a new product, the technology decisions would ideally happen once the design started to take shape, but this is not always the case. When an existing product is being reworked, the technology train may have left the station a long time ago; the software development platform or perhaps several of the electrical components have already been identified. Even decisions that have already been made are sometimes unmade later, though, if the reasons are compelling enough.

For example, one client told us they had already sunk millions of dollars into a particular system as the basis of their development. However, our later research showed that users had needs this system simply couldn’t address. The company’s executives weren’t excited to see those millions go down the drain, but they were glad they’d learned about the issues before throwing away the additional millions they’d planned to spend.

How large is the engineering team assigned to the project, and what are their skills?

This is ideally determined by what the design requires, but in practice there may be a fixed number of people and days allotted to the work. As with technology decisions, though, designers often better serve the business by questioning such parameters than by accepting them. The most important thing to look for is a mismatch between the expectations for the product and the number and skills of the engineers. If you’re designing a big enterprise product and there are only two developers assigned, you’re going to run into trouble.

Likewise, if the software or hardware team has very limited skills, you may need to scale back your design ambitions, though it’s better to find a tactful way to encourage stakeholders to bring in the appropriate expertise if you can. Lack of skilled programmers was an enormous problem at the height of the dot-com boom, when companies hired anyone who’d taken an HTML class and called them software developers; this seems to be less of a problem during “bust” cycles but is likely to crop up any time there is a shortage of talent. I’ve seen similar issues in organizations where mechanical engineers are only accustomed to doing plastic casings and not designing moving parts.

You may wonder how a designer can assess the skills of an engineer. In truth, most designers can’t. However, if you have enough experience working with skilled people and less-skilled people, you’ll learn that certain attitudes and behaviors tend to indicate skill level. If you hear engineers saying that something is impossibly hard when half of your last ten project teams were able to build it, you might start to wonder.

It’s also a bad sign when programmers are anxious about designs they can’t assemble from off-the-shelf libraries; it could mean the timelines are ridiculously short or they’ve seen truly absurd solutions proposed, but sometimes it means they simply don’t know how to build it. The most skilled programmers and engineers get excited about technical challenges, as long as the challenge is there for a good reason and the timeline is reasonably sane.

Could you draw a diagram and tell me in lay terms how the existing system works?

Sometimes this is important information; sometimes it isn’t. You probably won’t know until later whether you need it. Certain system limitations, such as client-side data that’s not always synchronized or response times that are very slow, can make interaction design more challenging. The same is true of hardware systems; if it won’t be possible to change certain kinds of boards or other components, you may not have much room to change the form factor. Just be sure to take this information as food for thought, rather than as something carved in stone.

Note that there’s a reason to ask for an explanation in both visual and lay terms, as shown in Figure 5.2, even if you think you’re well versed in techno-speak—it encourages clarity, and can be another indication of an engineer’s skill level.

Figure 5.2 Example of an engineer’s system diagram.
Figure 5.2 Example of an engineer’s system diagram.

See also:

Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.

About Kim Goodwin

Kim Goodwin is the author of the bestselling book, Designing for the Digital Age. Kim is currently consulting for clients in varied industries including aviation, consumer electronics, and retail. She spent most of the last decade as Vice-President, Design and General Manager at Cooper, leading an integrated practice of interaction, visual, and industrial designers and the development of the acclaimed Cooper U design curriculum. Kim has led projects involving a tremendous range of design problems, including web sites, complex analytical and enterprise applications, phones, medical devices, services, and even organizations. Her clients and employers have included everything from one-man startups to the world’s largest companies, as well as universities and government agencies. This range of experience and a passion for teaching have led to Kim’s popularity as an author and as a speaker at conferences and companies around the world.