Why Engineers build crappy products

looks like it was designed by an engineer

Published February 21, 2015 #product #overview

There’s a certain user interface that, when you first see it, screams out of you that it was designed by an engineer.

(via Daring Fireball User Interface of the Week)

Why does that happen? What is it in the nature of engineering or software development process that leads to user interfaces that are impossible for the users to actually use?

Perfect Storm of User Discontent

The short version:

Being a people person

The process of thinking about a new product begins with an attempt to understand what it is that the software supposed to do, that is, it starts with specifying a solution to a problem. This is assuming that the problem itself is correctly framed, which it often isn’t. These specifications generally take form in things like user stories and wireframes which are ways of specifying both what the user is trying to do and the specific interface that the user will use to achieve those goals.

Implicit in this is the understanding of what technology is able to do. Sometimes, especially for a product with a novel technical solution, what technology is able to do it isn’t completely understood. And regardless of whether or not the solution is in a known problem space, there will always be different challenges that will come up when building something. Building software is actually very difficult.

Given that fact, engineering will look at design, start thinking about what the general shape of the solution looks like, and should structure their development efforts around the parts of the product that seem the most risky – the parts that will be technically the most challenging. If we can prove that those parts will work, with a prototype or make it functional with a sort of mock interface, then and only then does it make sense to flush out the rest of the product.

The fractal nature of engineering

This is the fun part. Every engineer loves greenfield development because it allows them to explore the terrain without having to deal with the trade-offs, constraints, and messiness of existing code. The process is one of exploration, of being able to explore a technical space of possibilities and potentialities. This is really awesome, and a large part of what makes engineering interesting.

The experience is of building little things, putting them together in novel ways, and build things which are increasingly powerful. This leads engineers to put knobs and buttons and gizmos on different functionality to make it easier to explore all of what it can do. It’s socially rewarding to show off all this cool stuff, not just what it does not, but also what it’s capable of doing. Focusing on the technology aspect of it leads people to optimize the functionality in both breath and power.

Interface ecstasy

Engineers Keeping it Real: Go Fuck Yourself

The problem is products aren’t about technology. Technology is necessary but not sufficient to build products. Technology is just the plumbing, the thing which makes it possible, but not actually the thing that people care about.

The ecstasy of possibility is in conflict with producing elegant products, because products are fundamentally about making choices and creating clarity around something which is very complicated. This is more than missing the forest for the trees; the ideals and aspirations of both efforts are directly contradictory.

Example: Me doing Yet Another Dumb Thing

We were recently building a product that would use email as an interface touch point. Specifications, being what they are, didn’t really explain what should happen when a user attempted to interact with another user who had only partially setup their account. We were just playing around with some stuff, so it’s not even fair to blame the specifications on being vague; as it often goes when building something, we ended up way deeper in the weeds than anyone intended.

Looking at this from the edge case perspective, that is, while focusing on the engineering implementation and building in robustness of response based upon stuff that could happen, my instinct was to start building out code that would deal with this. It also uses slack as an endpoint, and in that set of scenarios it does something clever, so naturally email should do something clever as well.

I started down the path of being able to store partial requests that would get queued up and in the user interface to resolve in the future. I started going down the path of creating a whole bunch of functionality because I was thinking about things in terms of the technology, the other interfaces had something “elegant”, and I wanted to build something complete. Madness was creeping into the interface, because I was in the mind set of searching for a technology solution.

This is not something that’s core to the product. No one actually cares. In the situation like this, the answer really isn’t to be a lot of technology solution. I thought that there isn’t a problem, but that a technology solution is not the most effective way to solve the problem. It’s actually a design problem.

Technology is the easy part

If the teams aren’t integrated, if the design team “finishes” their work and then lobs it over the fence to the engineering team, this conversation will take the form of engineering requesting designs for something that “was missed and we need to solve”. It may have been missed, but it doesn’t need to be solved. The solution, in this case, is not to “solve it” at all, but to reframe the problem. And this reframing puts it into a place that engineers don’t like to be. It was not to build out a whole partially-completed-request queuing system that the user could resolve, be alerted of outstanding tasks or whatever, it was instead to simply keep the email interface simple and redirect them to the main flow on the website.

In short, the reason why engineers tend to be crappy product designers is that

Read next

See also

Bot Design Patterns

different ways to make different bots

In the antediluvian days before Google found everything for us, personal software agents were going to continuously do our bidding in cyberspace, tracking down air fares, making stock trades and otherwise doing futuristic things that we soon wouldn’t be able to live without. The anxiety of Y2K rose and crested, and the messianic aura of agents was washed away by more centralized and effective solutions. The aspirational residue did yield some nuggets, and the idea has found partial success in the form of the bot.

Read more

Field of Dreams is 25 years old and hasn’t aged well

if you build it, will anyone really come?

I’m sure you all remember the movie. A man whose normal life is starting to fall apart. He’s got the wife, family, mortgage and it’s both not enough and slipping away. He needs to do something, something to make him feel alive. And since it was that era of Hollywood film making, he’s also got plenty of daddy issues he’s working through. He becomes seized by a vision, caught in the grip of an idée fixe that he needs to go build something that everyone around him thinks is preposterous.

Read more

Bootstrap: Advanced Grid Tricks

You really should be defining your own classes

We are a big fan of Bootstrap here at HappyFunCorp. While there are some arguments to be made if Bootstrap in particular is all that, or if Foundation is better for a given thing, its clear that starting with some sort of CSS framework is smarter than trying to roll everything yourself. [1] There are three major complaints with using bootstrap. All of the sites look the same. There are so many classes in the HTML where they don’t strictly belong It’s a whole bunch of stuff that you don’t need.

Read more