Why Have Design Technologists?

A design technologist can move between the design and engineering worlds seamlessly. They can change their shape and blend in depending on the environment, and therein lies their power: they are powerful advocates for holistic thinking. They are the first point of contact for engineers because of their eye for design. They are the first point of contact for designers because of their ability to confirm feasibility and prototype rapidly.

The role of the design technologist is just another part of the process as they are made to interface with both the design and engineering teams. They are the glue that holds the design context as the product (and they) moves from idea to software. They can facilitate communication between design and engineering, but do not be mistaken: their presence alone cannot fix bad processes or make processes out of nothing.

Bringing designers closer to the screen

During the initial phase of a product, design technologists enable designers to explore the potential and possibility. How does this idea feel? How does it flow? Is something missing? Could animations be added in certain areas? What’s possible? Design technologists bring the medium of the browser to the forefront for designers: Throw away the static mocks. They do not serve you, because we do not work in print.

Design technologists enable design teams to see, play, and explore ideas before committing to a decision. Most engineers hate throwing out their code, but design technologists love it. Throwing out code means we’re one step closer to the right answer. The product can validate thinking early in the process, before upsetting engineering with tentative, unsettled ideas.

As the product moves from design-ready to engineering-ready, design technologists can transfer to the engineering team. They can make accessible, beautifully coded, beautifully designed user interfaces.

Focusing on the solution, not the pixels

During the engineering phase of a product, design trusts them to bring their creations to life, and they no longer need to spend tedious amounts of time redlining minor differences between the static mockups and the final product; they can continue to do what they do best: creative thinking. Similarly, engineering trusts them to build user interfaces that are easy to reuse. Design technologists can build component libraries from the ground up. They are experts in CSS and HTML.

Design technologists have the design context from the initial phase of design, so they are able to embody that logic within the very code.

Design is not adverse to rules or structure. In fact, I’d say in the world of product design, the design process is to bring a murky problem into the light, really look at it, and impose a structure within the constraints of business and technical requirements, so that users do not have to go through the same murky process. That’s the job.

Engineering loves and thrives on rules. The design solution is often far less about the actual pixels and more about the rules and constraints. Engineering can sometimes get bogged down in the pixel details, which is why “pixel-perfect” permeates design job listings. I’d argue a better approach would be to solve the pixels once in a robust Component Library and re-focus engineering on the point of the solution: imposing a structure so that users do not have to go through the same murky process that design did.

Formalizing values into code

Additionally, many design teams have principles that serve as a checklist or guidance as they critique their own and the rest of the team’s work. They can sound pretty vague or abstract: Relevant, Human, Unified, Aesthetic Integrity, Consistency, Metaphors, etc., See and Experience, Dimension and Diagram, etc. are just some examples of many possibilities.

How do you bring these abstract principles into code? By the same process! Engineering can fall into the trap of ego-driven development, in which a chosen Coding Genius promises the path of a silver bullet that can solve all technical problems. Each project is different, just as each human (each user, each audience for a product) is different, so there is no such thing as one-size-fits-all development.

Instead, I’d advocate for engineering to use the same design principles and guidelines to inform their technical decision-making: What technologies to use? How is the code documented and shared internally? Pull request reviews are akin to design critiques: code styles and preferences can be just as subjective as answering the question, “What makes good design?” Instead, focus the discussion around, “Does this follow our principles?” rather than “What’s Company A/Person X doing?”

Baking principles into the developer experience means the code now reflects design and product thinking catered to a specific product, a specific audience, at a specific time; it seems inherently flawed to me to try to do otherwise. My favorite developer experiences are the ones where it’s hard to do the wrong thing, and it’s made clear why it was designed in a certain way.

In service of the user

Ultimately, design technologists are freeing designers to be more creative and aligning engineering with the design principles of the product: all in service of the best possible user experience. Designers can get closer to the product earlier in the process, and engineers have a good developer experience to easily do the right thing. The process repeats itself. At this point, do we even need to worry about facilitating communication anymore? Everyone is already working together toward the same goal, and the software is in service of the designers, the engineers, and ultimately, the user.

Many thanks to the eyes of Joe "Joebus" Alterio, Scott "why don't I have a nickname yet" Stewart, Alex "King Lande" Lande, and "Don" Amy Dickson