This is the sixth in a series of blog posts sharing our study results on the business value of experience design. Read the last post here. This post explores the value of understanding both the limitations and the possibilities of the underlying technologies to drive an optimal product experience.
MC Escher was a Dutch artist famous for creating imaginative but physically impossible scenes. You probably recognize his endlessly looping staircases, convoluted floors and ceilings, birds morphing into fish, and other complicated scenes. They are amazing but impossible to create in the real world. In the same way, imaginative and creative experience designs that can’t be feasibly implemented – either because they don’t fit the timeline and budget or just aren’t technically possible – are equally destined to remain artwork.
Too often, requirements, designs, budgets, and deadlines are set before engineering can figure out possible. Compromises are made. Dates are missed. Budgets evaporate. Resumes are updated. An exciting pitch deck, complete with a beautiful product comp and clickable prototype, will set high expectations even in an agile world. In our experience, the best digital experiences come from a partnership between the design team and the engineering team.
History is filled with great design and engineering partnerships. Bell and Watson. Jobs and Wozniak. Jesse and Heisenberg. The yin and yang of design and engineering is a complex relationship that is fascinating yet elusive. One thing for sure: it doesn’t happen by accident. The design and engineering partnership is a deliberate decision to bring the right people, process, and technologies together.
If you’ve been reading this series, you’ve probably noticed that we ask many designers. We ask them to develop customer empathy. We ask them to understand human behavior. We ask them to be innovative and creative. And now we’re asking them to understand the technology they are working with. The modest ask is that the design team build basic fluency with the platforms, environments, and even the type of content and data available to the product team. This may require some onboarding and structured education, but the goal is to develop a general sense of what is possible and where the design might be pushing the envelope.
Another element of a design and engineering partnership is the practice of a shared process and methodology. Communication and trust breakdowns often emerge from disconnected roles and responsibilities, expectations, and handoffs that can be avoided by taking the time to blend various approaches and experiences that designers and engineers bring to the combined team. In the urgency to get projects off the ground, this critical step is often missed but is well worth the time. Fortunately, methodologies like Design Thinking and Scaled Agile have sorted out many of these disconnects and are a great starting point for a deliberate partnership.
Finally, in addition to defining what is possible to accomplish, the technology will influence how flexible the design approach can be. In the early days of monolithic computing, your experience options were limited to a few shades of green screen. Client/server, model/view/controller, progressive web apps, and all sorts of advances have accommodated much more de-coupled architectures that allow for much more flexibility in the possible experiences. A shopping cart can be a complex web page or a single pixel in a digital ad. Add in the promise of low-code and no-code platforms like Appian and Square, and all that your project might be left with is design.
The value of a design and engineering partnership is directly evident in better products and faster projects. Hopefully, your experience is also resulting in updated resumes – but for all the right reasons.
