I’ve the great fortune of working with a team of people with tremendous individual strengths and also tremendous awareness of where their strengths end and others' begin. This awareness is a key skill to cultivate when managing projects across a diverse and transformative lifecycle.
Okay, there’s a second important lesson: the people that are behind the actual functioning of many pretty and seamless experiences that most of us take for granted are often forgotten or de-emphasized, and it is a project manager’s job to ensure that their expertise and input are captured and attended to. Without them, neither you, your team, nor your client will value the importance of that role, and you run the risk of designing something that can’t be built, losing your developer’s investment in the project, and ultimately, ending up way off in terms of scope or timeline.
“ab ovo usque ad mala (from the egg to the apples)”- Latin proverb
I’d like to be better at bringing our developers in throughout the process, so I’ll share the practices and consistency that are the best version of how we work:
Group Design Reviews
We have three scheduled team design reviews, in which we review whatever work someone wants eyes on other than their own. All of our designers participate, but PMs and developers do as well. These help the whole team; for the developers, though, it lets them see what interface elements are being designed and allows them an opportunity to show the team how they’re implementing designs.
Our developers are introduced in our kickoff calls, the full team meeting that marks the official beginning of a production project. While it’s not always necessary to have them there for every brand or concepting meeting, it makes a difference for the client and the developer to have that initial “touch,” spurring involvement and investment from both parties.
“When designers replaced the command line interface with the graphical user interface, billions of people who are not programmers could make use of computer technology.”- Howard Rheingold
Having a partially remote team comes with the challenge of how to maintain consistent team member involvement to the level that local team members have. Plus, for an area that is often not well understood or even respected by “creatives,” it’s sometimes easy to forget that a design depends on its developer to function in the wild.
Our team does a great job of seeking counsel from our developers via HipChat, standup meetings, and design reviews, but it often takes some knowledge of what it’s like to be a developer in order to even think to reach out to them. I can improve my game by reminding our UX/UI designers to talk those things out more frequently, and by reminding myself that the work I do in content architecture and strategy doesn’t actually end until a site has been lived with for at least some amount of time, the fact of which we owe to our developers.
As I alluded to earlier, our team’s diversity aids in our understanding of and respect for the role of the developer. So many of us have spent years working in various design and development areas and so we understand the implications of our own work, or they’ve come to the team partially because they have a healthy respect for work they don’t understand. That mentality, and the value we place in Asking More Questions, means that we have a team that thinks about what came before them as individuals in the process (sales, strategy, planning), their own work (architecting, concepting, experience design, interface design), and what comes after it (development, implementation, real life).
So, what are our takeaways? Involve your developers at each chance where it can better the project or the relationship overall, involve them as creatives themselves, and involve them mentally, which will automatically result in involving them practically, by really respecting what they do and how they make clever designs really come to life.
Thanks to @hasanga for the inquiry that prompted this post!