(upbeat digital music) - Hi, I'm Diana.

I want to help you answer this question.

Should I really bother learning to code? I can be found on Twitter @DiDoesDigital and that's where I'll be posting slides and links later on. As John mentioned, I'm a product designer.

I work at Culture Amp.

Our product is an employee feedback platform that lets companies like Airbnb and Netflix collect, understand, and act on employee feedback. I've been described as one of Culture Amp's codier designers, but that's not where I started out.

I started studying accounting and IT in new media arts and I didn't know what I wanted to do.

I just figured that business and computers and communication would be important.

So in the last decade in the tech industry I've had a few different roles mostly around product and design and UX.

As a tech editor I learned a lot about code without ever really writing it.

So I've never actually worked as a full-time engineer. However, I have found a way to use it in my design workflow. Today I want to share a little about how you can answer for yourself, should I really bother learning to code, by looking at design roles and the evolving nature of design roles.

Three ways to use code in design and where to go next if code interests you as much as it does me.

So we actually are gonna ask a question. (laughs) Who's heard the argument before, should designers learn to code? Yeah, most of the room.

(laughing) Who's heard an argument for how much code? Wow.

Only two, three people? That's gonna make my job easier 'cause that's what I'd like to tackle today. We hear a lot of things about what designers should do. Graphic designers should learn UX design and UX designers should embrace data and customer experience, and writing and social media and business, and also code.

And despite all of the things that we hear about what we should do, I have actually felt a lot of resistance over the years to this one.

The argument is that designers that code are unicorns. They're some kind of mythical creature that doesn't really exist.

That's not true.

Theoretically because you would be spending your time on multiple things, you can't be as good at both. But you can be, and even if you aren't, you can use a little bit of both in each other. So on that note, how can you use them together in a role? The first thing to note is that this, choosing between design or code is a false dichotomy. It's not as simple as that.

It's not one or the other.

For example, in InVision's product design report from 2016 they found 87% of all designers prototyped during their design process.

And you might use clickable prototypes like InVision or something slightly more interactive and blended towards like Framer.

Or you might use code itself to create a prototype. There are other unicorn skills in John Mader's tech in design and tech report, for example.

He emphasised writing and the importance of writing for design.

And so we've seen the rise of the role of the UX writer or product writer and things like chat bots, smart home automation, voice interfaces, creating more attention on writing for designers. For all of these things, every minute that you spend on one there is an opportunity cost.

That means you're not spending time on all of the other things that you do as a designer. When you're trying to decide how to spend your time improving different skills, it's not enough to think about your own skills because no one works alone.

Even if you're a freelancer working privately for yourself, you still have customers and you have your peers in this room and you have a whole industry around you. So it's worth thinking about the opportunity cost for both you and your team.

How can you work together to take advantage of everyone's different skill sets.

Even if you aren't practising all of these different skills all the time, the more overlap there is between your skills, the easier it is to communicate.

So having that fluency about what everyone does and how it all fits together is really valuable. There is value in fluency about code for talking with engineers, but also with artificial intelligence.

For understanding systems.

We're seeing an increase in the number of decisions that are informed by machine learning systems, for example. In turn, this might mean that in the future we spend more time on things like data science and visualisations.

And hopefully more time on inclusive design because we need to train those systems to offset our biases and to try and counteract the issues that have led to the toxic tech that we've heard about earlier today.

I would suggest that however you figure out your role and how you spend your time on these different skills, that you coach people on your process.

By inviting people into your process you can start to explain where the edges of your role are and how that might differ from someone else's. Particularly, I think we're all fairly familiar with the idea of explaining that design is more than just eye candy.

We do want to make things functional and usable and valuable.

I find a useful place to draw the line on this is that I don't ship code to production.

So that is to say that I use code in my role, but I'm not the one responsible for delivering a working website at the end of the day.

And that can be really crucial for employers and clients to understand.

Not something you want to get mixed up.

So that's a little about the evolving role of the designer. If you do want to increase your fluency in code or in any of these other skills, I would suggest trying to see if you can fit it into your design process itself.

So we'll look at three ways to use code in design. First, designing in the browser.

Second, prototyping.

And finally, on personal projects.

So first up, designing in the browser.

There's this magical thing.

A document.designMode that you can put into most browsers in the developer tools and it will turn your website or any website into something editable.

So after you've turned it on, all you have to do is enter that text and hit Enter. Nothing too complicated.

You can start editing the text anywhere on the interface and this is really handy for just seeing if it will fit. It's handy in responsive design.

You can actually move the browser around and see if it does still fit.

If you conclude it doesn't, you can change the text until it does.

You can take this a little further if you learn just a little bit of CSS, you can start to tweak alignment and colours and typography, things like that.

And that can actually supplement your existing design workflow in an interesting way.

After you've put together a new interface like this in the browser you can take a screenshot and drag it into your existing design tool of choice. In my case Sketch.

And continue on with your usual work.

So this fits into a larger flow, a larger prototype. I find this handy for things like tables and lists and fiddly repeatable elements that are difficult to do in the traditional design tools. That itself might change in the coming years as design tools get more powerful, but knowing how they work in code is really valuable for figuring out if this is complicated and informing our design tools themselves.

Another way that you can improve your fluency in code while using it in your design workflow is in prototyping. Typically in prototyping you chase after the thing you have the most uncertainty about or the biggest risk, potentially.

In this case I knew I had five or six elements I wanted to animate and I wasn't sure if the browser would be fast enough.

If it would be smooth enough.

If it would be distracting.

I also had a hunch about a potential usability problem with this interface and my employee, my colleague hit this in about two minutes. The prototype itself managed to prove that yes, the animations could keep up, but I needed to rethink the interaction.

And I could take the interaction part back to Sketch and keep designing, but I know the animation is up to scratch.

In this case I'm familiar with code so this is a reasonably fast process for me, but it's important to balance speed and fidelity. If you can do it very very quickly in code, then great. If not, you might need to consider something else and only use as much realism as you need.

I wouldn't jump to code if I didn't need animation and interactivity and hover states are needed to really test those things.

So another possibility is personal projects. About two years ago I heard this idea of a trickle list from a book called Being Geek by Michael Lopp. It's a little like a bullet journal.

He tracks a number of activities each day and just marks whether he's done it or not. Over the course of a longer period of time, he can see the patterns and trends.

He doesn't do things he necessarily wants to keep an eye on every day, but he tracks high value or high potential activities like hallway conversations.

So he knows that most of the time when he has a hallway conversation with his coworkers that it's small talk.

It's pleasantries.

But occasionally something phenomenal will land on his desk and he'll be really glad that he had made himself available in that way to discover new information about what was happening inside his organisation. And I was intrigued by the idea, and I started using this for my own reasons. To balance the nitty gritty of project management details with trying to keep an eye on the bigger picture. After a couple of years, I've moved apartments and I didn't know where to put it anymore.

So I decided to take it digital.

So I built this for myself and these are the things I try to keep track of. Waking up early and exercise, and all those good things. And I push a button every day to say if I've done it or not and then reset it at the end of the day.

So I can start again fresh.

Over time I take screen shots so that I can keep track of it and this is the photo's app on my phone and it shows over time the shape of how I'm spending my days.

One way I could've approached this is to actually build that feature into the app itself.

But I would suggest coding what you can and faking everything else.

That kept it really simple.

That meant that I could actually build this out in a weekend and I had something that gives me personal satisfaction. And I don't need to add all the bells and whistles. When I was digging into it I also wondered about how I'm showing that these buttons are pressed. I'm only showing them with colour.

So anyone using assistive technology like a screen reader, for example, won't know that the wake up button has been pressed here. Or that I have worked on my conference talk this morning. So I dug into it and learned about this thing called aria-pressed.

It turns out that this, you don't need to know the details, but I found it really handy that it exists. It lets me turn any regular button into a toggle button. So if wake up were pressed, it would say wake up, selected, toggle button. And then if exercise was not pressed, it would say exercise, toggle button.

And I don't need to write specific copy for the screen reader to know what that says. Normally I would provide a text alternative to something that's only shown with colour. So this means that I have an idea of how to approach this in the future when I'm using this for, essentially, real projects. This, however, gives me immediate value.

I could've handled that a bunch of different ways, but I also decided to build it myself in a specific programming language that Culture Amp engineers use that I'd never used before. It happens to be Elm, if anyone's familiar. And I wanted to know how it behaved and what the limitations were of this and really just to understand the language of how they spoke about this language.

I learned that I don't want to use it anymore. It requires a lot of upfront planning and that's kind of counter to what I use code for as a designer.

I want to try things out.

I want to test things and prototype and move quickly. I'm not worried about how robust and maintainable this is long-term. I want to get results for myself as quickly as possible and to get new information as quickly as possible. But that does give me a bit of an understanding of what our engineers are working with.

So if you're interested in learning a little more about using design and code together, I'd suggest starting with Don't Fear the Internet by Jessica Hische & Russ Maschmeyer.

They do a short video series on the basics of web pages and how they hang together.

The Elements of Typographic Style Applied to the Web. This covers some classic typographic principles, but also how to build them on the internet. So you can start to play with styles and that lets you design in the browser, which we saw a little of earlier.

That tutorial as well gives you a good idea of how to start tinkering, and you can see where that leads for you.

Maybe you find a different way that code can fit into your design process.

If you learn a little more code and want to take it a bit further, I'd suggest trying out prototyping and seeing if you can blend your tools together. Particularly, you can use a Sketch prototype and a code prototype together, which has interesting results.

And definitely try building your own passion projects. I mean, that might be an app for yourself that solves a problem in your life.

It might be a newsletter or personal portfolio, but it gives you an opportunity to play with things and to take advantage of keeping up to date with different skills and technology without necessarily needing to go too deep in it. But give yourself immediate value anyway.

And on a similar note, tweak your design tools. Sketch plugins are mostly built in JavaScript and that tends to be the coding language of choice for most designers. So you can actually tweak existing plugins and if you don't like the colours of the guides that they use, or something like that, you can change it. So we're coming up to the key takeaway slide. This is your opportunity to take a picture. This will all be online later at DiDoesDigital.com and I will tweet out links.

And the articles that you saw earlier, for example, the headlines about all the things designers should do I can send links to those as well.

So just to recap, design or code is a false dichotomy. There are lots of other skills that we use as designers. There's an opportunity cost both for yourself and for your team.

And there's value in fluency even without doing any actual code.

You can design in the browser with just a little bit of code or almost none. And if you code for prototyping, balance speed and fidelity and only build as much as you need for realism. When you code for yourself, code for immediate value and fake everything else. So when you answer for yourself should you really bother learning to code? I hope you ask the better question, how much code should I learn? And I hope you consider the possibilities for using code in design.

Thanks.

(applause) (upbeat digital music)