{"id":11735,"date":"2017-09-06T11:00:26","date_gmt":"2017-09-06T10:00:26","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=11735"},"modified":"2017-09-12T13:23:42","modified_gmt":"2017-09-12T12:23:42","slug":"learning-code-designer-built-trust-team","status":"publish","type":"post","link":"https:\/\/www.shopjessicabuckley.com\/blog\/learning-code-designer-built-trust-team\/","title":{"rendered":"How Learning to Code as a Designer Built Trust on My Team"},"content":{"rendered":"

I\u2019ve 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.<\/em><\/p>\n

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\u200a\u2014\u200aoops I mean loud discussion\u200a\u2014\u200aI 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\u2019t 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.<\/p>\n

\"I had two choices: change the design to match the developer\u2019s suggestion, even though I didn\u2019t fully understand why, or insist it be developed as I originally designed.\"<\/span><\/p>\n

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\u2019t 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\u2019s suggestion, even though I didn\u2019t fully understand why, or insist it be developed as I originally designed. Usually I felt safer choosing the latter, and team relationships suffered.<\/p>\n

\"That dynamic completely changed, though, when I learned how to code for myself.\"<\/span><\/p>\n

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\u2019s San Francisco office and spent my evenings and weekends immersed in the world of iOS development.<\/p>\n

\"Designer<\/a>

I miss you and your incredible affogatos, Sightglass coffee. But I don\u2019t miss your lack of wifi. Why would you make a coffee shop with no wifi\u2026 in SoMa?<\/p><\/div>\n

The bootcamp taught us how to work with XCode\u2019s 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.<\/p>\n

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\u2019m shocked that the app we built in 3 weeks didn\u2019t crash. We were told the class would teach us how to create native prototypes, but by the end, we were writing actual code.<\/p>\n

After that immersive experience, I find I can\u2019t stop thinking about how the interface will be developed as I\u2019m designing it. For example, I\u2019m currently designing a flow that is built off a split view controller. We didn\u2019t learn about that one in class, and I realized I didn\u2019t 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\u2019ve written for a prototype for myself has actually found its way into the app.<\/p>\n

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.<\/p>\n

<\/div>
<\/svg><\/div>

\"The design process has become interlaced with development the whole way through.\"<\/p><\/span><\/blockquote>\n

\"I\u2019ve found that when I am able to speak the same language as my developers, we trust each other more.\"<\/span><\/p>\n

Sometimes trust comes naturally in a working relationship, but let\u2019s be honest: sometimes it doesn\u2019t. I\u2019ve found there\u2019s 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\u2019s disciplines. And now when my developer points out that there\u2019s an opportunity to use a native control, I\u2019m delighted.<\/p>\n

So if you\u2019re a designer who works with developers, take some time to learn about your developer\u2019s world. And if you\u2019re a developer, try your hand at designing an interface that solves a user\u2019s need. Your skills will grow\u2026 and so will your empathy.<\/p>\n

<\/div>
<\/svg><\/div>

\"When you have a bedrock foundation of trust in your teams, innovation and collaboration have room to flourish.\"<\/p><\/span><\/blockquote>\n

This article was originally published on Adey's Medium page<\/a>. <\/em><\/p>\n

\n
\n
\n \"Design\n <\/div>\n
\n
\n

\n Sign up to the Newsletter <\/h2>\n<\/p><\/div>\n
\n

\n Get notified of the latest product updates and news at Marvel.<\/h3>\n<\/p><\/div>\n
\n Sign up <\/div>\n<\/p><\/div>\n
\n \"Design\n <\/div>\n<\/div>\n<\/section>\n","protected":false},"excerpt":{"rendered":"

I\u2019ve 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… Read More ￫<\/a><\/p>\n","protected":false},"author":167,"featured_media":11739,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":["post-11735","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-viewpoint"],"acf":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\n\n\t\n