Principles of User-Centered Design: Bridging the Gap from Expectation to Reality

Principles of User-Centered Design: Bridging the Gap from Expectation to Reality

There’s a gap that often exists in product development. A disconnect between the expectations of marketing and the realities of engineering and manufacturing a product that works. Marketing expectations, informed by voice of customer and business goals, are often developed into concepts or solutions that do not fully consider feasibility or cost. Product solutions developed by engineering may not fully or accurately consider the needs of end users or the importance of the brand and experience.

This gap results in challenges on both sides. Marketing might be sold on a concept that ticks the boxes of user experience, while engineering is tasked with executing an immovable design intent that simply is not feasible, and could never hit their aggressive cost and schedule targets.

There’s incredible value in closing this gap—value that’s realized in quicker development time, lower costs and greater chances of success in the market. The question is, how?

User-Centered Design (UCD) sits at the crossroads of the human experience and technology, and is perfectly positioned to bridge this gap as part of a cross-functional team that includes marketing and engineering.

UCD is the ideal conduit between expectations and reality —providing the language and the framework to translate user experience needs into engineering requirements, and technical needs into elegant, manufacturable design solutions.

In the product development process, there are three fundamental questions that need to be answered before beginning commercialization:

You might guess that the best place to start is with why , and you’d be right. But the problem is, we often jump too early to the third question: “HOW should we make it?” It’s understandable why we do this—the question of “how” is easier to approach, almost binary in comparison to the “why” and the “what.”

However, if we haven’t answered the first two questions, answering the “how” becomes increasingly difficult and frustrating for your engineers, who often can’t make progress until we go back and answer the fundamental product requirements.

The “how” relies on the “what,” and the “what” relies on the “why.”

Let’s unpack this with an illustration.

At Plexus, we’ve often illustrated this concept with the process of making sandwiches. No one starts the process of sandwich-making by asking, “How thick should I cut the tomatoes?” (But if you do, what follows might help improve your sandwiches, too.)

In the fine art of sandwich-making, you have to start at the beginning. What if you’d decided that the solution for your hunger was to have an ice cream sundae? In this case, (we hope) tomatoes wouldn’t even be in the picture.

The same is true in product design and development . Companies might spend a great deal of time and energy deciding between tomato types, when instead they should be thinking about which toppings to put on a sundae. In practical terms, device developers will often spend significant resources trying to integrate a specific technology into the product, only to find as they get further down the road that it was never the right piece of technology to integrate .

The specifics vary from organization to organization, but generally the teams that answer the questions of “why” and “what” (marketing, product development and industrial design-only firms) are different from the team answering the “how” (engineering). Somewhere between “what” and “how” there’s a transition from one team to the next.

If you have the good fortune to be part of or partner with a well-integrated, cross-functional team , you can end up with a product that delivers on the early, visionary user experience the product team was aiming for.

What we see too often, however, is a disconnect that happens during this transition that can have detrimental impact on the product solution in the end. This is where teams often find themselves in the uncanny valley of a product that resembles the vision, but ultimately falls short of delivering on it.

Multiple factors contribute to this gap, including differences in values, objectives, skill sets—even the culture and language of the different teams involved.

Answering why and what takes a different set of skills, approach and mindset than what’s needed to figure out how to make something.

Though achieving the end solution requires a cross-functional effort, the former involves more of the emotional human element and the latter scientific principles and process. Along with this, you’ll find differences in culture, language and understanding across teams, which creates a need for clarity, alignment and empathy.

Empathy in this case goes both ways:

Without empathy-building in both directions, you end up with a gap between the vision creation and the product creation .

That’s exactly the spot where UCD provides a meaningful bridge. UCD reaches back into the world of marketing and design, as well as forward into the world of engineering, translating the needs of both to fulfill the vision of each.

We’ve said that UCD is the conduit between the two disciplines of marketing and engineering. UCD is uniquely positioned to be this conduit because it essentially speaks both languages. A great UCD team can translate one for the other—understanding the needs of marketing and the requirements of engineering, and bringing them both together into a meaningful, usable, manufacturable product .

When you apply the principles of user-centered design, there are three key benefits that allow it to fill this role.

This is really the main point we’ve been making all along. But it goes deeper than bridging a gap between two stages of development. User-centered design can actively bring these two critical teams together to help synthesize the strengths of each into a cohesive process that yields a stronger result . Three ways that can happen:

UCD is about innovation , and can ensure that design and engineering stakeholders are aiming at the same tangible result.

One of the key principles of user-centered design is to design from the outside in. Design the desired workflow and interactions first, then design the product solution that will deliver that experience. One way we do this at Plexus is the use of archetypes to test workflows.

Archetypes are high-level concepts that consist of a loosely constructed architecture of components and their corresponding touchpoints, put together as a very low-fidelity mock-up. The sole purpose of archetypes is to demonstrate and test a workflow. Archetypes can take a variety of formats, but what’s most important is that they’re purposefully void of detail, aside from the key touchpoints that the user would interact with. This means we can efficiently and broadly explore how the configuration and implementation of proposed technologies will change the user experience—for better or worse. This allows your team to think through and define a desired use case, understanding what’s feasible and what isn’t, before exploring possible product solutions.

We sometimes refer to this as “archetype-level thinking”—a mentality that focuses on answering the fundamental “what” question so you can approach the “how” armed with better information and a clearer direction for solution concepts from the start. As a team, if you’re able to define a desired use case prior to exploring more defined product solutions, you’ll gain efficiencies, reduce risk and set your designers up for success because of the focus you’re providing.

With all we’ve said about bridging the gap between vision and reality, we want to be sure it doesn’t sound like “blue sky” thinking has no place. What user-centered design provides is the right balance of blue sky thinking, but not so blue sky that the product you envision can’t actually be created. There’s plenty of room for “wouldn’t it be cool if …” and there’s also deep understanding of what pulling it off would actually take.

At the same time, balance doesn’t necessarily mean compromise. User-centered design doesn’t compromise on the design intent in regard to meeting a user need. By staying involved through Design for Manufacturing, UCD can ensure that teams stay true to the underlying principle of the user need and experience. Even if a proposed solution turns out not to be feasible, the UCD team can go back to that underlying principle and propose refined solutions that benefit from what is now a deeper technical understanding. This is how you preserve the through line from the user needs and desired experience to the finished product that delivers on the vision.

To wrap all three of these benefits together, employing the principles of user-centered design allows a team to conceptualize early on, understand users and their needs, then shepherd that experience through the entire product development process. What might start as an “aha moment” and a very story-driven intent becomes engineering specifications and product requirements that can be executed by engineering and delivered for manufacturing.

There is a gap that exists between marketing expectations and the realities of engineering a product for production. But there’s a bridge for that gap: user-centered design. UCD lives between the disciplines of marketing and engineering to explore use cases and needs while constraining themselves in a meaningful (but not limiting) way with the cross-functional support of systems engineering.

All of it adds up to better products that deliver better experiences and are designed to be manufactured.

Our own UCD team takes pride in filling that critical need within the product development process. We’ve helped our customers bring elegant, commercially viable product designs through to production—and we’d love to discuss how we can support your next product innovation, too.

Recommended articles