Code Complexity is a Design Problem

As a designer, there is a scenario I’ve experienced far too many times. It goes like this: Everyone from the product team is gathered in a conference room. Design has just finished presenting a set of upcoming features, and there is a long, silent pause. Finally, a developer speaks up. “Do we really need to build this?”, she says, unsmiling. The room is filled with tension. Arms are crossed.

The engineers are frustrated. To them, designers seem like they are simply foisting features onto them with little concern for their needs. They are the ones who in turn will bear the brunt of the work, and toil after hours when something goes wrong. To designers, developers seem uninterested in delighting users, or even satisfying their basic needs.

This cats-and-dogs adversarial relationship between engineering and design needs to end. It’s bad for morale, bad for users, and makes products less competitive. Designers should actively understand and empathise with engineering, especially their concerns, and give them a prominent place in the design process.

A Singularity of Purpose

Design doesn’t deliver user value. Not directly. In the software business, code is the only vehicle through which value is delivered.

Think of it this way: The best design in the world, when in the form of an image file, sketch, or prototype, can be admired for its beauty, clever interactions, and innovation, but it can’t deliver value to the user. Production code is the medium through which users interact with the product and get to it’s value. Because of this, designers need to learn to care about it’s quality.

The Complexity Tax

In some cases, the importance of code quality for a good user experience is obvious. Symptoms of suboptimal code — such as slowness — directly affect the user experience in predictable ways. The right bug at the wrong time can cause customers to flee, never to return.

But the most important factor about code designers should concern themselves with is also the most subtle: creeping complexity, or entropy. Complexity is tricky. It often doesn’t appear suddenly; it accrues over time, and this accrued complexity will slow your product’s ability to change, adapt and grow. Think of code complexity as the opposite of a force multiplier. It’s a force diminisher. It imposes a tax on everything you might want to do with your product in the future.

Excessive complexity is what is on the minds of developers when they push back on design. Furthermore, if a lot of it has been able to build up, they might feel backed into a corner when new features are presented to them. This is the scenario that can result in hostility.

Code complexity weighs heavily on engineering, and they are usually the only ones paying attention to it. That needs to change.

Bringing Complexity into the Conversation

Most engineering teams primarily think of cost, while most design teams primarily think of user value. But potential future costs of features should be thought of in terms of technical cost and user value at the same time. To have productive conversations about cost and value, the whole team needs to collectively understand the problem being solved and why.

Implicit in this is a major assumption: designers have done their jobs. That means they’ve spent most of their energy working with customers to understand their problems, and are skilled in working through solutions in low fidelity.

Credit: Scyther5 | Dreamstime.com

Making Design Disposable

When designers thoroughly understand user problems, solution ideas take on a couple of desirable characteristics. First, they are more securely anchored in concrete customer needs. Next, they tend to come more easily, and therefore are more abundant.

When solutions are abundant and expressed in low fidelity, they take on a new quality: disposability. For any given user problem, designers should represent their ideas as cheaply as possible — wireframes and sharpie sketches. When ideas are disposable, they lose their preciousness, and become easy to throw away. That’s what you want.

Killing Ideas to Benefit the User

If two ideas are equally impactful to the user, but engineering expresses real concerns about one, you should be able to it kill on the basis of being high-cost, even if engineering just has a gut feeling. This can be done if you detect the excessive complexity early. Ideas are cheap and disposable; code is expensive and persistent.

Designers should enthusiastically dispose of ideas that have a high cost/value ratio, and work with engineering to find a better way forward. Together, you are working to reduce the tax on future possibilities. That will benefit the user in the long run. A healthy design process should leave behind a wake of dead ideas angled toward the future success of the product.

But just because you can kill an idea easily, doesn’t mean you should do it.

Defending Ideas to Benefit the User

A lot of my fellow designers get frustrated when engineering doesn’t want to build their solutions. Worse yet, they’ve handed off design “specs” and left engineering to fend for themselves, only to be surprised later by how poorly their designs translated into code.

If you really feel strongly about a solution that engineering have concerns about, you should first understand its cost, and then make sure you can persuade engineering it is worth it. Help them understand why it is important, and show why alternate solutions won’t be satisfactory.

Building Bridges

Bringing engineering perspective into the design process can help build rapport. If you are willing to dispose of solutions to keep code complexity low, engineering should level with you when you feel strongly about a high-cost/high-value solution.

Don’t expect this to be easy. Understand that engineers are not just building a feature set; they are designing a system with many, many moving parts, all the while trying to keep the complexity tax low. A high-functioning engineering team has high bars designers can’t see. 

Kevin is the Senior Product Designer at Pivotal Software and has previously worked for Google and the 2012 Obama campaign.