Shorthand Design, Engineering, and Support

Written on August 07, 2020
Updated on August 14, 2020

I’ve recently been thinking a lot about the relationship of Design, Engineering, and Support. While they aren’t the only three elements of products creating and development, I consider the three most important pillars of how of a product lives and eventually retires.

I want to focus on what each of these elements require on a fundamental level to get a product vision implemented and launched successfully. No product is perfect, but it’s important to call out a basic element of each discipline that helps create something successful.

Let’s start with Design.

Design Requires Anchorage

At square one in the creation process, design has this beautiful freedom from constraint. Anything is possible. Yet, there’s a point where something is going to eventually anchor things in a “reality”.

Maybe this anchor is a budget or platform constraint. Maybe is a series of deadlines. No matter what the makeup is, anchors help bottle up the creative freedom of the design process into something potent and deliverable.

In my experience, having a potent and (mostly) complete design package has been a defining attribute of timely, stable, and successful products. It doesn’t leave much room for Engineers to have to interpret their own spin on things. Rather, it gives clear-cut spaces and borders for Engineering work to happen within. Any additional work can then be filtered back into the design team for further work.

I don’t believe there needs to be a hard rule that says: “No Engineering can happen before Design”. However, Engineering work has a tendency to snowball ahead of the Design process. If Design doesn’t get a head start early - or have a definitive voice in the overall process - Engineers can find themselves making design decisions on their own. If deadlines are tight enough, these changes can make it into product and cause inconsistent user experiences.

Given this, I think its wise to look a Design and Engineering a four step cycle:

  1. Engineer to prove that something can be done.
  2. Design to fold that idea into a consistent user experience.
  3. Engineer to fill out the technical borders of the design
  4. Ask if the design matches the purpose of the engineering product

This ensures that there are checks with how Design and Engineering fit together. It also empowers each element to do what it does best. Its not asking Engineers to be Designers - or vice-versa.

Going along this trend, let’s talk about a bit more how it relates to Engineering.

Engineering Requires Boundaries

Engineering works best when there are boundaries.

There’s a tendency in Engineering to attempt to design for the future. Instead of going back and ripping up stuff for an eventual need, why not implement a hidden base layer for later?

The intentions here are good, but the technical debt burden it creates can be quite harmful to the moment of a product’s development.

Having boundaries in what to implement and where to stop is crucial to delivering a feature or milestone now, but also crucial to the speed at which you can do that at a later stage.

So much time and effort is spent backtracking through product development because we didn’t establish clear boundaries at the start of creating something. We often think of things in too big of terms when pushing for something.

As we explored earlier, design can help with these boundaries. It’s important to note that a lot of the other boundary work comes from good management. There’s not a design spec for every bit of a technical work required on a project. When a management team has a great grip of where a set of work starts and ends, they can help cut down on a significant amount of scope creep and cruft on a product.

Again, this isn’t only a choice that pays out in the present. Long lasting products are also the easiest to maintain. So many rewrites occur simply because the underlying implementation is hard to maintain and develop against.

There’s another important element beyond the present and future of Engineering, though. That’s why I want to explore the idea of Supporting a product as well.

Support Requires Endurance

Finally, we have Support. The marathoners of Engineering.

Support requires continuous endurance of empathy and confidence in a product. It ultimately is the best way to funnel feedback into Engineering and Design around what’s going on with a product. If neither listen to what Support folks are walking through with customers, a product’s relevance and focus will quickly fade.

It’s really easy to look at support as _only_a means of satisfying customers or end users. However, you can only tell people what they want to hear for a short period of time before they expect a product to change or get better. Yet, when you leverage Support as a means of Engineering of product, its life can be extended greatly.

This is largely due to the idea that Support folks are seeing where the greatest disconnect or dissatisfaction with a product lies. An Engineering backlog could have 50 active tasks, but Support can help address and prioritize the customer pain-level of each of those. In essence, Support feedback and findings act as refinement for Engineering’s future priorities and goals.

We're Currently Not Fielding Conversation Around This Post Right Now

Check back later if you're interested in contributing to the conversation.

You can always tweet at @hiimtaylorjones if you're really got something burning to say!