Developing interfaces: Developers are the new designers
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 163 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/49670 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201511 / 163
6
13
16
17
18
19
20
21
22
25
28
29
30
31
40
41
44
45
49
51
52
53
54
55
57
58
60
61
71
74
75
76
78
84
85
91
92
93
94
95
96
98
99
100
105
106
107
112
115
116
117
118
122
123
124
125
127
128
129
130
131
132
133
135
136
142
144
150
151
153
155
156
157
159
160
00:00
Shared memoryMobile appSoftware developerPower (physics)Point (geometry)Field (computer science)Translation (relic)Interface (computing)Cartesian coordinate systemSign (mathematics)Focus (optics)Right angleProduct (business)Military baseQuicksortWebsiteComputer virus
02:17
Web 2.0Different (Kate Ryan album)Interface (computing)Mobile appBuildingBlock (periodic table)Data storage deviceXMLUML
03:09
StatisticsLocal GroupSoftware developerFocus (optics)Term (mathematics)Shared memoryQuantum stateSign (mathematics)Interface (computing)JSONXMLUML
04:36
Interface (computing)Interface (computing)Interface (computing)Product (business)Software developerCodePoint (geometry)Dependent and independent variablesBuildingWebsiteSinc functionTerm (mathematics)Focus (optics)Interface (computing)JSONUML
06:36
Software developerFeedbackInterface (computing)Process (computing)WebsiteMereologyTouchscreenAmsterdam Ordnance DatumTwitterData miningDependent and independent variablesMobile appComputer animation
08:02
Group actionLine (geometry)FeedbackSoftware developerMessage passingState of matterJSONXMLUML
08:56
Message passingTask (computing)Dependent and independent variablesComputer animation
09:39
MereologyMultiplication sign1 (number)Imaginary numberSoftware developerMobile appPosition operatorHydraulic jump
10:43
Rule of inferenceExpressionMassProgrammer (hardware)JSONXMLUML
11:10
LinearizationSoftware developerMultiplication signProcess (computing)Computer animation
11:39
Software developerProcess (computing)Process (computing)FeedbackLine (geometry)Level (video gaming)JSON
12:56
Coma BerenicesRight angleGoogolMereologyPrototypeSpecial unitary groupDistanceCausalityInheritance (object-oriented programming)Cue sportsSoftware testingFeedbackCycle (graph theory)Perspective (visual)Lattice (order)Software developerSign (mathematics)Water vaporMultiplication signLine (geometry)Data management2 (number)Integrated development environmentTerm (mathematics)VotingOnline helpProduct (business)Endliche ModelltheorieGoodness of fitFrame problemWordAuthorizationDifferent (Kate Ryan album)Interface (computing)Range (statistics)Process (computing)MathematicsFerry CorstenType theoryCoefficient of determinationQuicksortEntire functionInterface (computing)JSONXMLUML
20:48
Sign (mathematics)Computer fileIntegrated development environmentGoodness of fitNP-hardTouchscreenFeedbackSpecial unitary groupDigital photographyMathematicsDifferent (Kate Ryan album)Software development kitJSONXMLUML
22:32
WebsiteAcoustic shadowSpecial unitary groupGraph coloringProcess (computing)Hand fanSoftware developerComputer animation
23:00
FeedbackComputer fileSoftware developerSpecial unitary groupJSON
23:29
Computer-generated imagerySign (mathematics)Multiplication signPower (physics)QuicksortState of matterCartesian coordinate systemEvent horizonTouchscreenExterior algebraCollaborationismMedical imagingSoftware developerSoftware testingFeedbackComputer fileVotingVariable (mathematics)Mobile appBitAxiom of choiceExploit (computer security)Right angleSpecial unitary groupFachwerkArchitectureRow (database)DampingMereologyScripting languageSet (mathematics)Code
29:05
SpacetimeMiniDiscMedical imagingFacebookMultiplication signFeedbackPRINCE2DistanceSoftware developerRight angleComputer animation
30:07
Interface (computing)Computer animationProgram flowchart
30:43
JSON
Transcript: English(auto-generated)
00:00
Okay. Hello. Welcome to Developing Interfaces, or how we guys can be the new designers. So that so many people are concerned about or engaged in design here, that's really great. This is me, if you can't see me here that well.
00:24
I'm a developer, and I started developing stuff and creating stuff when I was in my teen years. I started creating websites and small stuff. And what I liked about that was seeing people use those kind of websites.
00:45
And that made me think that maybe design was something I should do instead, because that's more of the looks and feel of it, right? And I can make something look cool. So I dribbled a little in design and more in development, and I thought both of them are cool, because they complement each other.
01:02
They are two things you need to create something valuable for a user. So I basically stuck that path all the way, and I'm in the middle between design and development. So I work at a small company that's based out of Washington. It's called Microsoft.
01:25
Oh, there you go. And we have a development center here in Norway, where we develop products, not just SharePoint support or translations. And the cool thing about working at Microsoft is that I can have a Mac,
01:43
because we develop stuff for these kind of things, iPhones. At least our team does that. And it's really cool to see inside of Microsoft what we are building now when it comes to products and having this really focused on product focus and user focus,
02:02
which we have with all these small apps we're making now. I think you guys are going to be impressed of what's coming the next couple of months or even years when it comes to small applications from Microsoft. And also we're creating something that's called Delve.
02:20
We created just a couple of blocks from here in Torregata, and it's really cool. And we created it on iPhone, Android, web, everything. But I'm not going to talk that much about what we are doing. I'm going to talk about what I know, because I've been doing a lot of these kind of interface stuff for a while now.
02:46
I moved to Oslo and started making iPhone apps right after the first iPhone came out with the App Store. And since it was a really huge demand for that, I was hired by a lot of different companies
03:01
and started building apps and building stuff that users could actually interact with. And so I worked with a lot of these big companies in Norway and helped them create user focus and things that are going in the user's hand.
03:21
And all of these share one thing, and that is that they have a really huge focus on the user. So I'm going to talk about the design today when it comes to all of those teams I worked at and how I see they're doing design and development side by side
03:41
and how we can do that better and how we can, all of us, do better design as developers. How many of you guys are designers? Some? Developers? How many of you guys are making something that users use? Exactly.
04:08
And design is really a strange term because it can mean a lot of stuff. It can mean photography, it can mean colors, it can mean UX. For example, if you search for design in Google, you end up with this picture,
04:23
which I feel represents some of how a lot of developers look at design, just a layer on top of what they're making and this glossy stuff. But let's talk about interfaces, the stuff we're actually building on the UI layer.
04:52
Tom Cruise is really good at using these kind of interfaces. I'm not talking about this exactly in the future kind of interface.
05:03
I'm talking about what we're making today in terms of websites, simple apps, all this kind of stuff. When I ask you guys if you're making a product, and I think you're a designer then. I'm not trying to trash the designers here, but for me a designer is someone who makes a product
05:23
and contributes to that. And I'm a designer since I'm making interfaces. That's how I see it at least. All of these great teams I worked at, there were some that were okay.
05:42
And I started looking at what made these teams great and what made these other teams okay. And it was a lot of that in how developers and designers work together. Because the great interface developers, they were responsible for what they were making.
06:04
They really cared deeply about the product they contributed to, and they were really detail-focused. And all of those points are something you can make about a great developer who writes great code as well.
06:22
You need to be responsible, you need to care deeply about your code, and you need to be detail-focused. And for me this goes into the responsibility of what we are creating.
06:40
And I want you guys to walk out of here today to try to be more responsible for everything we are making. You as developers are just as responsible for making something useful as the designers. Because I want you to make great user interfaces, that's it.
07:03
So I'm going to split this talk into two parts. Part one, which is the things I'm talking about now, how we work together as designers and developers. And part two of what kind of tools we can use to make that process better.
07:24
And a lot of these things I see when it comes to responsibility is rooted in me talking to designers or developers. And I'm really open about critique. And if I see a friend of mine who created a website or an app or something like that, I often give them feedback about that.
07:45
So I can often say stuff like, maybe that button should be bigger or maybe you should try putting that screen somewhere else or something like that. And the trend I see more often than not is the developer answering, I didn't design it, I just coded it.
08:07
And that doesn't fly with me, because you are like the last line of defense before this hits the users. You should take action on that stuff. You should be responsible for what you ship.
08:21
Also when it comes to interface and how things feel and look. And for me, when I start seeing developers caring more and more about this, it's because they feel the pain of their users. They either start receiving feedback from users or support messages or something like that and they take it upon themselves to try to fix this.
08:49
And we were at a conference last month in Chicago, Ignite. And this is after a week of standing at a booth and talking to our customers about Dell.
09:05
Because it was so exhausting to actually hear people complain to us about what they didn't like and what they did like. But the thing is that we went back from that conference with a lot more responsibility, because this was our task now to convey this message and to try to fix this.
09:25
And also because we had the empathy of the users, because we had talked to them and looked them in the eye. And really felt their pain. And I want to talk about hats.
09:44
Not actual hats, but hats we wear at our work at home. Imaginary ones. Because designers wear one kind of hat and developers wear another one.
10:02
And these hats are something we are taught to wear, because we shouldn't bump too much into the walls that surround our position. We shouldn't try to do a lot of this time. We shouldn't try to make a logo. And that's okay. I'm not saying that we should try to make logos all the time.
10:24
But the thing is that when you are in this position, you tend to not care. You tend to learn to not care about these kind of things. How an app feels or looks, because it's not part of your corner in this hat metaphor.
10:41
But the thing is that your user doesn't care about what hat you're wearing. He just cares about what ends up in his hands. And in my experience, when you have this strict rule about who does what, and that the programmers get excluded from the discussion,
11:01
because they're given the expression that they don't need to care about this kind of stuff, that often leads to a massive amount of suck. Really a lot of suck. But the thing is that we can change this. We can change all of this,
11:21
because it's our job and we need to change it, and we should change it. And we should change our workflow, how we work with designers. How we do our day-to-day business creating this kind of stuff. Most places I've worked have had this kind of linear workflow,
11:40
where a designer cooks up something, sends it over to the developer, he implements it, and it's shipped out. We ship all the time, and let's hurry up. And that's okay if you want to create something that's okay. But you're not creating innovation or something spectacular by this.
12:02
Is this the same as expecting that a new car will suddenly pop out of a manufacturing line? Because I had this quote I wrote down, I don't know where it's from, but I really like this. Stupidity is believing that repeating the same process is creating innovation.
12:23
And it's not. Instead we need to be encouraged, and we need to be really want to challenge the designer. We need to poke them, and give them feedback, and get the feedback back, and really work with them.
12:40
If something doesn't feel right, we should have the motivation to actually say that to them, instead of just thinking of our little hat, our little fedora, and living in our corners. And Ed Catmull, CEO of Pixar, said that ideas only become great when they are challenged and tested.
13:01
And that's true, right? That's true for everything. We can't just push them out, we need to challenge them and test them, and at least from our developer's perspective, because we have a different perspective than designers often. And how can you actually challenge these kinds of ideas or these kinds of designs?
13:25
Well, feedback is the most important thing here. And giving great feedback is really hard. Most people can tell you that something doesn't feel right, or it sucks, but that's not really constructive, and it doesn't help anyone.
13:44
And the first part of giving really good feedback is timing. And this is important because if a designer delivers a whole design for something, a product to you, and it's relatively implemented, and you have something to say on that,
14:04
then it's really hard to get that through. It's really hard to change people's minds then, because we tend to be locked onto stuff we have worked a lot on and have really put our soul into. So give your feedback at the right time, and also give...
14:29
At Microsoft we have design reviews. How many here do design reviews? Okay, that should be more hands. No, and design review is something that is basically...
14:42
This is not Microsoft. This is a picture I found online, because I forgot to take that picture. And design reviews are a way of designers getting feedback on the stuff they're working on. The designer calls a meeting or just pulls people in in a room, and they show what they're making, what they...
15:02
And it could be anything from just a wire frame to a finished thing. And all the kind of different people from the entire company comes in. We've even had a dog in there once. He didn't give that much feedback, but the thing is that when you have all these people that are allowed to be there and are encouraged to be there,
15:23
developers can join, the CEO can join, managers can join, even HR can join. And because everyone has some feedback, right, and everyone should be a part of that process to be a part of how everything goes down, instead of having this line and this manufacturing line.
15:44
And the second part is environment. A work environment, not a global one. That's a whole other talk. And to be able to give good feedback, we have to trust each other. And we have to create that trust. And that's one of the most difficult things I've thought about,
16:05
how to create trust with my design department or with my colleagues, because we can't really be honest and open with each other if we don't trust each other. And the first, the easiest thing to be able to achieve this is failing together,
16:22
is to be a part of something that sucks together. That's the easiest way of actually getting there. But we can't fail together if we're not working together from the start. So when you say to someone that you didn't design this, you just called it,
16:42
then you're not failing together. You're blaming the designer of something you should be responsible for as well. Another thing I've gotten a lot out from is actually sitting together. Sitting together, we are really good at doing cold reviews. We should sit together with designers and do small design reviews.
17:02
And we should sit together in an environment. We should have our desks next to each other and really be a part of the same process, not an entire department that's on another floor or something like that. And when it comes to the environment and how we actually build this trust and work together,
17:23
we have done something else at Microsoft, which is really fun. Something called design sprints. Raise of hands how many have done design sprints? Okay. So design sprint is something that Google Ventures, the Google capital venture firm has created.
17:46
And it's a model of how to do something or create something or research something in a week in terms of a product. And it works like this.
18:04
You get a lot of people, four or five maybe, and you go into a room and you stay there for a week. And you go there with a question or a problem you want to solve. You go in there with either you want to have this new feature and how you should do that best
18:21
or you have a whole new business opportunity you want to explore or you just want to find out why users are not using your app enough. It works for all of this. And you go in there, you have designers there, you have developers there, you have CEOs there. You should really check this out. It's so much fun and it's crazy how much you learn.
18:41
The first day, you unpack. You find out what the problem is. You find out everything that you are actually going to research or work on. For example, if you're doing a new feature, then what are the reasons you're doing this feature? What do you know from before? What research led you to explore this feature?
19:04
Next, it's sketching. The cool thing about sketching is that I really didn't know how powerful it was until we did this design sprint because here we were sketching out interfaces in terms of we had 20 seconds to do one interface.
19:22
20 seconds. And we had to do like 20, 30 of them. And the thing is that after the first five, you start to actually get somewhere. You actually just draw something from your intuition. And it's so interesting to see because afterwards you can see that everyone else starts to draw the same thing
19:41
and you are onto something that is generally agreed upon. And once you decide, you vote on the things you want to explore more. Firstly, you prototype it as easy as you can and finally you test it with real customers. You go out and you test this. And we have done this a couple of times now and it's really, really powerful.
20:01
And we learn a lot from it because we go in there without any reasons to or any pre-assumptions of getting actually something out of this. That's the whole part of this. You don't necessarily get anything out of it, but you can and you probably will.
20:22
But everyone is involved. That's the important thing. That developers are there and sketching, designers are there developing prototypes, managers are there doing what managers do. And when it comes to this environment, when we have created that trust we want and when we have done this design review and been a part of a team,
20:45
we want to achieve a really good word for this is candor or to be candid with someone. To be open and frank without risking that people take it the wrong way or to actually just be open with someone about something.
21:05
And good feedback is specific. Good feedback is candid and it's tied to goals. And if you do that and if you follow those advice and try to work alongside the designers and try to work together,
21:23
then the environment gets a lot better. And then there's the medium, how you actually deliver this feedback. For me that's the most important thing because actually just going over to a designer and telling him that you should do this differently has almost never worked for me.
21:42
Because I believe that showing is so much better than telling. It's so much better to actually show that, okay, maybe you could do it this way if you just push this button that way or move it to this screen or something like that. And then you might say, hey, I don't know this sign. I can't change his sketches or Photoshop files or whatever it is.
22:06
And my solution to that is just to do it all over and over again until you find something that you feel can work. Just try a lot of different solutions. Just try to move stuff around. Just try everything because it's not that hard.
22:24
And there's also a lot of resources when it comes to trying to create something that looks reasonably well. Google launched its material design kit, which is our guidelines for creating good design basically.
22:41
And a lot here is I think really great because it defines how things should be related, how you should use colors, how you should use fonts, what sites you should use, how shadows should be used. Just take this out. It's really good. Because all of this is about just challenging something.
23:02
You don't have to create the file design. You don't have to be the best designer or the best developer in this process. You just have to challenge what you're doing today and create that feedback loop. So I'm going to show how I tend to do this if I get the design from someone
23:21
or I want to change something or any of those kind of things. So let's use some tools. So here I have this sign I got from a designer.
23:40
And this is a voting app. You can vote on a picture. And I tend to use an application called Framer because when it comes to doing prototyping, you can either implement this in your app or write the Xcode or push it to production,
24:06
but that takes a long time. And if you just want to challenge that designer on how he's thinking, then it's so much better to actually just do it quickly and do it fast to actually just show him that it's possible to do it this way. So let's open Framer.
24:23
And I'm using Sketch here. And Sketch is really cool. It's sort of the alternative to Illustrator. And developers I've talked to have said that this is sort of the developer-friendly design tool because it is reasonable.
24:44
It works like it should and things are placed where it should be placed. The really cool thing with Framer is that you can actually import stuff directly from Sketch so that that means that if I now change something in my Sketch file,
25:01
it will be changed in my prototype as well. So what it does is it gets the first screen first, the first artboard here. And I want to do a test on this thing because I don't think that's a good solution to actually just have a press. I want to have something more happen.
25:22
So let's see. So every layer in my Sketch file here is named. And that's names I can reference in Framer.
25:40
And that's the power of this, that you have the layers on the side there and then you can just reference them and place them wherever you want and animate them and make stuff happen when you're using this. This didn't work that well. So now I'm just referencing the screen itself to a new variable.
26:08
And I'm saving these pictures as variables as well just by referencing the layer name. And I do this for both screens here and the buttons that were on them.
26:23
I hit those because we only want to show them when you actually click an image. And so let me just put a lot in place here.
26:59
So what I now did is that I have, this is JavaScript by the way,
27:03
this is our CoffeeScript. And what I now did is I added click events on the two images and I set the buttons that are on them to visible when you click them. So this works.
27:20
And this is what the designer had in mind. So now I've created that and I know that doesn't feel like a great interface. So I want to give him a suggestion of how I think it should be without needing to designing anything, just doing something a bit more fancy.
27:47
Now I add states for these kind of images because I want them to pop out and then be more fluid and animate more. So I add the left choice, I add states for that one.
28:03
And I add states for the right choice and I animate those by just switching states here when I click them. That's cool, right?
28:20
And maybe this is not the best kind of design, right? But the idea is to just do something that feels a bit better and I can show this to the designer and he can say, oh, you know what, maybe we should just have them another way or stuff that I can come up with now just because these are things that come up in collaboration with the designer, right?
28:46
And I think that works. The next tool I'm going to show that we use and I think it's really important when it comes to, this is about timing and timing feedback.
29:02
It's a tool called Wake. And Wake is really cool. It's built in Norway by a company called Bucknambek. And it was created by a guy named Chris, which he worked for Facebook as a designer. And they had this problem at Facebook
29:22
because they had done design sprints a long time. But they felt like they needed even quicker feedback than design sprints. They couldn't wait that many days. They wanted feedback right away when someone designed something. And they wanted feedback from everyone in the company, everyone on the team, even developers.
29:42
So Sketch is a place where you can just dump in images. This is basically it. It's just a feed of images that are posted here. This is just a mockup. This is not what we're designing in Microsoft.
30:01
But I can go into images and I can comment on them. And I know that I can just go here and just see what people are working on right now, right? And actually just comment on stuff and say, actually, and just suggest things.
30:26
And they can be updated. And we can start to create more and better interfaces just by doing this.
30:45
And that's basically it. If anyone has any questions, I'll be happy to answer them. Unless no one? Thanks.
31:04
And remember to push a button on the way out. Preferably the green one.