I’ve recently had the pleasure of working at a large digital agency here in Toronto. We generally work on long, large projects that need hundreds or thousands of design and development hours. Design and development also work tightly together daily. This means that it’s important for us to have a shared understanding of the problems we are trying to solve. It also means we need a common language of the solutions we plan to execute.
Because of the size of the teams, I don’t get to do any development. On one hand this kind of sucks but on another, it’s been a good challenge to immerse myself on the design side and not have to focus on implementation. This is not to say we don’t or shouldn’t think about implantation as designers but that we can focus on UI and UX and work with the development team to turn that vision into a working product. I also work alongside many designers with little to no development experience. In this article, I’d like to talk about both these perspectives. How I have seen them effectively (and sometimes not effectively) collaborate with development.
The 3 Wisemen
There are 3 specific roles we use on almost every new project. These roles create a collaborative culture between tech and design. They are the SA, the TPM and the TechLead.
Solution Architect (SA)
This could be summed up as the person who architects the technical solution but that wouldn’t be very helpful. What they really do is initial scoping and technical analysis of the product. They work closely with product managers to help them first get material requirements from the client. Then turn those requirements into a rough timeline, budget and technical solution. But how do they fit in with design?
First, while the PM and SA are (usually) the first 2 roles to get on-boarded to a project, design should be right behind them. If not alongside. Secondly, during early discovery periods on projects the SA can act as a counterbalance. They might not have any opinion on UI/UX but they can give the PM ballpark estimates on effort and feasibility. At first, this might seem too constricting to designers but it gives them the freedom to explore radical ideas knowing that there is a vetting process before anything goes into development. Without this vetting process, there would be unnecessary tension between design and development with designers delivering designs they expected to be built regardless of the impact on timeline or budget. This is emphasized in design teams with less development experience.
Technical Product Manager (TPM)
Filling a gap between a SA and PM is the TPM. A SA typically rolls off the project as the sprint cadence starts to get going, giving way to the TPM and TechLead. The TPM can fill the void the SA leaves but instead of envisioning an initial scope or timeline they are focused on the day-to-day. They look through the lens of a product manager, putting the product first.
TPMs and design (along with other roles like Business analysis and PMs) work closely together during design sprints or when designing new features. They can provide that same vetting process as a SA allowing designers to explore. They also have a bigger stake in the product’s success and should be more opinionated about UX.
TechLead
The TechLead is the person who is leading the development team through each sprint. They are most worried about the codebase, making sure the code the team writes is working, clean and reusable.
They might have personal tastes as far as UI and UX but they generally don’t care too much about the look of the product. They are a key person to work with on issues like accessibility and the nuts and bolts of the product. They are the most familiar with the codebase and I’ve found the best person to discuss things like micro-interactions and other implementation details.
Working with these roles as a designer
Not one of these roles stands above the rest. They all serve a specific purpose and, more importantly, facilitate quick, iterative work instead of bogging teams down with more processes.
One of the largest obstacles to overcome when collaborating with these roles, especially for a designer with little or no development experience, is a shared technical understand and language. We have a strong design team, and a strong design team is inquisitive, they don’t take “this is too hard to do” as an answer. They want to know why it’s “too hard to do” but, sometimes, it can be hard for a SA or TechLead to explain this.
A designer doesn’t need to know how to code though, they don’t need to know a single line of JavaScript. They need to understand the concepts of web and mobile. When designers on a team have an understanding of the abstract way a website or app is built, deployed and served to a user they can effectively work with tech roles like SA’s and TPM’s.
One way we have solved these issues is by having learning sessions. Technical directors take time out of their weeks to put together and deliver presentations to design teams about concepts like networks, frameworks, etc. Vice-versa, design leaders put together presentations about design systems, design tooling and other topics.
It’s important to understand that you, as a designer, don’t have to be technical. That’s why we have SA’s, TPM’s and developers, but you need to be able to understand them and work with them on a daily basis.
