Shorthand Design, Engineering, and Support

Written on August 07, 2020

I’ve been spending some time recently thinking about the relationship of Design, Engineering, and Support. They’re what I consider three crucial elements of how a product is created and lasts. Yet, each of these elements have essential requirements to them.

Design Requires

Let’s talk about Design first.

Design requires a freedom from constraint, but needs to be rooted in reality. When you’re creating engineering products, new features and ideas need to contribute to the overall narrative on what’s going on in a product suite overall.

Engineering can come before design, but at some point the engineering idea has to yield to the design. I’ve unfortunately worked with my fair share of situations where folks have told me to ship a feature of engineering and then watching a designer be told to create something to fit it.

This brings three rules to mind here:

  1. Engineer to prove that something can be done.
  2. Design to fold that idea into an experience.
  3. Ask if the design matches the purpose of the engineering product

Technical users like options and configuration. General consumers tend to enjoy usability. It often feels like we’re designing for one or the other. In reality, you’ll see a good mix of both using your product. No matter what side of this spectrum your design lies on, it needs to make sense for your product.

Engineering Requires

So, let’s talk about Engineering.

Engineering requires boundaries. Period. The act of building something needs to have room for creativity in how resources are used and implemented. It also needs a deep understanding of how the design works and whether it will work or not.

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. I’ve increasingly been finding myself hamstrung by the thought of “What about that? Doesn’t this need to be made better since I’m in here?”

Support Requires

Finally, we have Support. Good ole’ Support.

Support requires empathy and confidence in a product. It ultimately is the best way to communicate to Engineering and Design what’s going on in the reality of a product. If neither listen to what Support folks are walking through with customers, there will ultimately be more missed connections.

It’s really easy to look at support as a means of satisfying customers or end users. In so many ways, satisfaction and end result matters in this experience. However, your support interface and team are ultimately the funnel by which feedback comes in from all customers - big and small. Focus groups are great. Customer calls are excellent. Yet, those interactions are initiated by you. What happens when a customer is confused, angry, or has general questions? They’re going to talk to your support team.

One thing that always impresses me is when you put a few layers of support between a customer and an engineer. Yet, you ultimately have a means to put a engineering in contact with the folks they’re creating something for. We either make engineers too available to not available enough in so many situations. People need to do work and create what’s next on the agenda, but they also need to understand the impact of what they’re doing - good and bad. They also need folks who are able to communicate with customers and establish boundaries.

Support feels so much like moderating a conversation about a product. Responses need to be factual, but they also need to feel natural. Sometimes you get folks who are excited or very verbose in what they have to say. Other times you’re dealing with folks who don’t say enough and seem to be holding back from you. As support, you’re supposed to encourage those conversations and make them happen.