---

title: "Tiny thought: On the separation of design and engineering"
author: Thomas Wilson
date: 2020-11-23
draft: false
slug: "2020-11-23-on-the-separation-of-design-and-engineering"
tags:
  - essay
  - tinythought
  - design
---

_Tiny Thoughts_ are little (500 word) essays. They're concise.

I make user interfaces, and I often participate in, or lead, the process of designing these interfaces. For a while I thought I wanted to transition fully into a design role. Ultimately I am drawn to the certainty and craft of engineering. However, the the mental models, sensibilities, and philosophies of design still appeal to me. I can like both, and businesses need both.

Separating design and engineering is a false dichotomy: design can benefit from the implementation-details of engineering; and engineering benefits from the non-linear and multi-faceted process of design thinking. It's symbiotic.

A while ago I got the chance to work in an environment where the two _were_ separated. The design process and design thinking were both absent, and there was no appetite to bring them in.

During this time the mentality was to copy the UI of an existing, similar, already-successful product. A lot of people on the frontlines of tech have been told "just copy company _X_" where _X_ is AirBNB, Twitter, LinkedIn, Pinterest, whatever. "Just make the UI look like that".

At first glance, the thinking is sound: we don't have the money or time to invest in design, but this other company has. Let the whole design team over at Instagram/Reddit/Uber do the hard work, and we'll just steal from them.

At a personal level, I did not like working in this environment, because I felt alone. At a professional level, the working process was constrained, and the resulting software generic and left behind when the source material changed.

Some software has to be boring: I wouldn't want a whacky or zany bank app, menstrual cycle tracking app, government app, or crisis support app. There is a place for boring UI. Borings UI also removes a layer of difficulty in how the product is built. [^1: I would argue that it's not actually _that_ much easier to build an app with a Boring UI - UI is just one part of any software.].

Behind a lot of boring UIs is a team of individuals who have thought an awful lot about their business, users, and problems. They have considered information architecture, interactions, users, and outcomes.

Just because the end result is boring, does not mean the process of designing it was short and simple.

When you copy _just_ the final product, even a boring one, you diminish your entire business's ability to iterate, and any insight into the _why_ of the UI are lost. You have limited your engineering team. Sometimes this limitation is significant (a client-facing product), sometimes it is not (an infrastructure service).

The product of engineering should not exist without the process of design. The discussions I have had, facilitated, and witnessed when deciding on UIs have made me a better engineer, and have made the product better.
