Design 101 for Developers

We often hear about designers learning how to develop, but what does it take for developers to learn how to design? In this talk from #Pragma Conference 2015, Christopher Downer (of Sketch fame) provides an introductory design curriculum for developers. Anybody can be a designer, and when developers help take on this role, the whole team benefits.

---

Introduction (0:00)

My name is Christopher Downer, and I am a designer. I’ve been working on Mac and iOS apps for about six years. For the past two and a half, I’ve been working on Sketch, which some of you may already know. If you don’t, it’s a vector design tool for the Mac. It’s used for creating icons, interfaces, websites, wireframes, and really anything that ends up on a screen. If that sounds like your type of thing, please check it out!

Should Designers Code? (1:38)

Being a designer, I constantly see articles, blog posts, and Tweets telling me that as a designer, I need to learn how to code, or that I need to learn how to develop applications. I’ve read a few of these articles, and there are definitely valid points there. Designers should, absolutely, be more familiar with the entire design process, and should have an understanding of how things work. It’s a good thing because it will help out the developers they work with. However, I’m going to let you into a bit of a secret: I can’t code.

I do want to know how to code, and I’ve tried to learn so many different times. I’ve used many methods and ways. I tried to learn when I was at university, sitting down one-on-one with a developer, looking at books, and online courses. I tried learning in a variety of different languages as well. I started off looking at JavaScript, before moving on to Python, thinking that would be a bit easier, and even developing natively in Objective-C. Most recently, I had to look at Swift.

When it comes down to it though, developers are super smart and clever people. Me on the other hand, not really. I know what a function is, and I can just about grasp the concept of a loop, but I don’t know what a pragma is. I’ve not given up just yet though, and I will keep trying.

Should Developers Design? (3:28)

A question I don’t often see many people ask is, “Should developers design?” That’s what inspired this talk. I’m not going to tell you that developers need to design everything themselves and ignore their designers, that’s crazy. However, although developers may not be pushing the pixels, they make decisions all the time that shape the outcome of a design.

Strangely enough, I probably learned more about design from developers than I’ve learned about design from designers. They’ve taught me a whole load of things that I would have never even considered when I was starting out, including accessibility and localization, matching color profiles, designing for multiple displays, place holders, handling errors, security, first runs, edge cases, and the list goes on. Before I found out about any of these things, I don’t really think I was designing anything at all. Mostly, I was just making pixels look pretty.

It seems to me that nearly all the developers I’ve worked with are interested in visual and interaction design, which is really great. However, a lot of them seem quite intimidated by it. They may not really know how, or may not too sure how to begin. I hope to dispel some of the myths surrounding design, talk about design in general, share some insights, and get you to perhaps think more like a designer. Hopefully, it will mean you can be less dependent on the designers you work with.

What is Design? (5:37)

I’m going to start with the basics and answer the question, “What is design?” This might seem obvious, but we should draw a distinction between “design,” “UI design,” and “UX design.”

Plainly, UI is the visual stuff and the UX is the interaction, but what about that sweet spot in the middle? Is that design? A lot of people treat UI and UX as two different disciplines, but to me they’re harmonious. I can’t go and design the visual side of things without thinking about how it affects the usability and the interaction. Although UI design, as a term, does refer to the visuals, it is also confusingly the term used to cover the entire design.

What ISN’T Design? (7:00)

You know what design is, but perhaps we can learn a bit more by looking at what design isn’t. First of all, design isn’t a scary, magical process. Designers don’t go work for five minutes and come back with a completed design. There are so many considerations, matters, and problems that designers need to address. Nor is design a phase that kind of runs along and ends before development begins. In fact, design and development run alongside each other in a number of stages. Of course, developers do a whole lot more than just development things, but it’s different for each project, just as it for design.

Your typical designer will start by sketching something out on paper before mocking it up in an app like Sketch, where they transfer what they have on paper onto the screen, creating a higher fidelity type of mock-up. The following stage, which so many designers are doing nowadays, is prototyping. Designers will use apps like Framer or Origami to visualize how the app flows together, and work out the interaction and animations. Afterwards, they iterate on that design, critique it, and review it. They keep on refining it and making it better each time, so that hopefully, when it comes to the implementation and testing side of things, it’s all done. However, as we know, that’s not always the case.

A common misconception of designers is that they need to be artistic. Most people don’t feel like they can go in to start designing something because they can’t draw a straight line, for example. Nobody is born a great designer, just like nobody is born a great artist, which means it’s something that anyone can do. It’s just something that you work at and practice over time.

Finally, design isn’t just a matter of taste. For visual design, this plays a role, of course. But, when it comes down to interaction design, it’s less subjective. There are rules to good design, and even more rules when it comes to user interface design.

Developers Have Design Problems (10:23)

You may not yet be convinced why you need to know more about design. As a developer, you write code and you’re really awesome at it. You may already work with a designer, but if you’re an indie dev or a small company, you might not have one. They might only be available freelance a few hours a week, and they can be pretty expensive to have around all the time. No matter where you work, a designer probably isn’t going to be around all the time. They might be working on different projects, or the developer to designer ratio may be pretty high.

When you’re developing and you come across an issue that needs a design solution but the designer isn’t around to ask, what do you do? Do you wait for them to come back? Do you queue up all the problems that you have and then run it by them when they’re available? Most of the time you can’t. Deadlines tend to be pretty tight and you can’t wait for them, so you need to make a decision right then.

As a developer, you need to fill in the blanks. This might come down to guessing, but that might not be the best choice. You certainly don’t want to leave your design down to guesswork. In the situation when a designer’s been away and comes back to see that developers have designed without them, it often upsets the designer; it means there’s more work for them to do, because they have to undo the damage. In turn, that means more work for the developers, because they have to implement those changes and test them. As for designers, they probably don’t have the time to consider all the nuances of an app, or be aware of edge cases. They’re also less familiar with the app compared to the developer, so they’re frequently less informed to make decisions.

The more informed you are, the more time you’ll save. When you’re well informed about design, you won’t hear your designer telling you: “Can you make the animation smoother?”, or “Move this two pixels to the left.”

Design Rules (13:26)

As I’ve said, design is not a magical proces, and it’s not really a matter of taste. It’s something that is driven by lots of constraints and considerations. A great place to start is Apple’s Human Interface Guidelines. You can get it on iBooks, and it really is a great little guide. It covers a load of basics and principles, and it’s something that I keep coming back to time and time again. It is important to remember the name, however. They’re the Human Interface “Guidelines”, not the “Human Interface Rule Book”. The guidelines are important to know, but not necessarily something you have to follow. The more experienced you are at designing, the easier it is to know when to move away from it.

Consistency (14:35)

When it comes to design, there is no silver bullet or magic trick to make your designs awesome. However, the one small thing that does go a long way is consistency. Is the look or feel consistent within the OS? Is the look of the app consistent between screens? Making sure to achieve consistency is almost like making your own rules. This can be done by setting up style guides or layout grids, but often it is really just as simple as asking yourself, “Is this the same color that I was using in my previous screen?”, “Do these two elements share the same padding?”, or “Do these text boxes align with each other?”

In order to create consistency, you need to train yourself to see consistency. Have the eye of a designer. One common trait you may have noticed among designers is that they’re all quite fussy and meticulous. They obsess over the small details, and they diagnose themselves as obsessive-compulsives. Again, nobody is born with this ability, it’s just something that you pick up over time. Then, suddenly you will notice a row of icons in another app where one icon does not quite line up with the others, or that something is slightly off-center. Once you see those things, you cannot un-see them. It’s a horrible curse. However, when it comes down to your own products and designs, it’s an invaluable skill to have.

Space is your friend (16:39)

You may refer to it as “white space” or “negative space,” but why is it important? Imagine an iPad app designed by developer in Storyboards in Xcode by someone who’s not very design-focused. It may have a standard-looking interface, with a solid UX and no real customization. Likely, it will look messy because the elements are close together and hard to distinguish. How might this be improved?

By increasing the size of the white space around each of the elements, it makes focusing on the content far easier. It will have room to breathe. I may increase the margins, align elements, and even the increase the line height, and it will be renedered more legible. You may end up with less content on the screen, but you could argue that that is a good thing. The less you see, the more you can focus on. People can only typically focus on one thing at any given time. It’s okay for your content to go beyond the fold and off the edges of the screen, just by moving elements around.

Don’t let constraints design for you (19:24)

When you’re thinking about design as a developer, it’s very easy to think, “I’m going to come up with the design solution which is the easiest for me to code.” That’s completely understandable. Back when I was trying to put together a UI in Xcode, I couldn’t implement what I designed, so I did what I knew and made it as simple as possible. On the flip side, however, a lot of designers don’t factor in these kind of limitations and will dream up wacky things that are near impossible to implement. For developers, the knowledge they have can really go into creating tangible designs that don’t feel basic. A lot of the time, they’ll also want to make something that looks and feels great. I’ve worked with designers in the past who have proposed ideas to me that I would have never even thought was possible.

Perhaps the most well-known example of a developer designing a completely new interaction is Pull-To-Refresh by Loren Brichter. I don’t need to explain what Pull-To-Refresh is; you’ve all seen it. It’s in virtually every app that has a timeline or refreshable content, and it’s even in iOS in the Mail application. Loren is one of those magical unicorn people who is not only an amazing developer, but also a really good designer. At the time, he was developing a Twitter client called Tweety. In old Twitter clients, you’d have the Refresh button at the top corner, and you’d scroll up to press Refresh and see what tweets were new. Being a design-focused developer, Loren saw that that kind of behavior and interaction really sucked. He could see how Pull-To-Refresh might work, so he wrote it, shipped it, and the rest is history.

That’s an interaction that no designer alone could think of, because of the developer insight involved. A typical designer wouldn’t know that you could trigger an event just by scrolling or swiping down on the screen.

Avoid system colors (22:10)

This one is perhaps a bit subjective, but the one thing that I see quite frequently is that the colors used in designs made by developers are not very nice. There’s a good reason for this: they use the system’s VGA colors. If a developer wants to use blue in their design, they’ll type in “blue”, or the RGB value 0,0,255. It’s quick, easy, and ugly. If you’re not going to be working with a designer who will tweak this later on, please consider taking the time to tweak it just a little bit.

VGA blue isn’t a blue that you would see anywhere. It’s quite an unnatural color, only something that you’d see on a computer screen. It’s the same blue that you see in the “Blue Screen of Death,” if you’ve had the misfortune to use a Windows computer.

When it comes to colors, there are so many options. For blue, for example, you could choose something less harsh, maybe slightly more green. Even better, use the eyedropper from the color picker to pick a color from a photograph or an image. The options when it comes to colors are endless. Such a simple and straightforward tweak can go a long way into improving how something looks.

Furthermore, text and other elements that appear black aren’t actually (0,0,0) black. They’re more of a very dark gray. One reason for this is simply that it reduces the harshness of contrast of black text against a white background. It works similarly when reversed: if it’s white text on a black background, the text is probably a very light gray, and the black is dark gray.

How it works > how it looks (24:58)

An app with a great experience and a native interface will be a way-better design, although perhaps not visually, than an app with a crappy UX and a really pretty custom UI with flashy animations. Aesthetics are important, but all that “everything should look like a stock application” would be really horrible, and I wouldn’t want to use any apps. Consider all the pros and cons involved with going down that route. Is it a better solution, first of all? Can it still be made accessible? Is it intuitive? Will people know how to use it if they picked it up?

Be boring (25:59)

Honestly, the best solution is often the boring one. Obvious design will beat clever design every single time. It is one of those times where you might have to compromise on the visual side of things just to make it more usable, but in the end, it will be worth it. It’s more of a challenge to design around these types of constraints. Often, I’ll design something I’m really happy with that I think looks pretty, but I’ve forgotten to account for some cases or the feature I may have involved, so I’ve got to add these things to my design. Whilst they’ll be more usable and the feature will be better for it, my design now looks horrible because there are all these extra options and buttons in there. I have to still try my best to make this look good, and make sure everything’s consistent and lines up neatly.

It’s one of those challenges that I love as a designer, because it pushes me. It makes me work hard at trying to make something look good and still be usable.

Ignore trends (27:41)

Look at the front page of Dribbble, then design the exact opposite of what you see. Right now, the two trends are big, bold animations and hamburger buttons. Trends are temporary, and they’ll fade quickly. Strong foundations on the other hand, will be more permanent. They’ll last longer and you’ll app won’t look outdated in three months’ time. And the design will be better for it.

Question everything (28:25)

Be self-critical and ask yourself, “Is this good enough?” It’s quite easy to criticize other people’s work, but it’s a lot harder when it comes to your own. You have to question every element you add. Does it have a place? Does it benefit the screen? You have to keep in mind that less is more. For usability, I like to ask myself, “If I designed this app and gave it to my parents, would they know how to use it?” My parents are certainly not pro-users; they have iPhones, but that’s about it. If they would know how to use the app, then to me, that’s a sign that the design is quite good and quite safe. However, if you had to teach them how to use it, then that’s bad. You can’t teach everybody who downloads your app how to use it personally, so you need to go back to the drawing board.

It’s important to remember that you might know how something works because you’re a developer and a designer and a geek, but you can’t say the same for the Average Joe who’s going to download the app in a wider audience.

The Secrets to Good Design (29:58)

There is no magic trick or silver bullet, but one secret to good design is iteration. You make something and you keep improving it, improving it, improving it, until it’s as good as possible.

For a developer, that’s understandably a hard thing to achieve because your time is already limited enough as it is. However, when I was a younger designer, I always thought that my best idea was my first idea. My first idea wasn’t just something that I would throw out there and then not think about anything else. It’s something that I kept going over in my mind, working out all the pros and cons how something might look, how it might work. By doing that and not sharing my ideas, even the most minor and insignificant ones, that could actually be the spark that ignites the idea in someone else’s mind. By sharing your ideas with other people, getting feedback on those, and then going back to the drawing board, that will undoubtedly improve your design. Iteration is the secret to success that so many of these large companies and startups who are renowned for huge design cultures.

Good design happens when there’s an overlap between designers and developers. The earlier the developer gets involved with the design, the better. If they’re included in design discussions, they’ll have more of a scope of what’s going on. When designers and developers work together, they’ll gain empathy for each other’s vocations. They’ll appreciate the problems that they have to come across, and what type of problems that they have to solve.

Anyone Can Be a Designer! (32:28)

Since iOS 7, I’d like to think that design is a lot less intimidating, especially for developers and people who may not be designers. You don’t need to be a Photoshop pro anymore to create realistic, glossy-looking toolbars with green felt backgrounds. You don’t even need a copy of Photoshop anymore to get into design.

It’s far less visual than it once was, and people now understand that how it works is more important than how something looks. Developers can really hone their craft because they have the time to do so. As we found out, iteration is really key to good design, but if the developers they work with start upping their game and start learning more about design, that, in turn, is going to make designers raise the bar and keep them on their toes. It will encourage them to come out with better work.

Designers vs. Developers (33:47)

Although we like to joke that designers and developers are from two different planets, a lot of us are in this industry for the same reason: to ship great apps and products for real people all around the world. That’s something we mustn’t forget.

Designers need to lead, rather than just going away and designing something. Involve developers more in design decisions. Explain why and how you came up with a solution, rather than just handing them a spec sheet or all the assets. If you do usability testing, involve your developers in that. Developers are super smart, and they’ll be able to quickly learn the differences between good and bad design. If you lead, the developers continue with the design whilst you’re not there, and their work will get better over time.

Recap (35:05)

“Should developers design?” They already do. Every day, they make decisions that shape the outcome of a design. Nor is design a phase that’s parallel to development. It’s something that runs all the way through to the end of the project.

Consistency is incredibly important. This means both visual consistency as well as a consistent experience, be it across your app or on a wider product, or even in the operating system.

Try not to design the easiest thing to code. This is very easy for me to say as someone who doesn’t code what I design, and I’m sure I’ve angered a lot of developers in the past by coming up with ideas that perhaps aren’t so simple to implement. However, in the end, the developers are happy to put the extra work in because they know the product will be better for it.

Design obvious over clever. This will make the app far easier for people to use. It’s going to make it more easily accessible, and by ignoring trends, you’re going to increase the longevity of your design.

Be your own worst critic. Question why you’re adding something to a design, and ask what benefit it serves. By questioning things, it will ultimately lead to a natural iteration as well.

Designers should involve developers in the process. The earlier in a project you do that, the better. Developers will have a greater understanding behind design decisions, and they’ll be able to learn from that, rather than just being handed a finished mock-up or design to go and implement without knowledge or understanding of how the designer got there.

A final thought: A clean UI is like clean code. It’s organized, it’s consistent, and it’s as sparse as it can be whilst still doing everything that’s needed.

Q&A (37:54)

Q: We know in Xcode 6 that they introduced the new vector format images which you can use for different scales and different iPhones and iPads. Do you use it in real life, or do you prefer to draw images for specific resolutions; one, two, or three X?

Christopher: Saving PDFs out is something that, of course, I’ve been wanting to do in Sketch, so the assets are using it so the file size is smaller. You don’t have all these one X, two X, and so on. I think PDFs and vector assets are good things to use if you design them at one X, the smallest size possible on non-retina screens. If it looks good there, then when it comes through the rest of the displays, that’s simply doubling it, so you can guarantee it’s going to look there as well. It seems that a lot of designers nowadays who design at two X, in an odd number of pixels, so when that gets scaled down by half, we do see blurry lines. For saving PDFs, I absolutely recommend that, just be sure to design at the smallest possible resolution, at one X. Then if you scale up, talking about iOS 2, 3, it’ll be fine.