In the world of tech, working cross-collaboratively can be a real challenge. If project requirements aren’t specific, measurable, and time-oriented, design and development teams can end up engaging in proverbial tug-of-war of features and delivery dates.
As a designer, you’ll soon be out of energy while dealing with these changing project requirements. In the meantime, no real work isn’t getting done — and the important questions aren’t being asked. To put this into more relatable terms, let’s imagine the following scenario.
You’ve been assigned to a pretty big software project. The newer product exists as a low-quality MVP, but it’s on you to design upcoming features for it based on an older version while collaborating with a team of developers.
Your boss decides that the best way to cross-collaborate is through weekly sprints — meeting where you check in with the development team and update them on the progress of your designs, prototyping, and delivery constraints.
But after the first sprint, you find that this method of meeting quickly proves unhelpful.
First, you realize that while replicating an older feature to the newer product, you don’t understand what its purpose is for. You ask the developers, who give you a rundown filled with technical jargon you don’t understand. Just great.
Then, you get the feeling that developers are involving too much of their opinions into your work. Should you really move that component because they think it’s best? As the only designer on the team, you feel as if you’re the only one defending your rights as a designer.
And what about your manager? They often seem too busy to help, as their job is to assign you the work and advocate only when necessary. But what happens when they don’t do as they promised and you’re left compensating for the lack of support? This is when things can get frustrating.
Projects don’t lose their focus. Teams do.
One designer may have the resources and ideas to make a change, but only teams have the power to change the course of a project. Working together means agreeing on shared goals and a shared purpose. Project don’t lose their focus — teams do. That’s why the below methods can help you get back on track and make your design process goes smoothly in the end.
💡Tip #1: Create some solid design delivery references
One word of advice: developers have priorities, too. Often, your average developer has little time to ask you for design comps. And I’m guessing that constantly being asked to provide links is a distraction you don’t want, either.
That’s where a delivery reference comes in. This can take the form of a shared document or page containing links to your design deliverables. The best way to accomplish this feat is to build an interconnecting system of interactive prototypes or screens. These can then be linked together and labeled by task type.
This a great way to save time, and it prevents developers from distracting themselves from their work. Creating a reference page that links to all pages you design also helps you, in that all updates to prototypes you create will reflect on the links you create for access purposes.
💡Tip #2: Create solid component libraries early on
Working with design systems is a complex affair. As they evolve and expand, they can become difficult to manage. And as this becomes a more and more a reality, time becomes scarce when sudden changes need to be made.
You’ll need to be smart about how you handle information as this happens. This means creating component libraries that, when changes, create a similar changes on all areas of your prototypes.
Doing this requires a strategic mindset when working with the system itself, and it always helps to ask some key questions:
- What components are used the most? Observation may reveal that certain components are used more frequently than others. This in turn begins to reveal patterns the more time you spend designing with the system.
- What can cost more time later if I don’t address it now? As a designer, time-consuming tasks can become a serious roadblock to your progress — especially if you’re building onto the system and the team requests constant changes because of collective decision.
💡Tip #3: Communicate early (and often!)
Okay, here’s a question for you: how often do you really communicate with your developers?
And I mean, really communicate.
Not just showing up to meetings, giving a small presentation of your design, and fading into the background. I will say that at first, I was guilty of this — especially in my early design career. And why wouldn’t I be? It’s so easy to do that as a designer. Just sit back, design, and let the developers do their stuff.
But — there’s a problem with this
Working with a team is much more than that. To build a product and make your work truly successful, you’ll have to keep your team up-to-date on your design work. By doing this, you establish credibility — and this is essential to earning the trust of those who are coding, not designing, the product for customers.
How you handle this is key to your future relationships with the developers. Building a strong foundation will allow you to do a few other things:
- Vet your design decisions with more clarity on their side of the matter. As you continue to work closely with individual developers, you learn more about their point of view. In my experience, I’ve had the pleasure of learning a bit about code. Ask your nearest developer to give you a small guide on their deployment process. (They are developers —and are more than happy to give you the technical details.)
- Create a cohesive atmosphere for conversation. Some like to assume that UX and development exist in their own silos. I say otherwise — the best ideas form when people leave those preconditioned modes of thought and work together. Early communication fosters this kind of atmosphere early on.
- Ensures that management doesn’t have to worry. In addition to the general outlook of things being better overall, early communication also creates less stress for upper management. Each member of the team can clearly and confidently state that the project is going well with no concern.
These tips seem like common sense — but they’re golden
As someone who has worked with multiple developers on multiple products at a time, it always helps to remind myself of these simple, but important, steps to take.
Being a UX Designer often means that you’re playing multiple roles — the mediator, researcher, designer, and (sometimes) strategist. And beyond that, you have to consider the needs and goals of the people who will be using the product.
Developers act as a crucial part of that process. Work with them, and they’ll be your advocates. Don’t work with them, and they’ll seem like gatekeepers instead.
Most importantly, you’ll find that those who might seem the “uninitiated” in regards to user-centered design are just as curious about what you do as you are about their work.
How To Ensure Your Design System Helps To Achieve The Purpose Of Your Product by Nick Babich. Smashing Magazine. 2019.