I’ve been designing in the iOS space for the past few years, and sometimes there was friction at the handoff between design and development. Everything changed when I learned how to code in Swift.
Fresh out of art school, my design process looked something like this: design an interface, get my art director to review it, update it, get my creative director to review it, update it, and get client sign off. Oh and then hand it off to the developers who will be implementing the design. I can distinctly remember a fight — oops I mean loud discussion — I had with one developer who was suggesting we use a native iOS control after I had already designed a fully custom control. I was under the impression that real designers can’t depend on iOS native controls. That would be cheating. And by that point, my involvement in the design was over. There was little room for feedback from the development team.
"I had two choices: change the design to match the developer’s suggestion, even though I didn’t fully understand why, or insist it be developed as I originally designed."
When my developers gave me feedback that one of my designs was difficult to code, I would always listen intently to their suggestions. But in the back of my mind, I always wondered: are they just saying that because they don’t want to put in extra effort or is it more serious? I never could be sure. I had two choices: change the design to match the developer’s suggestion, even though I didn’t fully understand why, or insist it be developed as I originally designed. Usually I felt safer choosing the latter, and team relationships suffered.
"That dynamic completely changed, though, when I learned how to code for myself."
Last fall, I applied to participate in an iOS bootcamp. From October to December, I lived in the city of San Francisco, worked my regular day job from Capital One’s San Francisco office and spent my evenings and weekends immersed in the world of iOS development.
I miss you and your incredible affogatos, Sightglass coffee. But I don’t miss your lack of wifi. Why would you make a coffee shop with no wifi… in SoMa?
The bootcamp taught us how to work with XCode’s storyboards as much as possible to build native prototypes. Every week we learned a new concept in development, and by the end of the class, we were able to build a fully functional app.
My project was an iPhone app that would pair you with a random coworker for lunch. It actually worked! Looking back at the code, I’m shocked that the app we built in 3 weeks didn’t crash. We were told the class would teach us how to create native prototypes, but by the end, we were writing actual code.
After that immersive experience, I find I can’t stop thinking about how the interface will be developed as I’m designing it. For example, I’m currently designing a flow that is built off a split view controller. We didn’t learn about that one in class, and I realized I didn’t know enough about how that control worked to feel comfortable designing for it. Thanks to the iOS bootcamp, I had a working knowledge of Swift, so I spent a few evenings to build my own split view controller. I find myself doing more and more exercises like these to inform my design decisions. In a few instances, the code I’ve written for a prototype for myself has actually found its way into the app.
But the biggest difference is how I communicate with my team. Now I seek out my developers feedback as early as possible, because I find their opinions instrumental to my design process. No longer finished with the hand off, the design process has become interlaced with development the whole way through.
"The design process has become interlaced with development the whole way through."
"I’ve found that when I am able to speak the same language as my developers, we trust each other more."
Sometimes trust comes naturally in a working relationship, but let’s be honest: sometimes it doesn’t. I’ve found there’s a fundamental shift that happens when my developers know that I deeply respect their craft. I appreciate the beauty in a perfectly efficient function, and a shared passion for clean code. We are able to build trust more quickly when we have a working knowledge and respect for each other’s disciplines. And now when my developer points out that there’s an opportunity to use a native control, I’m delighted.
So if you’re a designer who works with developers, take some time to learn about your developer’s world. And if you’re a developer, try your hand at designing an interface that solves a user’s need. Your skills will grow… and so will your empathy.
"When you have a bedrock foundation of trust in your teams, innovation and collaboration have room to flourish."
This article was originally published on Adey's Medium page.
Sign up to the Newsletter
Get notified of the latest product updates and news at Marvel.
