David Hoang — Writing — engineering

Design Engineering

Thu, 21 Mar 2024 00:00:00 GMT

In software, engineering and design are infantile in existence compared to other sectors: mechanical, electrical, aerospace, and environmental engineering. Engineering encompasses a broad range of disciplines and involves critical thinking, creativity, problem-solving, and collaboration. Many engineering disciplines have a role called a Design Engineer—a title that has been more popular in software in recent years. Design Engineers tend to work on products and systems that involve adapting and using complex scientific and mathematical techniques. In essence, they work on highly technical challenges that require strong design consideration. Today, we’re seeing Design Engineers become a popular role in software, and this isn’t the first time new roles/practices emerged.

In the early 2000s, the role of a Data Scientist became popular as data became increasingly abundant through the internet, social media, and digital technologies. Though the practice of statistics, analytics, and domain-specific knowledge existed before Data Science, companies like Facebook, Google, and Amazon were the pioneers leveraging data analytics to drive decision-making, improving user experiences, and growing the business. At the time, the practice was maturing in adoption and there was a shortage of talent who could do the role. Today it seems rare for any tech company to not have a Data Scientist.

Data Science was transformative in tech in the 2010s. In the age of LLMs, multi-device interfaces, and everything seemingly being programming, Design Engineering will be the transformative practice in the 2020s.

Design Engineering is not simply a rebrand of product design. Whether we like it or not, tech has a tendency to consolidate roles. Interaction Designers, UX Designers, UI Designers, and Visual Designers became Product Designers. Graphic Designers, Illustrators, Communications Designers, and Marketing Designers became Brand Designers.

To say Design Engineering is combining product design and front-end development dilutes the value the practice brings. Like a minestrone, the Arnold Palmer, or Cronut, Design Engineering is a true blend of two conventional roles. Design Engineers have deep knowledge in technological systems while scaling interface quality. They naturally fit in design crits or reviewing code with engineering.

Role, responsibility, and impact

There are three core areas Design Engineering is the top candidate for leading: product architecture, design infrastructure, and 0-1 R&D. These three areas do not encapsulate everything a Design Engineer might do, and the hope is to provide three concrete examples.

Product architecture

It makes sense for a Design Engineer, a role which balances technical systems and end user experiences, to be close to product architecture. In products that are authoring tools (Figma for design, Replit for code, Webflow for websites) it's important to think beyond isolated features but the foundational capabilities of what your product can do. Design Engineers have the right skills to explore aspects such as information architecture of a product and also understand the technical logic of how such things function.

Design infrastructure

Design Engineers are naturals at design infrastructure—the underlying tools and systems to scale design. This might be contributing to component libraries, building internal tools to increase efficiency, or prototyping new patterns and interactions to inform the future of their software.

In many cases, Design Engineers are brought in to prototype experiences that otherwise would be nearly impossible in static mockups in Figma. When you’re dealing with an interaction with a Language Server Protocol (LSP) or a layout engine for a site builder, you have to build the prototype in code.

0-1 R&D

Exploring new product directions can be needed for an early-stage company needing to pivot in direction or an established company looking for new growth opportunities. These initiatives are usually not funded due to the perceived risk of pulling people off teams to do this unproven work. Due to the multidisciplinary skill sets of Design Engineers, they're able to explore this space much more quickly and effectively than other teams.

Org structure

My philosophy on org design is to optimize for the desired results, not the existing org chart. I’ve been at places where Design Engineers reported to me (Design) and others where they report to Engineering. For the sake of Design Engineers, it's important to have a clear reporting line. Creative Technologists (made popular at Airbnb and Uber) in the 2010s have never recovered from the trauma of having unclear expectations and conflicting priorities of multiple orgs.

Design Engineering will revolutionize the 2020s

As we navigate what seems to be a tech paradigm shift with LLMs, AI applications, and multi-device experiences, Design Engineers will be this decade’s Data Scientist. Expect talent to be rare and continued definition of the impact of the role.

My hope is not for designers to simply change their title to Design Engineer on LinkedIn. It’s uncertain if every company needs a Design Engineer. However, I am confident companies with authoring environments or complex interactions/data need Design Engineers. Snap, Retool, Replit, Uber, Square, OpenAI, and The Browser Company are a few examples of companies that have Design Engineers on their software teams.

Data was the currency in the web era of social and ad tech. Now it’s trained data (LLMs) presented in multi-device interfaces. When it comes to an emerging function in a paradigm shift in tech, the Design Engineer is the new Data Scientist. Let’s see if that’s true in ten years.

Originally posted on Proof of Concept

Building your designs

Sun, 11 Feb 2024 00:00:00 GMT

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 think of it 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 gives you a clear picture of 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 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 that 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

IDDE: The infusion of design and dev tools

Fri, 31 Mar 2023 00:00:00 GMT

Many millennial designers grew up playing with Microsoft Paint—often the first UI drawing tool they used whether they knew it or not. This was also true for me, but there was another software that inspired me as a kid—Visual Basic 1.0. I thought the visual development environment for BASIC created by Alan Cooper was a design tool. From Visual Basic, to HyperCard, and to Macromedia Dreamweaver, I never cared (or knew) the difference between a design tool and development tool. It was about making something.

2008 to 2015 were formative years as a designer. I immersed myself in as many tools as possible and found ways to subvert them to build something; some of my favorites being Quartz Composer, Xcode, Framer.js, and coding on TextMate 2. Blending design tools with ways to build, I became enamored with the concept of an Integrated Design (and) Development Environment (IDDE).

The traditional IDE is a suite of tools and features needed for you to build and ship software. I never understood why design wasn't a part of it. Funny story: when I interviewed with Apple's Xcode team many years ago, one of the interviewers asked me what wild idea I would propose. "I would buy Sketch 2.0 and make it the new Interface Builder." This probably killed the interview for me.

Today, this vision of design tools and developer tools coming together is becoming more real than ever—not because of my experiences with Visual Basic as an eight-year-old, but because the way software is made is rapidly changing.

There are forces of nature in play accelerating this change, and it’s more timely than ever. The first is the adoption of Large Language Models (LLMs)—no surprise if you've been following tech trends in the past 12–18 months. I don't think LLMs are a fad or hype cycle but a foundational change. Because of the complexity of these systems, drawing UI isn't sufficient to design for something so dynamic. LLMs are only one example of a dynamic system being a core aspect of software. With innovations like Open Interpreter’s 01, multiple-device interaction is another complex system that drawing software cannot comprehend.

Second, the skill range of designers and engineers is expanding through natural skill building or augmentation with AI workflows. A designer who may not be comfortable with coding can hack something together through natural language. It also means a software engineer who may not like front-end work can get help with AI tools to close the skill gap. Both disciplines are getting more and more comfortable outside their traditional workflows. According to Figma, 30% of their users are developers.

Finally, shipping software is getting more seamless, resulting in faster iteration cycles to production. In my early career the most magical dev-ex experience was building apps with Ruby on Rails and deploying to Heroku. Today’s experiences will continue to get better for dev ex (and design ex!) for software creators.

Infusing design and development workflows

The concept of merging design and developer tools sounds great, but infusing the workflows can’t be slapped on. Regardless of how innovative or cool your product is, existing human behaviors and adoption will be the biggest competitor to your product’s success. Remember, the two most opinionated people about workflows on the planet are designers and developers. If the workflows are well considered and evolved, adoption can occur.

I came up with a few thoughts on what matters in an infused workflow and this is not a comprehensive list:

Abstractions are good, but software creators need to access the raw material (I need to be able to pop the hood open to look at the engine)
Access to inputs for real-time feedback is important for any interface manipulation
People break each other's design and code all the time and this often results in manual reconciliation
Presence and communication—the ability to have visibility on how changes impact the work

The IDDE is a software creation platform

It's an exciting time for everyone to participate in software creation. The infusion of design and dev tools is not replacing people, but empowering so many others with software developers being more important than ever.

The IDDE has been something I've been thinking about for more than ten years in my career. I can't think of a greater purpose than building tools that revolutionize the internet. I was motivated by this mission at Webflow and now get to work on it at Replit.

As Linus Pauling said, “The best way to have a good idea is to have lots of ideas.” If we can get more people to create software in the world, perhaps one of those people's ideas is the next idea that changes the world.