Building Better Products Through Strong Design and Engineering Collaboration
Joāo Marcelo Martins is a Full Stack Engineer, Rita Wang a Product Designer, both on the Customer Engagement team at GetYourGuide. They explain how engineers and designers can work together, as opposed to handing tasks and responsibilities off from one person to another, to create experiences customers will love.
Design and engineering are core disciplines of any tech organization, but they’re often seen as two independent stakeholders in the product development process. Even when teams are functionally oriented, and with design and engineering peers sitting next to each other, it's still easy to find knowledge gaps and information silos that can hinder the outcomes of a team.
We strive to make the collaboration between designers and engineers at GetYourGuide a handshake instead of a handoff process. This increases the accountability of individuals on the team's deliverables and improves their output. We'll dive into how we approach this collaboration style, and the benefits we’ve gained from it.
Overarching alignment and streamlined decision making
It's easy for engineers and designers to fall into silos within their respective disciplines. After all, they use different software programs and tools to do their work which don't usually overlap. However, in organizations that aim to build better products, it's vital that the intersection between design and engineering doesn’t get overlooked, but rather is made stronger.
Throughout different projects, we embraced the challenge of understanding and exploring each other's realms of work so we could deliver great and scalable experiences to our customers. The way we achieved it was by being side-by-side, not only physically (or digitally on Slack), but also by overcommunicating our end-to-end thought processes.
To achieve alignment when working on projects, we had to make sure to have full clarity on:
- What we’re trying to solve: Made us focus on a single problem, design, and engineering-wise
- Impact of the problem: Aligned our priorities and how we should tackle them
- Potential solutions: Made us more flexible and accountable for potential changes
- What's acceptable: Going from MVP to a robust solution
Not having this knowledge spread across multiple members of the team helped us be more agile when making decisions, and ensured that our final product would satisfy what we set out to do.
Problem break-downs, prototyping, and POC validation
Having designers and engineers working truly collaboratively gives teams the superpower to make prototypes and test proof of concepts (POCs) much faster. This drives clarity on product feasibility, as well as enhances the overall quality of the experience delivered. For example, assumptions can be tested and iterated in much shorter cycles.
This is a key practice for us to put into practice and deliver on our principle to solve the customer problem quickly. The experimental approach makes it easier to work on separate pieces of the problem the team is trying to solve at the same time. It also speeds up the learning process, helps us reframe the problem statement, and iterate on solutions. This is a fundamental part of converting what were initially only ideas into full-fledged products that delight customers.
We achieve this by making sure we have enough checkpoints in the process to scope the problem definition, review concepts, and breakdown product solutions. Once the initial path is laid out we start the implementation. We make sure the work we’re doing is granular enough to check in again after an iteration is complete, learn from what was done, and course-correct if needed.
When we were redesigning our city itineraries to help customers explore a city with a schedule tailored by our destinations managers, this was particularly useful, because it enabled us to focus on each element individually. All components were designed and built-in isolation and as they compounded, our MVP began to take shape.
We still had components we wanted to add to the overall experience, but with a first version already live, it allowed us to be a lot more purposeful and precise on what was coming next. This process tightened the design and engineering disciplines and brought a truly cross-functional approach to product development.
Introduce a piece of engineering into the design process to stress test the solution early
When following the handoff rather than handshake way of working, what happens is we only discover certain problems when the design is implemented. It’s important for designers and engineers to do the research together. Each person can then bring their skills and experience to the table, challenge each other, and think about edge cases together.
Something we found especially useful was empowering designers to work with real content and see how the design would look in different languages, domains, and currencies.
Since it’s a hassle to copy-paste content elements from the live website, and diligently convert currencies, Designers sometimes skipped this step. As a result, we still found ourselves facing issues after the design went live.
This would result in frustration and unnecessary iterations to solve issues and also jeopardize the customer experience. For components that are essential to the customer experience and business performance, it’s worth making sure the design solution works with all possibilities — for example, different languages and currencies.
Designing with real content holds us accountable, and can also uncover issues with a given UI pattern. It's challenging for product designers to manually think about all cases, that's why introducing a piece of engineering (populating real copy in the UI) to help stress test the UI pattern helps us catch issues earlier.
As a HackDays project, we worked together to design and develop a Figma plug-in that populates activity information into a Figma design. As a proof of concept, the plug-in shows a list of activities with specified destinations, languages, and currencies. With the first version, we were able to spot issues with our activity card design, brainstormed how we could better solve these issues, and discussed learnings that would help us design and implement better activity cards.
Name and structure the design solution to make the intent of each layer self-explanatory
One exercise we found particularly useful is going through the component structure in detail when we dissect the component pieces and refine how they will be implemented. When designers structure each component in a way that reflects the information structure and properly name each element in the design mocks, it helps engineers understand how they’re thinking about the solution. This allows them to provide input to better structure designs.
By discussing the component structure before beginning implementation, designers and engineers are doing research together, understanding what information is required to populate a component (for example, information required from the API), and whether the structure makes sense. This helps engineers examine, for example, the API response structure, so there’s no unnecessary overhead to parse and render.
In 2021, our team worked on introducing new content formats, such as itineraries and travel guides. We needed to think about how we could enable content creators to upload content, how we could make each field as self-explanatory as possible (naming, examples), flexible, and at the same time provide some constraints to prevent human errors, such as limiting the choice of colors.
Designers and engineers set aside some time to go through the content structure together. Designers prepared a template to show the intent of each frame. This would make the hierarchy clear, name each element to reflect the content that should go in this frame, and the intent behind presenting this information to customers.
With this exercise, we also discussed possible changes and iterations. “Do we want to enable text links in this field in the future? Or would it always be plain text?” We asked these questions to clarify the intended structure, and empower engineers to design a more robust implementation.
Engineers know best what parts of the content can be "degraded" to prioritize performance and avoid unnecessary flexibility that could be prone to human error. For example, if we only need plain text for a description field, enabling content creators to upload rich text (with hyperlink, text formatting) creates unnecessary overhead that hurts consistency and, as a result, the customer’s experience.
Build complex components in design by examining information hierarchy, implementation, and API response
It can help designers understand the constraints engineers work with by looking at the information sent from the servers through APIs. This is the information engineers use to implement components and adjust the design structure accordingly.
For example, if there’s a string of text on a design that says “EUR 90.00,” it will be easier for engineers to work with if it’s broken down to “EUR” + “90.00” in the design. This is how engineers parse information and render components. This also helps designers think about the intended experience and edge cases.
For projects where we start with the design first, as an engineer, it's extremely helpful to go through the layers of the proposed solution to understand what sort of data we'll need to fetch within our application to make the design come to life. This helps us more precisely gauge what it takes to implement a design, and kick starts work that can be done asynchronously.
When we were working on the Figma plug-in, for example, we sat together (virtually) and talked about how to map API responses to display certain UI elements in the component. We defined it together in a mind map. We highly recommend using a visual aid to make sure you are on the same page, and for documenting decisions along the way. FigJam is a great tool for this.
We hope that you got a flavor of how Design and Engineering work together in a handshake format. You might be in an environment where collaboration is more like a hand-off, but there are certainly small things that can be done. We suggest taking time to understand each other’s work and challenges with curiosity, and think about what can be done to make collaboration smoother. This is an exercise rather than an end state.
For our team that meant investing more time on refinement sessions and that everyone involved in the projects was encouraged to provide constant feedback so we could validate our ideas during the process. Every organization will have different processes and ways of handling projects, but through open and nurtured collaborations, surely, the outcomes from the team will be improved.
Besides the more measurable benefits, there is certainly pure joy when you work together instead of working in silos. Seeing how helping your team members achieve more, building a great product with the skills each role has to offer, and delivering better customer experiences and business value, are what makes work enjoyable every day.
If you’re interested in joining our Engineering team, check out our open roles.
Other articles from this series
The Road to an Engineering Career: Learning to Code at 27
Behind The Journey: Laurence Rega - Full Stack Engineer
How to Empower Engineers with Infrastructure as Code
How we find and fix OOM and memory leaks in Java Services
From Interviews to Onboarding: Insights From an Engineering Manager