Swift for/with Designers

Developers and designers working together can create the best apps in the world! But we’ve all seen that this collaboration doesn’t always run smoothly. Come learn how new tools like storyboards and Swift can help designers and developers work more closely and produce the best software (and the happiest teams). Designers and developers can be better friends. 💖

---

Working Together as Designers and Developers (0:00)

Swift Language User Group talks tend to focus on the technical aspects of Swift. Swift is fantastic, and it with came new tools that inspired me to discuss the subject of working better with designers as developers, and vice versa.

Initially I planned to discuss all the new tools that surfaced recently for facilitating work, but decided to concentrate on the more practical side: us, the user group, working together.

Most of us, the audience, fall into the categories of developers or designers. Of course I am aware that many people fall somewhere in between these with skills, but for the sake of brevity I will concentrate on the dichotomy between these two roles.

Bridging The Roles of Designers and Developers (1:53)

In the process of making software, designers and developers are responsible for different tasks. On the designer end, we have ideating, and sketching, things that are more abstract. On the other hand, developers concentrate on building and shipping, getting things down to the implementation and pushing software out the door. Obviously, I am glossing over a huge spectrum of activities between these things, and these responsibilities can go back and forth.

In working with designers and developers in teams, we’ll typically have things like this where designers will mark their ideating and sketching territories, while developers define their highly technical territories. This is perfectly natural, but there’s a substantial gap between the two extremes of these roles that is not accounted for; the responsibility to bridge the two isn’t defined by our natural territories. This is probably the prototypical issue in designer/developer relationships that leads to things falling through the cracks. We’re not totally sure what are designers doing and what are developers doing, and these issues are tough to communicate without either technical or design knowledge.

We would like to take this chasm between the two roles and make it go away. Some people would advocate that a designer’s role starts at ideas, moves forward, and ends once it becomes code. Then they hand it off, and it becomes the developer’s job.

However as we look forward, recent tooling changes and a lot of tools outside of Apple’s ecosystem empower us to push the responsibility divider forward. Instead of where code starts, to be where the UI stops. In this scenario, a designer is responsible not just for the static things like image files, but the designer can share that design intent all the way through to some sort of code that is able to run, ideally, which isn’t just some sort of high fidelity mockup. After that, the developer does what a developer does best, which is complex computer science problems, business logic, and other cool tasks of the sort.

Either of these dividers work fine, and there are a million other possibilities. You can divide responsibilities however you’d like as long as the entire process is covered and everyone’s job is as clear as can be. As with all relationships, this issues involves 98% communication. Just talk it out with people and make sure that you’re all cool about what everybody’s doing.

Improving as a Designer (4:54)

On the pure design side, there are people who are not touching any code. They’re working in Sketch, Photoshop, Illustrator, and similar tools including prototyping tools, but not necessarily coding.

My first tip for designers would be to steal from web design. We no longer have one size to design for iOS as we did in 2008. We have four sizes of iPhones, that become eight when turned sideways, along with two iPad sizes all running on a variety of hardware. The web has dealt with this issue for years and emerged with the solution of responsive design. I’d recommend that you adopt these techniques and concepts to help accommodate for the variety of devices running iOS. Although I’m not an expert in the web design field, the more I learn about it the more I find it to be applicable for designing iPhone apps. As we know, if a designer hands a developer a PNG, which can only be one size, it makes their job significantly harder. Don’t make developers guess your intent from one dead PNG. Use the tools of responsive design to show your design intent.

My second recommendation is delving into prototyping. Prototyping allows you to express your design intent not just through PNGs and dead images, but living examples of your ideas that don’t require developers to guess. If you as a designers can take these further and delve into ultra–high fidelity prototypes, you will ease the developer’s job of implementing your design. Pixate has announced (but has yet to ship) code exporting, where you can just make a Pixate prototype and then hit a button, and it generates Swift or Objective-C code which would be pretty awesome - a Dreamweaver for mobile (that might actually be good this time).

Finally, I’d recommend that every iOS designer familiarize themselves with Apple’s HIG - the Human Interface Guidelines. If you’re not super familiar with iOS design, Apple has this rather large handbook of design guidelines. Knowing this is the designer’s responsibility; the developer shouldn’t need to teach the designer what Apple’s design guidelines are. Familiarize yourself with the HIG, familiarize yourself with the design of many apps, and use that to look and think about standards you could use. This helps in case you, for instance, come up with a really unique, novel, or cool concept, but you don’t see it in the HIG or other apps. You may then approach the developer and simply ask off the bat, “Is this possible? And/or will this take three months of one person’s work?” Arming yourself with a lot of knowledge about what’s good and bad techniques in iOS design aids development substantially.

Helping Close the Gap Between Roles (8:41)

To take a step further towards the developer, a designer may learn a few more technical tools to help ship amazing software.

Storyboards have come a long way since Xcode 5, when they were unusable, to now, when they’re actually pretty good. You can almost diff them which is great! Their real power, for people who aren’t really familiar with code, is that they can just take an image and drag it in there. Storyboards’ functionality allows designers to use Xcode itself as a prototyping tool. The benefit of that is that you begin by easily using Apple defaults, but if you are an enterprising designer you could also improve it with your own ideas and tweak details. You can just go and code a custom segue or little custom views, and bit by bit reach further towards control of the implementation of your design details. Even if you don’t want to work with code, storyboards are super powerful anyway.

Alongside storyboards, I would also encourage people to play with Playgrounds. This one even has the benefit of kind of coming from both directions of design and development. For designers learning to code, a playground is really helpful because it’s a safe place to experiment. You don’t have to spin up a whole project, and you don’t need to know what a view controller is. You can just have this safe place to play around and learn to code a little bit at a time.

From the other end, developers who are used to spinning up a whole sandboxing project just to test small ideas can now accomplish this easily in a playground, allowing for rapid iteration and testing small ideas without creating extra, unnecessary projects.

The last one tool I would recommend completes this transition of nontechnical people dabbling in the technical side: IBDesignable. It is almost the ultimate expression of this bridge, where it’s a playground for views where you can just test out ideas, implement them, and then immediately re-renders the results in Interface Builder. Eight months ago at the 12 Apps of Swiftmas, I gave a talk about IBDesignable on this stage, so look there for more information.

Improving as Developers (11:53)

Here are some tricks for developers to be more design-conscious and implement a specific design more accurately and easily.

The Xcode view debugger is a tool that was introduced in Xcode 6. While the app is running in debug mode, you just click on the rectangles icon (in the bottom panel, next to the debugging tools), you get this crazy explosion where you can see all the views. This is really helpful if you’re doing UI debugging to figure out what’s happening and where each of your views are.

If you really like that and you wanna go one step further, there’s Reveal and Spark Inspector. There may be others that I just haven’t managed to hear of yet, but they are pretty similar. Those take this idea of the Xcode view debugger, where you can explode the view hierarchy, and really turn it up so you can modify things at runtime. Reveal and Spark Inspector are essentially the Web Inspector from Chrome and Safari, only for iOS views. They can manipulate view properties while the app is running. This helpfully allows for quick iterating on UI without compiling and re-running every time.

My last bit of advice is involves debugging animations. In the iOS simulator, there is an option called Slow Animations. When you turn it on, it does exactly what you think it will. It makes all the animations in your app really slow, and allows you to pay closer attention to motion details.

Now designers and developers can be friends forever. 💖

Q&A (14:10)

Q: Should designers learn to code? The movement for designers learning to code has proponents and opponents. What are your thoughts about this matter?

Michael: The idea of designers learning to code is great in my opinion. Many of them do so without intending to change careers necessarily, but to have more useful tools in their disposal - auxiliary skills that facilitate the collaboration with developers. An important aspect of these skills is helping communicate ideas better with developers, sharing empathy and a common language. A designer may not know how to implement a segue or the necessary view controller for a design, but with some code knowledge they could at least explain their ideas to and understand developers better. Shared understanding is powerful when working in a team.

About the issue of designers learning to code, the inexplicable flame war between the two camps makes no sense to me. Although I gave the argument for why designer should learn to code, we have specialization for a reason. If everyone needed to learn design and code, it would be more difficult to specialize in either aspects. Nevertheless, there are many benefits for designers learning to code if they want to.

Q: Do you recommend any specific tools for designing animations? How do you recommend communicating about animation between developers and designers?

Michael: This is one of my weaker sides in communication, so I am no expert. The current state of affairs is that everyone just uses After Effects to make a custom animation. However, to help communicate animation, prototyping tools may be invaluable as they help create the more full fidelity animations with values that can be extracted such as animation curves and Bézier paths. For this reason, tools such as Xcode’s Storyboard or tools specific to iOS have an advantage over general prototyping tools like Framer. Because they aim to be native, building and prototyping animations using those tools helps developers do their job.

Q: Are you familiar with Zeplin? It made collaboration between developers and designers a lot easier in my team; what’s your opinion of it?

Michael: I personally haven’t used Zeplin but only heard good things about it. At Realm where I work, the design team works on the website and just builds their ideas so we have less of a need for it.

Q: How do you handle cross-platform designing between iOS and Android? Do you know of any useful tools to work this way?

Michael: I don’t know of any off hand that will go for both of them at the same time. If I’m designing stuff, I just use Sketch a lot of the time. Therefore, if I were doing iOS and Android, I would just have one page full of iOS artboards, and a mirrored page full of Android artboards and then just keep them in sync manually which I agree is not a great process. Same goes for prototyping - I would simply use the same tool for both.

Q: What resources would you recommend for developers who want to learn design?

Michael: I went to grad school for this, and although I learned a lot, it’s a pretty expensive solution. Some people opt for GA programs, and others just teach themselves online as there’s a plethora of tutorials, guides, and books available. This Product Hunt Collection could also be a good resource. However, I’m not personally familiar with many of them.