Ideation is a time for endless creative possibilities. Brainstorming sessions are held, inspiration strikes and you reach for the tools required to shepherd your ideas into reality.
Bridging the gap between concept and execution, of course, relies on cooperation between designers and engineers — two groups whose varied approaches can harbor animosity and stifle innovation.
“The biggest challenge is how each wants to deal with the idea of possibility,” said Mainor Claros, a senior software engineer at healthtech company GoodRx.
The divide becomes a question of language, he said, with each side struggling to decipher the other’s intentions. Even when their goals are aligned, diverging viewpoints can get lost in translation.
“Engineers want to handle as many possibilities as they can, using the fewest all-encompassing rules,” Claros added. “Designers want to make the most of every possibility given.”
The trick is to reconcile these differences so both sides can better understand each other. That’s why Built In Los Angeles reached out to a group of local designers and engineers who have learned to embrace collaboration and think outside the box to discover unexpected areas of innovation.
Designers and engineers bring very different perspectives to the work they do. What can these teams do to better understand each other’s space?
To understand this is to understand what satisfies a designer and an engineer.
Engineers are faced with problems that, at first, are too much to wrap our heads around. The goal is to reduce problems into a few, simple requirements. Failing that, we strive to reach some level of consistency. We crave that — along with simplicity — because our task is to teach computers to perform not-so-simple tasks.
Designers are tasked with imagining and describing an ideal state, where the observer or user feels best. Designers need to do this for various viewpoints, and this takes time. Except this description is interpreted differently depending on the observer’s vision and experience.
Engineers and designers both strive for elegance, but our definition of elegance differs. For designers, simple is not easy, and similar-but-different versions might as well be entirely different. For engineers, design is as much an ever-growing, incomplete task as coding is. Design is not as easily isolated as code; it depends on context and we should allow for constant design refactoring.
Designs can differ depending on the context, but they must be composed of consistent building blocks.”
What’s a strategy you’ve found to be particularly effective for creating and maintaining alignment among teams?
What you want is a design system. Designs can differ depending on the context, but they must be composed of consistent building blocks. The fonts, paddings, margins and colors can be strictly defined in a set of variables, which engineers love, while the combination of those variables can give birth to something bigger than the sum of its parts.
What is the biggest challenge you see designers and engineers run into when working together? How have your teams overcome it?
The biggest challenge is not sharing work early or often enough. We believe there’s no such thing as sharing your work too early with the right expectations in mind. At Albert, we try to establish a frequent cadence in sharing work — even if it’s just sketches in design or early builds within engineering. This type of transparency helps keep our teams in sync and agile.
Designers and engineers bring very different perspectives to the work they do. What can these teams do to better understand each other’s space?
Often, this just comes down to empathizing with one another and keeping multiple channels of communication open. We’re lucky to be working in a time where tools have become more collaborative than before. At Albert, we use Slack, Figma, Notion and various internal tools that bridge the gap between the two departments. This has allowed for developers to contribute to the user experience in Figma themselves and designers to understand technical constraints using their sandbox environments. The key here is for each team to learn enough to be able to talk in the other’s language.
We’re lucky to be working in a time where tools have become more collaborative than before.”
What’s a strategy you’ve found to be particularly effective for creating and maintaining alignment among teams?
Overcommunication is key for alignment, especially through our current times, when teams have been working in environments that are more distributed than ever. Within each project, we like to bring engineering into the product design process early — even if it’s a short conversation introducing the project and our intentions behind it. This allows us to receive early feedback and often uncover technical constraints that the design team may not have been thinking about.
What is the biggest challenge you see designers and engineers run into when working together? How have your teams overcome it?
To answer this question in a general way is difficult, because it depends on the context in which designers and engineers are working together. For example, are they working on an early proof-of-concept or a research spike; at the alpha stage, the beta stage, a full release; or on an incremental update? Is this a consumer-facing, B2B or an internal-facing effort? Is this a small, medium or large project? Is this a single-team effort or a cross-team effort? What are the specific roles and the experience levels of those involved? What’s at stake? Is this a small bet, or are we reaching for the stars?
At Supernatural, we try to be sensitive to the context we’re operating in. Today, our focus is on building cohesive, mission-driven teams with clear scope and purpose, where everyone in a team is aligned on a shared vision. We feel that every discipline has a spot at the table, from product, program management, and engineering to design, QA, release and marketing. It is important to all of us that we understand the problems we’re trying to solve and our roles and responsibilities on a given project, which can change, too. We try to create an atmosphere where no one is stuck in a single lane — where everyone has an opportunity to share their ideas and be heard.
We feel that every discipline has a spot at the table.”
Designers and engineers bring very different perspectives to the work they do. What can these teams do to better understand each other’s space?
I don’t know if this is necessarily true — that designers and engineers bring very different perspectives to the work they do. Surely, any two individuals can have very different perspectives, inside or outside their disciplines. But the design and engineering disciplines can have a surprising amount of overlap, too. Both disciplines require developing a deep understanding of the problem, customer, and tools and processes for work and collaboration to forge a path to achieving quality through internal and external review and testing their assumptions and results on a regular basis.
I’m often impressed by how much designers can think like engineers in how they systematically approach their design problems through well-informed research and reasoning. I’m also often impressed by how creative thinking can inform the engineering process.
Honestly, the best way to get designers and engineers to better understand each other’s space is through communication. Both in-person — these days over Zoom — and asynchronous communication are key. In-person communication is important at project kickoff meetings to get alignment on goals and working agreements. It is especially helpful for designers and engineers to align on standards for how design assets should be structured and shared so that engineers have a clear understanding of how to implement a designer’s vision. One needs to foster an open environment where engineers are free to ask questions about a designer’s intentions and give feedback as to what is or isn’t technically feasible. Additionally, one needs to foster an environment where engineers are encouraged to share their early implementation results with their design counterparts and other stakeholders to gather feedback and course correct implementation as needed.
Finally, it is important to celebrate the wins and learn from the mistakes. Wherever there are successes or breakdowns, there are lessons to be learned. So, retrospectives are important to the health, growth and mutual respect of any team.
What’s a strategy you’ve found to be particularly effective for creating and maintaining alignment among teams?
First and foremost, the planning process is key to creating alignment. We try to make sure there is a well-defined product brief before we undertake any major efforts and that everyone involved in implementing that brief, including designers and engineers, have had a chance to ask our product team questions. The product brief process itself is designed to be an open one. Oftentimes, ideation comes directly from designers and engineers during the product design phase, but sometimes ideas will be incorporated well after implementation has begun.
Maintaining alignment is a more complex problem that involves concerted program management, commitment to high standards and best practices, emphasis on peer review, and partnership with our QA and release management teams. We lean on a shared commitment to achieving the best possible outcomes for our users, being the best we can be at our crafts and harmonizing with each other.
One real-world example was our Boxing modality launch. We had very ambitious goals at the outset, and aligned on the decision to launch it by the end of October. We also wanted to release an early version in mid-October to select partners to get early input and help drive a great community outreach opportunity. So, with time as a fixed entity and quality being non-negotiable, we worked carefully together to refine the scope of the project, jettisoning anything that we didn’t feel was absolutely critical. We then held several planning sessions among our product, design, engineering and content teams to align on exactly how we would implement every major facet of the new modality. To stay in sync during implementation, we held a “scrum-of-scrums” among team leads to ensure there were ample opportunities to keep each other informed. We were so on-point with our collaboration and planning that no one had to work overtime the weekend before launch. We were able to maintain work-life balance because we supported each other throughout the process.
What is the biggest challenge you see designers and engineers run into when working together? How have your teams overcome it?
Making sure a designer’s vision is the actual end product: There are many variables to consider when constructing web applications, and they can all affect design. Screen size is one example. A design may look great on a 13-inch laptop, but how does it look on a phone or tablet? How about a 27-inch monitor or 72-inch TV? When we display on a phone, does everything just shrink? Do things get eliminated? How about this grid that has five items across? Should that change dynamically based on screen size? The variable list is endless. Planning and establishing clear objectives can go a long way.
Do we care if this is usable on a phone? If the answer is yes, then we need to plan, design and engineer for that. Early communication between designers and engineers can also help. An engineer may have worked on similar problems or have useful industry knowledge. From discussions and planning, the expected design can start to take shape. How it will look and function at various sizes, how things should shrink and grow, and how they transform. From these instructions, engineers can start to build.
The variable list is endless. Planning and establishing clear objectives can go a long way.”
Designers and engineers bring very different perspectives to the work they do. What can these teams do to better understand each other’s space?
The use of design systems such as material design help bridge some of that gap. Using material design and building your own design system can give designers and engineers common definitions. Design systems force designers to think about design and interactive elements as building blocks or components, which is exactly how engineers employ them.
Design systems define low-level building blocks in detail and then combine those to make more components. As an example, you design your typography rules and guidelines and then button rules and guidelines. Now, do the same for form elements. A sign-in dialog is really just a combination of all of those and possibly a container or card. This is simplified, but you get the idea.
As an engineer, you can start using a component library for material design. With the base level components, you can build new custom components. Discussing how these components look and behave between designer and engineer helps establish a common language. Even though the workspaces between designer and engineer are vastly different, having common components with the same name, look and behavior can help establish common language and aid communication.
What’s a strategy you’ve found to be particularly effective for creating and maintaining alignment among teams?
Designers and engineers should work closely together to make sure goals are aligned and then met. Fostering an environment that encourages direct and immediate communications between teams helps keep that alignment.
As an example, I’m working on a story for some listing displays at Veritone. Each one contains a thumbnail picture, title, date and description. I have a design I’m working from, and each one of these in the design contain the same amount of data and are the same size. When I actually get my component hook into API data, I find that the descriptions vary widely in size. Some have no description, some have just a sentence, while others have paragraphs of information. The variations in data have brought up a host of design questions. I need to contact the designer and go over the scenarios and come up with a workable solution. It’s OK if that conversation is short, and is basically, “Send me a screenshot, I’ll work out solutions for this and get back to you.”
Issues can and will come up. Knowing that it is okay — and encouraged — to ask questions and solve issues together can make a difference keeping teams aligned and goals achieved.
