A product's design isn't just how it looks. It's how it works, and how it makes you feel.
As the point of discovery for new products transitions from real-world sales to web and mobile interfaces, design is increasingly a critical differentiator for companies trying to acquire and retain customers.
At the same time, advancements in frontend architecture, and the movement to more frequent site updates through continuous deployment, means that design and engineering teams have to work more closely than ever before.
The relationship between design and engineering rests on a few core principles:
Engineers need to empathize with designers — what they care about, what they look for in a design, what their ideal process is.
Design needs to understand engineering constraints — what can be built quickly, what's possible given team staffing.
Both need to develop an intuition for the user — at the end of the day, both want to deliver something that solves an important customer need.
Developing design intuition
As with most collaborative relationships, the key to developing a strong partnership relies on understanding your colleague's core objectives and their process for accomplishing those.
At first, understanding a design is not as intuitive as reading a product spec or reviewing code, because the intention behind the design is not explicitly spelled out.
Seek to understand intention
Simply put, design is the process of identifying and solving problems. When reviewing designs, ask the designer why they made the choices they did. What problem are they trying to solve? What are the principles that govern this design? Why is this solution ideal?
Ask about process
The fidelity of a design is a function of where it currently lives in the design process. Some designers are comfortable showing designs before they've been critiqued. Some are comfortable sharing only after they've been tested with users. When you receive designs, ask where they are in the designer's process. Are they ready for implementation? Waiting on user feedback?
Understand design systems
Most companies have established design patterns that are used to make iterating on new work faster. Like an alphabet for design at the company. When you understand both the intention behind a given design, as well as the patterns or tools that are already available in bringing that intention to fruition, you're in a better position to critique a design. Is this custom element worth building when we already have a component that sufficiently solves the problem we are trying to address, and doesn't fly in the face of the intention behind the overall design?
Providing engineering context
There are many avenues to solve a particular problem. There are fewer avenues to solve that problem quickly. If you want to deliver software that solves a customer problem quickly, it's critical to identify the lowest-scope solution that is still viable. To identify the "minimum" in "minimum viable product", you need to understand what constraints you're operating under.
Communicate constraints early
In the early stages of a design, the designer is typically thinking more about the problem they are trying to solve, the customer profile of the person who suffers that problem, and what the ideal solution looks like.
As an engineer, providing context about the constraints of the system are helpful in shaping the studio-space for the designer, and preventing him/her from exploring paths that would ultimately be infeasible.
Give your designer guard-rails — what data is available in this part of the user experience, what kinds of elements take a lot longer to build than others, how much more time building a custom component would take than using an existing one from the design system.
Make yourself available
Go to design reviews. Make yourself a resource during the exploration phase of a designer's process. Sit with your designer. Teach your designer why certain approaches are more feasible than others. Help your designer develop her/his own intuition about the constraints of your system.
Developing empathy for the user
Ultimately, the goals of the engineer and the designer are the same — to solve a problem for the customer. The customer and his/her problem have to be the north star, both for the design and the implementation.
Find a common vocabulary
When discussing a design or the final implementation of that design, it helps to have a well-understood vocabulary with which to provide feedback. Write down the problem you're trying to solve, and use it as a reference when providing feedback. Come up with the principles that govern the solution, and validate that what you're implementing fulfills those principles.
Many disagreements stem from simple miscommunication. Coming up with a common vocabulary with which to discuss designs ensures that disagreements are about what is actually important — the customer experience, and not the words we use to describe it.
Fill in the gaps
Even the most thorough designs rarely cover all of the possible edge-cases that one could experience in the real customer experience. As the engineer implementing the design, you'll probably encounter these edge-cases before anyone else does.
Understanding the problem you're trying to solve, and the intention behind the overall design will enable you to make important judgement calls when fixing these edge-cases. You can always work out the kinks later, but coming up with a strong first-pass based on the principles governing the overall solution will always be much faster than going back to design for further iteration on edge-cases.
Meet your customers
At the end of the day, there's no better way to understand how your customer users your product than to actually watch them. Developing an intuition for your customer's pain points, what they care about, and how they actually use your product will sharpen the judgment you use to make any change to the customer experience.
Are you an engineer who cares about the user?
The first step to writing any piece of software should be to identify the user story for what you're building — what problem is it solving, and exactly how will the user interact with it?
Then you have to write tests to ensure your user can actually complete the story you want them to. Wouldn't it be great if you could just write the user story, and the tests would write themselves?
With walrus.ai, you can write integration tests in one line of code, in plain english.
Oldest comments (0)