Why your team needs a design technologist
When I joined Carta in mid 2017, I had never heard of design technology. I joined officially as a “Producer, ” what Carta called a combination of a product manager, designer, and front-end engineer (because at start-ups, we wear lots of hats, right?). We were Product leads, in charge of essentially the entire product life cycle. About six months after I joined, we realized Carta had gotten too big for one person to be effective at all of this anymore. So, producers were split up into Product Managers and Product Designers. I became a Product Designer.
Some of my coworkers fell into their new role naturally; I did not. I was used to prototyping, designing, coding, and making product strategy decisions on the fly, all at once (in hindsight, probably not the best way to build product). For a few months, I created mock-ups in Sketch, built wireframes, and thought about information architecture. It took me a while before I realized I missed coding. My manager and I discussed it, and she agreed to let me “try out” a new combined role — one of both design and engineering. I wrote down a few of the job responsibilities I envisioned for myself and sent them to her on Slack:
- Work closely with engineers to make sure our code aligns with platform design & the UI kit
- Create UI-related PRs utilizing HTML/ CSS/ React
- Be engineers’ first point of contact for design help
- Work with platform design to make sure their needs align with our team needs
- Work with the product team to make sure our product aligns with the platform. Help create components if it does not
A version of this is currently on Carta’s jobs page with the title “Senior Design Technologist.” Without realizing it, I had become Carta’s first design technologist.
So what actually is a design technologist? In essence, a design technologist is a designer who uses code, not Sketch or another vector tool, as their primary form of communication. Because of this, designs are automatically scoped to what is technically feasible- reducing duplicate code, engineering frustrations, and off-the-wall designs.
I constantly hear complaints about “waterfall” product development — where a designer creates mock-ups and hands them off to engineers, with little to no communication after the mocks are complete. By the time the mocks have been coded, it sometimes looks nothing like what the designer intentioned. This is sometimes due to things getting lost in translation, and other times due to some technical constraint that meant the designs were probably never going to happen in the first place.
Also, building stuff takes a long time. Sometimes, we can’t afford to build something out completely in order to test a hypothesis. At startups especially, by the time an engineer finishes a project, there is a possibility that it could be killed, or the team could have an entirely new focus (an aside, this has happened to my team more than once).
Having a design technologist on the team means there is always an engineer whose job is first and foremost, the user experience. It means little things like CSS animations, button alignment, and error messages, and big things like consistency, brand, and usability aren’t overlooked.
It also means you can easily prototype with real data, something that is often lost when using Sketch, Figma, or InVision. Sometimes it feels like every case is an edge case (especially at a financial startup like Carta, where new clients with new use cases spout up every week). When you use real data to test, you find problems in UIs much earlier.
Lastly, and a point I want to really drive home, is that it creates empathy between design and engineering. It makes it much harder to have an “us vs. them” mentality when you have a liaison championing you to the other side. A debate between design and engineering I often see is:
Designer: “This design is better for the user!”
Engineer: “This version will take an extra month to build and is inconsistent with the rest of our app.”
As is usually the case, the answer usually depends on the situation. Sometimes consistent UX outweighs a “better” interaction, and other times the user suffers. Design technologists act as a bridge between the teams —they have expertise in both fields, and can explain tradeoffs in a language both teams can understand.
Design systems, Ink, and the future of the role
Another important aspect of design technology is creating a design system. At Carta, our design system is called Ink. Ink is an infant in the design system world, only about eight months old as of this article. However, it already has an enormous amount of momentum and designers and engineers alike are strongly encouraged to use it when they build product.
A design system is the set of reusable components that make up a company’s product, brand, and language. Examples of design systems are Google’s Material Design, Salesforce’s Lightning Design, and Microsoft’s Fluent. Simple components include buttons and dropdowns, and more complex ones include multi-step modals and forms. At Carta, designers and engineers alike collaborate to grow Ink and make it more useful, but at its core, it is owned by the design technologists.
The Pareto principle works well to explain how much to expect from a design system. Theoretically, you could build about 80% of Carta with just Ink components. That leaves the other 20% to specialized features and design innovation. In other words, it leaves the boring stuff up to Ink, so that designers and engineers can focus on building the interesting stuff.
One of Carta’s core values is to scale, and to do it quickly. A design system is by far the quickest way to build quality product, fast. We have far fewer bugs, less repeated code, and a path to easier, better-looking, more intuitive designs. Design technologists make sure Ink is suited for Carta’s ever-growing needs, and serve as the bridge between design and engineering.
Like dual sides of a crew boat, design and engineering must work in tandem to move forward quickly. Design technologists make sure everyone is rowing at the same speed.
