As designers working in software, we need to work hand-in-hand with the people who bring ideas to life. Yet, so often we tend to fall in the trap of placing artificial walls in front of these otherwise perfect opportunities to collaborate. I don’t think there is a one size fits all solution to bridging this gap but here’s my experience on approaching this at Auth0.

Caveat: At Auth0, designers are part of remote teams, with people working in various timezones scattered across the world. Read more about that here.

And as designers working on the product itself, we work in the form of triads. Or in lay terms — a tech lead, a product manager and a product designer. Most teams include an agile practitioner and/or an engineering manager for guidance. But the work-to-be-done is primarily shaped by the triad itself.

When I first started as a product designer, here at Auth0, many questions popped into my head. How does the product work and fit into our customers’ workflow? How will I provide the most benefit to the team and the triad? What do I care to invest time in learning, and how will that shape how I integrate into the team? And is the dashboard the most common way our customers interact with Auth0?

Solving the Problems of Working on a Developer-Friendly Product

It’s natural to gravitate to working with the product manager on the team, as that is a more natural order of things. But considering the technical nature of the product, it felt key to also work closely with the technical lead on my team. This was strategic to help me answer some of the more complex questions. How fast you bridge this gap will vary depending on how technical you are willing to get. But no matter what interests you as a designer, you can still gain from this type of collaboration.

This was a tricky path, since Auth0 at its core, is solving the complex problem of identity. And we’re focusing on the people that actually build software applications — the innovators. With this in mind, it can be difficult to break down everything you need to learn. Learning about identity, building for platforms, and Auth0 itself can quickly become overwhelming. And you might feel the need to get up to speed quickly to provide the team some benefit.

Finding the Right Ways to Collaborate

So my first thoughts were: it would be nice to start chipping away at these little walls built between product and engineering. I started by having regular check-ins with the technical lead on my team. He had been working at Auth0 for some time in many different roles and teams, so it was a great learning experience.

Quick aside: Auth0 helps to figure out what career path you want to move towards, isn’t that neat? It’s a combination of conversations about what direction you want to move in (whether in your direct field or not) and career-building activities.

Coming back now —

These initial check-ins helped bridge goals and get a shared alignment on them. They were also increasingly helpful to start building trust and empathy for the different roles. Empathy is obviously important to designers but it can be magical when used internally among teams. I followed this up by getting more involved in technical meetings and scheduling regular monthly check-ins with all the engineers on the team and joining stand-ups, among other, engineering-led ceremonies.

This is something that can be fruitful but doesn’t come naturally. As a designer, you need heads-down time to get your work done and devoting time for regular check-ins with engineers and joining technical, engineering-led meetings might seem like wasteful activity. However, it’s something necessary to help build context quickly. I learned that most of the engineers on the team cared deeply about the product, as well as, the experience of using it, all thanks to being mindful to take the time.

Diving Deeper Into Bridging the Gaps

As mentioned earlier, unearthing this required a lot of effort and time on my part. It’s not something that is evident, especially, when you’re halfway across the world. The most important lesson I gained from these conversations is that it’s important to build relationships to learn from. For example— using the time with an engineer to discuss your ideas and them punching holes in it can be helpful, if you keep in mind that you’re working to the same eventual goal. This can help you work better by being held accountable for your role and being transparent when something doesn’t work. This is great for getting validation at every step of your process for building products too.

Expanding these sessions into more collaborative experiences was an easy next step. We would discuss a feature, the technical lead would write the proposal for it, while I would simultaneously put together some rough mockups. This step felt key to sharing a vision of the feature itself; you made a decision together and not in a silo. The shared responsibility among everyone makes this better. This allowed the entire team to become more involved in user journey activities. A few months down and we’re trying to do more product-focused work together and keep making decisions together. An engineer from the team is even interested in moving towards a product-focused role.

Speaking the Same Language so You Never Have to Hand off Designs

As a designer, you either learn development on the side or not at all. What’s great about this collaboration is that it fixes the gaps, wherever they are. By having engineers walk you through what the API design might look like or what the data model is, helps immensely. After all, that is a large part of the user experience that you, the designer, are responsible for. In any product, this way of thinking helps to make certain decisions about the experience and informs the interface. Are we querying to the database at some point? Maybe we need to show a loading state for the content because the frontend is already loaded. What if there’s a network error? How do we signal this to the user? All of these technical questions are great for designers to build a product that is able to answer them for the user.

What it also enables is a common language. As a designer, you get better at communicating with your peers in the terms they understand and vice-versa. This is extremely beneficial, as you can, have discussions earlier in the process and inform your design work by any constraints that are required. Partly because you now have the tools to understand the technical side of things and partly because you will have constraints defined earlier, rather than later during what is traditionally known as a design-developer handoff. The more you continue collaborating, the less you’ll need something like a design-developer handoff.

You Just Can’t Fix Everything…

We use a famous quote by Henry Ford at Auth0 but I’m going to refrain from using that one. I’ll use this one instead.

“Failure is the opportunity to begin again more intelligently.”

— Henry Ford

This entire process is slow, difficult and prone to errors because there is no tailored fit. I’ve had to invest time in setting up multiple video calls. Otherwise, it’s hard to get everyone’s individual perspective on the work. There is also a steep learning curve around the identity space and learning the technical arc of the product itself. Yet, the key has been to keep building a relationship with the members of the engineering team. Things get a lot smoother, even if they aren’t perfect. The dynamics of your team are constantly changing and this changes how you work with people. For this, I’d recommend reading a bit more about team dynamics and how hard that can be. I think transparency, communication, and feedback will still be topics for that.

Key Takeaways

The few ways I’ve found to make this collaboration better: 1. Start conversations with engineers, they’ll be more than happy to help. 2. There’s a great deal of knowledge to go around, learn from it. 3. Join technical meetings and try to be more vocal with questions in these. 4. Start involving engineers in collaborative activities for product work, this helps bring in ideas. 5. Build things together, engineers bring the technical context and designers bind that into a simple journey. 6. Build relationships with these remote humans, you’ll cherish your time working wherever you are. 7. Don’t be afraid because things start getting technical, as designers, we have the ability to make things simpler to understand. 8. Be open when you don’t know things, this is the only way to get better.

Conclusion

These key takeaways sum up the experience of working at Auth0 in a product team. We work, not only as designers or engineers but as peers in building something great together. Remote work can sometimes feel awkward because of the lack of real-world interaction. However, if designers take the leap to involve ourselves in parts outside of design, the outcome is definitely great. It’s less about passing the buck and having shared ownership of the product.

For me — I’ve come to learn so much, not only about Auth0 but about identity by crossing over this bridge. This path continues to be fruitful for learning and carving out further distinct areas of growth. Collaborating with engineers not only enables me, as a designer, to understand and work efficiently but also helps other designers bring these ideas to their respective teams. On the design team, we’ve had many great discussions and action items come from these design-engineering workflows. I hope this helps you get ideas for collaborating with your engineering counterparts! And if you find yourself really wanting to join a company that believes in a shared roadmap for identity between design and engineering— Auth0 is looking for product designers. Find out more at our jobs page here.

Thanks for reading along!