What It Means To Be A Designer’s Developer
As an Experience Developer at Adobe Design, our central design organization, I play a unique role during product development. Sure I perform all the standard engineering duties: I implement features, I review pull requests, I fix bugs. But what differentiates my job is that I develop in the service of design and user experience. I see it as my responsibility to do what’s necessary from an engineering standpoint to best support the design team throughout the development process. I describe myself as a ‘designer’s developer.’
What is a Designer’s Developer?
As a ‘designer’s developer’ I wear many hats. In addition to developing, I can be a negotiator, detective, design advocate, and co-conspirator during any given project. I help communicate the design team’s intentions, serve as their voice in engineering meetings, help push their ideas forward and generally serve as a bridge between design and engineering. So what exactly does that look like? It means a lot of listening, a lot of building, and often a lot of throwing code away.
Experiment, Explore, and Experience Through Prototyping
In the early stages of a project I spend a better part of my time collaborating closely with designers prototyping various interaction models. Sometimes I build just a couple; sometimes I build as many as 10 or 20. In my mind, during this phase of development my main responsibility is to say ‘yes’ to any and all design requests. Any idea the designers want to test out I’ll build for them with (almost) no argument. In the beginning designers have a wealth of ideas and even more questions. They need to experiment, explore and experience as much as they can to help answer those questions and discover what works and what doesn’t. Prototyping is my way of contributing to this discovery process. The more I prototype, the more the design team learns and the better the end product will be.
Build with a Focus on Detail
When designs become more finalized and engineering begins in earnest I spend more and more time on the nuts and bolts of development: implementing features, sprint planning, fixing bugs etc. I work mainly on front-end features and augment the development team, helping out however I can. I also focus on details; the nuances and smaller moments that go into user experience such as animations, transitions, look and feel, and general polish. Because of time and resource constraints these design details can all too often fall through the cracks. It’s one of my main responsibilities to fill those gaps and ensure the design team’s priorities are met.
Push Back to Push Forward
Being a ‘designer’s developer’ doesn’t mean always implementing everything design wants. Sometimes the designs aren’t technically feasible or are too invasive and destabilizing to the build. It’s never fun pushing back but designers know they can trust me. They know we have the same priorities, that I want the best possible end user experience and will do whatever I can to help realize it.
Embrace Your Interests to Find Your Niche
At the end of the day I’m a developer. I love building applications, devising unique solutions to problems, and sleuthing out the causes of nasty bugs. I respect and strive for the rigor and skill it takes to build a solid and robust application. But at heart I’m a ‘designer’s developer.’ Through supporting the design team I have the opportunity to use code as a tool for exploring a wide array of fresh and original ideas. It’s a real joy and thrill to quickly prototype an idea and see it come to life just to start on a completely different concept the next day. Designers constantly push the envelope and challenge me to push the envelope with them. I also embrace the complex task of bridging the divide that exists, for better or worse, between design and development. Most rewardingly, when all is said and done, I play a key role in creating something useful, enjoyable, and beautiful for people.
It took me a little while to find my niche as a software engineer. I first had to realize not all engineers are cut from the same cloth. Just because I wasn’t terribly excited about encoding algorithms didn’t mean I didn’t have a place in the industry. Next I had to discover what sort of engineering problems I was most interested in and passionate about solving. I had always been drawn to user experience but not until I started working closely with designers and, eventually, within design organizations did I find where I belong.