Getting designers working closely with developers has many benefits. In this talk from try! Swift, Helen Holmes shows how to get designers into your code base by explaining the engineering architectural decisions you can make to make your app designs improve exponentially.

---

Introduction (00:00)

When I started planning this talk, I wanted to call it: “10 things you can do in Xcode without code”. But, why would a room full of intelligent iOS engineers want to do things without code? Instead, the talk I want to give is: 10 ways to get designers into your Swift codebase.

My name is Helen, and I am a designer, I work at Mozilla Firefox. I am part of the developer tools team, I help design tools that web developers use up to eight hours a day, almost every day. I am fairly new to the team and that is evident when you look at the tools themselves. This is unfortunate because there are many awesome projects in the world that suffer from a similar affliction. That is to say: they can benefit from having a designer. But it would need to be a designer who understood code in order to even get started. It is a hard problem to solve, because big codebases can be scary.

Should We Have a Designer in Our Codebase? (02:44)

Firefox, for example, takes much setup time, an hour and a half build and getting used to a complex bug tracking system to even get started. Even if our codebase is not scary, code can be scary, even programs can be scary. All of you are used to Xcode, and Xcode does not look scary to you any more. But maybe After Effects does, or Photoshop, or even Microsoft Word does. When developer tools started, they did not have a designer.

Because of this, the tools were ugly. Sometimes they would get a designer on loan for a bit from somewhere else in Firefox, but never for very long. When they finally had the chance to get a designer, they knew they needed a designer who understood web development, and one who could ship code herself. After hiring a one, it has been a learning experience for all of us, as we have learned what has been successful for getting a designer into our codebase and designing with code.

We now know that Firefox thought it would be a good idea to have a designer in their codebase. But you might be asking, should we have a designer in our codebase? If this is a question you are looking to answer for your team, let’s go over the pros and lets go over the cons, and the architecture changes you need to implement for it to be a success, not only for your product, but your engineers, health of the team and the designer.

Pros (03:21)

At the most basic level, having a designer is better than no designer. It is a designers job to think through visuals or user experience of an application, often both. If you want a beautiful well thought out app, a designer can help you with that process.

Secondly, having a designer in your codebase gives engineers an expert to pose questions to, specific to your app and your needs. It can be difficult for a designer to understand the problems that an engineer often needs to think about when it comes to user experience, because they are in a different head space. This is not true when they are in your codebase, it is also faster than having your engineers ask for assets or help from engineers on different teams within your company.

As designers on other teams often need time to ramp up and properly understand the problem. Having a designer in your codebase, understanding engineers problems, allows your engineers to improve the baseline of everything they produce. Even if they do not have access to fully fledged mock-ups.

Most importantly, having a designer in your codebase destroys the natural disconnect between a design program and the actual app. By running, playing with and building some of the app itself designers can give you better feedback for all of the scenarios your app will run into, not just some of them. This is called designing for real life scenarios.

Cons (05:06)

The cons for bringing a designer are much more about time. The decision you make to bring on a designer into your codebase means that you will need to make changes for the designer to be successful. This means engineering time through architecture changes and mentorship. In the end you will probably find that your mileage will vary. Each team is different, each person on your team is different. The needs and resources that each team has is different.

In order to understand if good design is greater than time for your team, lets go back to the actual how of bringing a designer into your codebase. We come back to the main title: 10 ways to get designers in your Swift codebase.

1. You will need to get a designer who is interested in designing with code. Designers you could pull into your codebase could be anywhere, from fully fledged UI engineer to a code novice. At every level, in order to get the benefits of a designer in your codebase, you need to have a designer who wants to learn and is willing to put in the effort to design with code. Everyone in this room knows that coding is not easy, and learning to code involves much work. Getting the benefits of a designer in your code-base is only possible if you have a designer who is impassioned about it.

2. You need to have bandwidth on your team for mentorship. Your designer will need, and should have, mentorship. Even with an impassioned designer you will need to have bandwidth on your team to mentor that designer, answer start-up questions and do more intensive code reviews. As we covered earlier, most designers fall in a spectrum, anywhere from being an engineer themselves, to being a complete novice, you will need people on your team to handle those eventualities. Not to mention that Xcode is a daunting program. Once you have found a designer and you have cleared up time on your team for mentorship, there are changes that would be hugely beneficial to implement.

3. The first is new storyboards. There is the argument whether or not storyboards are best for your team and your project. XML is difficult to version control and that should not be dismissed, and there is overhead to ensuring that your storyboards do not become corrupted. However, using storyboards gives a fabulous UX overview of your project. Maintaining well designed storyboards is a great way not only to onboard designers into your codebase, who will benefit in the beginning a great deal from Xcode’s GUI features as they ramp up, but also give new engineers to your project a better holistic understanding of your whole application.

4. You should switch to using auto layout. Many developers prefer to do layout programmatically; however, if your app can be done with auto layout, you should consider it, for the same reasons you should use storyboards. It allows you to set constraints in a way that new developers and designers in your codebase can see very easily without a build step, shortening the feedback loop between design changes and implementation.

5. You should set up IBDesignables. They allow you to see a variety of visual changes in your storyboards without having a build step. They are relatively easy to get into your code-base, and worth it for any designer looking to change things (e.g. border width and color, border radius). Again, this is all about shortening the feedback loop between making visual changes. The designer in the codebase will make many small incremental changes to the UI, not having to build for each and every change will make a huge difference in their productivity. Storyboards, Auto Layout and IBDesignables are all engineering tasks, but there are things you should ask of your designer too, to help them get up to speed and more comfortable in Xcode faster.

6. The first of this is encourage your designer to switch to Sketch. Sketch is a design program from Bohemian Coding that many designers have fallen in love with, because it strips away the bloat from the Adobe programs. I ❤️ it because if you compare Sketch and Xcode’s storyboard view you will notice they are similar. Using Sketch instead of Adobe programs will help get your designer into the swing of using Xcode more quickly. The two programs were designed to go together with the same mapped key commands and export settings that work magically with Xcode’s asset requirements. Plug-ins for Sketch can be written in Swift, Objective-C or JavaScript and a slew of preexisting plug-ins already exist on GitHub. This means that you and your designer have opportunities to create useful workflows for your team. After implementing these changes to your codebase and introducing a new person to your team, there are still ways to improve how your engineers and your designer work together, in the codebase.

7. The first of which is work with your designers when they ask you for things. Inevitably your designers will ask you for libraries, frameworks and other things they believe will make their jobs easier. Engineers have these tools too, do not brush off your designers engineering requests because they are a designer. Instead work with them to understand the problem they are trying to solve by using the framework, and then slot in time for research, planning and building into your priorities for your project, the same way you would for engineering requests.

8. Do not leave your designer high and dry. Different from solely mentorship, it is important to regularly check in with your designer, to understand what their struggles are in your codebase when it comes to completing things. Everyone is different, some people have no fear of coming and asking when they do not understand something, and others not. If your designer is unused to designing with code, you may find they are quiet and fearful of asking questions, on the belief that it will bother members of your team. Instead encourage your designer to ask questions and schedule check-ins to make sure they are not struggling in silence.

9. Along the same lines, getting a designer into your codebase is similar to adding a new engineer. You should put time into your documentation. Actually, even more than a new engineer, who might be able to put the pieces together by rooting through the codebase. A designer will especially benefit from higher level code design documentation and inline comments. This is good practice anyway, in the sprints while your designer is gearing up it is worth it to put extra time into your documentation. Ask your designer to keep their own work log on things they discover to either fold into your team’s documentation or just for their personal use as well as they learn new things.

10. The time to get a designer into your project is when you have time to be lighthearted. A designer can be a beginner’s mind in your code-base, it is an opportunity for your engineers to grow their eye for good design, graphic and interaction. And a good time for your designers to learn how difficult building the mock-ups they provide your engineers actually is. A designer can ask why in places, where your engineers might not wish to, helping you identify where in your code-base you might have obfuscated problems. A designer in your codebase means better and better interaction design from your designers as they come to learn that designs are not flat but touched and moved and interacted, and are forced to think about real life applications.

Positive Environment (15:23)

Your engineers get better and better about thinking through UX problems, more intelligently and generating better looking defaults when we move beyond the constraints of a perfectly fleshed out mock-up, everyone learns, but in a learning environment, to be successful, it needs to be a calm one, a positive one. If you want to reap the benefits of having a designer in your codebase, you need to do it at a moment when you think everyone can be successful. And it is worth planning the moment out, to one where your engineers and designers will not be unduly stressed.

A poor relationship between your designers and your engineers can cause stress, every time you receive a mock-up your engineers groan that designers do not get it. Every time a designer speaks with an engineer they get annoyed because, once again, they are told that a design is impossible to build. Getting a designer into your codebase eliminates the stress. The designer becomes a member of the team. The designer learns that some of their designs are impossible to build; now they know because they have tried to build them. Having a designer in your codebase means that you no longer need to worry about wrong colors, or fonts, or other details that have been lost between the PDF of a design and the app itself. Instead you now have a person on your team who is the owner for those particular problems. Having a designer means you can stress less.

At Firefox it has been a learning experience for all of us, we believe that it is had a positive impact on our product which has made us very excited about Firefox devtools future. I can only hope that what we have learned benefits you, your team and your products in order to can make something truly beautifully designed.

Thank you very much to the conference organizers for having me, and thank you all very much for listening and your time. Please ask me your questions on Twitter.

Q&A (16:32)

Q: Would you consider a codebase that is not friendly for designers getting involved and being a part of it to be a code smell?

Helen: I think that code smell can definitely make a codebase very hard to get into. I know that no one likes to write code that is smelly, bad code, no one tries to write bad code. Trying to maintain good, clean code will make it easier for a designer to get into the codebase. But, because it is inevitable that sometimes you will write code that, for whatever reason, feels hackish, as long as you keep good documentation there is no reason that a designer could not operate in what is a very complex, somewhat smelly app.

Q: How do you suggest introducing a developer to Sketch, when, say from Photoshop? I get pushback when I mention Sketch.

Helen: I think that particularly if you are working on iPhone applications, the fact that all of the key commands map to storyboards is a helpful reason to do it. Another good reason is price, Photoshop costs about $600, $600 USD, and Sketch only costs 70 USD, which is a big price difference. In general it is always hard to convince people to try something new, it helps if you are just very positive and show them the cool things that you are making in Sketch. And slowly but surely win them over with cool things you have made.

Q: Do you have any idea on how to collaborate with the workers, the designers, or animation?

Helen: I think it helps if you look at animations together with your designer. Animation is difficult because it can be hard to describe in words an animation, we use words such as pop, sizzle, swoosh. But they do not mean very much unless you are looking at an animation swooshing. It helps if you look at, there is Spring, I believe, A library, if you look at it together, and look at animations and have a shared language for the animation that your designer wants you will get better results.

Q: Great talk, I can very much side with that. However, would you argue that it is better to start directly with Swift or to work with prototyping tools because many of those are more visually orientated, and they teach you logic (and stuff like that). Once a designer understands logic they can start getting into the engineering aspects. But there is, again, under the ramp up cycle. I do not know if you have had any personal experience with this?

Helen: I have used both code and I have used prototyping tools. I personally prefer just coding, because ultimately, many prototyping tools are difficult to learn anyway, and if it is going to be very hard to learn, you might as well write code. That is how I feel about it, I think that other designers will give you different answers to that. It depends from designer to designer. But I think that particularly if your app is using auto layouts, storyboards, IBDesignables, that gives visual feedback, there is enough there that a designer does not feel they have been thrown into a world of plain text, which is scary. Instead it gives some visual feedback.