At some point in a designer’s career, the age-old question is asked: “Should designers code?” My direct answer for people who design software interfaces is yes. This is a belief I’ve held my entire career. Despite my stance, I don’t like the question. It might be the wrong question to focus on and varies depending on who is asking it. Designers feel like they are doing multiple jobs, so if someone outside our practice provokes the question, it feels like we’re being asked to do more without being rewarded for the work.

At its core, design is taking an idea and making it tangible. Building your designs is a continuation and extension of that tangibility. Ignore the question of whether designers should code and look this way:

Designers build.

The fidelities of building Building your designs doesn’t assume production code. Less than 5% of the code I’ve written in my career made it to production (that’s a good thing), but 100% of it was considered in the software development process.

One of my favorite use cases to build my designs is to quickly navigate through the interface flow. When I used to work on iOS apps, my favorite method of building iOS prototypes was a simple Xcode project using UIStoryboard. Storyboards (as the name implies) made it easy to add interface elements in views and connect the views to have a first look at the experience. I’d compile the project and put it on a test iPhone, hand it to the developers for us to walk through the experience. Low-fidelity builds invoke high-fidelity questions. Even in the first run we could have a clear discussion on trade-offs and upcoming design challenges. I’d take the feedback and update the Product Requirements Doc (yes, designers should write PRDs).

Here is a video demo of the prototype I built. It’s all built in storyboards with a bit of Swift code to detect the logic. It did not take very long to build either! This is an example of how, with a little bit of technical acumen, you can put something very functional together. There are some designers out there who are truly unicorns in the craft—able to design and write code, even at the production level. They’re often called Design Engineers today, and I think they will be the most sought after role this decade.

Building storyboards and UI flows can lead to prototypes, proof of concept, and the insights needed in software implementation.

Comprehension of materials

When bringing a building or structure to life, interior designers work closely with architects—a similar relationship between software designers and engineers. Interior designers do not focus on architecture, but the good ones have intimate knowledge of the considerations and methods of architecture to ensure the design vision can come to life. They may not be the ones building the blueprints, but interior designers understand the engineering design decisions that influence their design.

When a sculptor creates a bronze statue, comprehension of the materials is not only the temperature the alloy needs to be heated to pour into the mold. What is the patina effect over time that might change the look of the sculpture? What is the weight and durability of the output? How will people maintain the piece years down the road? Though software is a different process than creating a physical object, there are similar considerations in the interface implementation and maintainability of the codebase.

Understanding the build materials fosters accessible design. If you care about accessibility, building your designs will make you even more considerate of it. It’ll force you to think about the different states and properties of an interface. Running a built interface through a screen reader builds more empathy than a representation of an interface.

Understanding the production line

Building and shipping software is like other product development processes. There is a production cycle that usually can be improved. One added benefit of building your designs is understanding how software is made. There is a slew of steps before you should ship: implementation, quality assurance, systems testing, and more.

Going through this process yourself allows a clear picture on what happens to the design through implementation. You’ll better understand bottlenecks and have a stronger sense of what considerations will need to be made as your design gets pushed through.

Getting acclimated to building

If you’ve never built software with code, getting started can feel intimidating. Fortunately, the code barrier is lowering every day, making it more approachable and accessible to do so. Building is not a process, it’s an action of transformation, and it matters less on how you build it.

When learning a new skill, I recommend finding the laziest way possible to build confidence. I used to take screenshots and reproduce them in Photoshop to build up my interface design skills. Here are some ideas to accelerate your comfort with the material of software:

• Build your designs in Webflow—no-code to know code. You’ll learn front-end primitives as you use it. As you get more comfortable, export the code to Replit and use AI to expand on what you’ve created
• Use Figma’s Dev Mode and build it yourself
• Practice reconstructing your interface designs in code

As you get more comfortable, you’ll be able to write more code from scratch. Remember, these skills take years to develop so focus on daily progress and small wins.

Building empowers

It’s heartbreaking to see a designer spend all this time working on screens and it never coming to life. Build your designs because you will make your idea tangible—don’t do it for others. It’s not, “designers should do this.” It’s, “I will do this.”

Someone once said to me, “When you build your designs, it expands your influence in decision-making. Why would you opt out of those as a designer?” I think about this a lot. Great software designers think of design from idea to software. We proclaim this a lot yet don’t practice it.

Building your designs makes you a better designer.

Designers build.

Originally posted on Proof of Concept