Transcript

Jen

This is The Web Ahead, a weekly conversation about changing technologies and the future of the web. I'm Jen Simmons and this is episode 109.

So, hello again! I'm still in Munich, Germany. We just recorded episode 108 last night. If you listened to it, you heard me and Pamela talking about how jet lagged we were. That was, like, 12 hours ago. Now I'm jet lagged at the other end of the day, in the morning. I have yet another presenter from the Push Conference that just ended here in Munich. Dustin Senos. Hi, Dustin.

Dustin

Hello.

Jen

Thanks for joining us. Dustin is a freelance product designer. If you want to hire him, hey, he's freelance. You can check him out. You used to be at Medium.

Dustin

Correct. Yup.

Jen

You were the first designer at Medium.

Dustin

Yup.

Jen

Then you were the head designer at Medium.

Dustin

Yup.

Jen

That's so impressive.

Dustin

Thank you.

Jen

[Laughs] Like, one of the best designed, fresh interfaces that we've seen in years. Oh, hello.

Dustin

[Laughs] Thank you.

Jen

You talked in your talk about what product design is. From your perspective, what's the deal? We talk a lot about design, but I feel like we don't talk a lot about product design.

Dustin

[00:01:18] I get really focused on the difference between art and design. I think we blur those lines with our work a lot. I think a lot of people think what we do at tech companies is art, when really it's trying to solve a problem. We design things to solve problems for people. For me, product design is when a user has an intent and they will have a goal they're trying to achieve. The product makes that goal possible for them. In my talk, I'm interested in how the best products make the goal or the outcome better than they would have ever imagined. I think about Instagram making people better photographers than they thought they could have been.

Jen

Right. I think in the industry, we do, hopefully, focus a lot of user experience design. What is the user experience? Are they getting what they want? But some of the stuff you were talking about got beyond that. Or maybe even before that. Who is the user? What is the problem that you want to solve?

Dustin

Totally.

Jen

You were talking about how we don't do enough work around that.

Dustin

[00:02:32] I think you're totally right. I think a lot of people don't think about why they're building what they're building. They have a cool idea and they go out and build it and think, "What interface could be designed for it?" Or try to make a form or navigation really efficient, without taking a step back and thinking about what is it we're trying to build and what is this product and why are we doing this?

I think that comes before user interface design and after research. Almost more blended with the research side. Unless the research is super exploratory, it's trying to find answers to the product that you're trying to build. But you still need to know what product you're trying to build first.

Jen

What do you do when you're working with a client and they seem really intent on how the interface is going to look and what colors they're going to use? You really want to talk to them about these bigger questions.

Dustin

[00:03:35] It's hard. It's super hard. Especially doing freelance work. This is my first time doing freelance product design work. A couple of clients will be like, "We want to make this feature. Can we do a design sprint?" Well, which feature do you want to build? They know exactly which feature they want to build. You're like, "Well, we can visually design that, or go into the UX side of that. We don't need to do product design for that sort of thing." I try to get excited about the journey with them and try to explain, "If we don't pre-describe what the solution is and hope to know what the problems are, we don't know where we'll end up." That's where really cool things might happen that might be unique and set your company apart. It's hard because everyone tries to do everything so fast. "We have no time to slow down and think about these things." Well, then, you should just stop. [Both laugh] You should just stop doing it then. You need to think about these things. You need to put in more work upfront.

Jen

As you just said, they think they know which feature they want. I guess a lot of people don't think of it as design. Making a decision about which feature you're going to build is a design decision.

Dustin

Totally.

Jen

Who do you think actually makes that decision? Is it the business executives?

Dustin

[00:05:08] It really depends on what incentivizes the decisions at the company. If we need to make profits, there might be business people thinking, "We need this feature because we can sell it to people." I think at small companies it's typically the CEO. But the CEO probably has a whole bunch of other stuff to do. He or she is very busy and maybe not able to have the headspace to think about all of that kind of stuff. It's good to have everyone at your company thinking about that.

Jen

I've seen products where there are a lot of assumptions being made. The developers are the center of everything. It's all about, "Which technology are we going to use to build this thing?" They jump past a lot of assumptions about what's going to get built. Then it's all about making sure the servers are happy and the code if efficient and there are all of these bug tickets in GitHub or something. At that point, it's all focused on what the robots want. It feels like a big struggle to say, "Let's design this." Frequently people mean, "Make it look better." Which is good. That should happen. But just making it look better doesn't mean the interface is better. "Our interface isn't working. We did some testing. It turns out our interfaces are kind of screwed up. Let's make our interface better. Ok, cool. We're not only changing the way things look, we're moving things around, changing the words, changing the buttons, changing the user flow, changing the registration flow. Oh, wait, who did we build this for and do we have an audience? How are we going to grow our user base?" It feels like that whole sequence that I just described is completely reverse of what it should be. You should start with, "Let's define what we're doing. Let's figure out who we're going to do it for. Let's test those ideas and make sure those people want what we think they want, that they have the problem we think they have." Then you figure out, "How's that going to work? How are the flows going to work? How is the interface going to work?" Then you figure out, "What should that look like? How's it going to express our brand? How's it going to feel?" Then you figure out, "How are the servers going to be happy? What tickets will it take to build this?" I've been on a team where it was completely the opposite direction. Coming in and trying to say, "Wait, let's define who the people are. Let's define what need we're meeting." The engineers got angry: "Who are you to tell us what to do?" But... but... what is going on around here? [Both laugh]

Dustin

[00:07:45] I think people just gravitate towards... I always refer to it as their center of gravity. Engineers and designers. Designers like to make stuff look good and that's where they're comfortable, so that's why they'll make stuff look good. Engineers will be like, "I don't want to work on old tech. So let's talk about all the technology we could possibly use. This new front-end framework does this. Oh, look, our product now mimics the examples of what the front-end framework can do." Because it's interesting, right?

I totally agree. It's hard to stop and question things. Oftentimes, personally, I'll have an idea for a side project and I'm really excited about it. Then I'll talk to people and you realize it's not a good idea. That's deflating. But it's better to find that out upfront than build the thing and then realize that no one wants it or it's not a good idea or there's something that exists that people are using. I think people try to avoid those questions.

Jen

I wonder if it's in part because for so long, those of us who understood technology, we meant we were the engineers. But we weren't called that. We were the webmasters or the developers. We didn't even use the word developer. We were the people who understood the technology. Our ideas were actually the best ideas. Other people barely knew how to use the Internet. "Those people are dinosaurs. Those marketing people and executives. They really don't know what they're talking about. It's the developers or maybe some designers who are the center of wisdom." I wonder if we're still carrying around that kind of bias in our world.

Actually, there is something to figuring out the business stuff. Or the executives aren't just evil people who won't give you the budget. I don't know. Not always. Plenty of times, there are C-level people who are useless. [Both laugh]

It's almost like we don't want to have the conversations. I don't even know who belongs in the room anymore. Which people are in the room to have the conversation about, "What are we going to make? How is it going to be good for the people that end up using it?"

Dustin

[00:10:17] I've never really thought about that. Oftentimes, companies are split up between the people that make stuff, and the people that don't make stuff. It's almost like the people that make stuff always have this extra level of value. When it doesn't really matter if you make stuff or not. If you are a marketing person and you know the audience really well, you're probably more useful than a whole bunch of really good front-end engineers. Especially early on. Or if you're transitioning your product into something new. I've always thought who should be in the room should be as diverse as possible. Diverse backgrounds, job roles, and everything. It changes. If you're building developer products, there should probably be a bunch of developers in the room, talking about what they need. But if you're building a platform where you're trying to enable lots of people to be on it, you just need to have lots of people in the conversation. They bring different stuff. The ignorance to what can be built or what's hard is fantastic to have in a room, because they're not thinking, "We could do that, but that's going to be really hard to build." They'll say those ideas. I think developers or designers will self-censor when we really shouldn't.

Jen

Customer support folks as well.

Dustin

Totally.

Jen

If it's a brand new startup then you don't have a customer support team for a product that doesn't exist yet. But if you've got any sort of customer support. Lots of times, that job is outsourced to other countries. You don't even know. It's another third-party company and it's handling it. Those are the people who know best what problems your customers are having and what they need.

Dustin

[00:12:06] Totally. And what parts of it resonate with people? Typically in customer support you only hear the negative stuff. They'll do a weekly report of, "Here's what people are struggling with." But if you can hear over and over again that someone really likes this one aspect of it, then maybe you can focus on that or expand that.

I worked at a company called Club Penguin that was bought by Disney. There were 350 people there when I left and about 100 customer support people. A huge chunk of that company was customer support. We would do rotations where we would go do customer support. You instantly feel the pain from a bad UI or bad engineering choice so much more real than hearing it in a report. As soon as you're listening to a kid talk about something. It was a kid's game that I worked on. As soon as they lost their points or something, you'd be like, "This kid is crying right now." [Both laugh] This is for real. I feel really bad.

Jen

In your talk, you were talking about process. There's four things on this slide, let's talk about them. Not establishing success criteria. You were talking about what is it that makes a project go wrong. Why did you talk about what to avoid? How did it work at Medium? You could just copy Medium.

Dustin

[00:13:56] For this talk, I wanted to talk about process. I talk about it as the vegetables of design. It's not the fun stuff but it's really important. When I was thinking about what people could potentially take away, my goal is to have little nuggets that people could take away. I thought about exactly that. I could talk about what we did at Medium or what I've been doing with my freelance clients or how things worked at Disney. But I realized that teams and products are all very different. What worked for us at Medium, or I was lucky to world-class engineers and world-class designers, might not work for another company that's a bunch of people fresh out of school or not having 10 years of experience in the web doing this kind of stuff. If I went up there and said, "Here's a process that worked for us." It might not be applicable to everyone. They could take nuggets from it, but I decided to talk about the inverse of what works to what doesn't work. I think you can often see, in many places, a pattern of what's not working for them. If you talk about the negative stuff—the momentum killers—they can maybe take one or two of those an apply them to their process. Versus trying to change their entire process and start fresh; to lift everything up and try a totally different way of doing it. If you can give them concrete examples: "I've seen this not work." Then they're like, "Oh. We tried to do that." Then maybe they could take more from my talk.

I put the four things in order of importance and order of actually doing them. 1) Not establishing success criteria. 2) Designing for the wrong person. 3) Not exhausting your options. 4) Being too clever. There's a lot of meat in each one of those.

Jen

Let's talk about the first one: not establishing success criteria. What do you mean by that?

Dustin

[00:16:00] For me, that's not knowing what a win is, or what your goal is, upfront. So often we jump into design or development as soon as we have an idea. "We can build that! That's really easy. I'll just go build that." If we don't know upfront—this goes more with the team side. It's easy if you're a solo person working on stuff, because you're probably doing all of this in your head. Success criteria could be three or four people tweeting about the little side project you're working on. But when you're working at a company, building a product, if you don't establish upfront what a very concrete, simple goal of what you're working on. It could for the whole product or the current sprint or the feature you're working on. It's really hard to know if it has done what you hoped it did. If you don't have it, it's hard to critique multiple designs. You have no sounding board to say, "Is this solving X?" If you look at 15 designs and go into the world of design where you're like, "This one's blue and this one's orange and this one's green. Let's talk about that for many hours." Without thinking about, "What are we trying to do? What is the goal of this thing?" It probably doesn't actually matter what color it is, in many cases. The side of design that puts down design, where you say, "It actually. doesn't matter." Sorry, I'm rambling about that.

Jen

I've seen situations where it feels like you are trying to come to consensus, trying to agree, trying to do something together. It turns out that you can't. You keep banging your heads against each other. Underneath it all is the fact that everyone has a very different idea of what success is going to look like. No one's conscious about it. No one's sitting there thinking, "I think this is going to be successful because this is what I think success would look like." They're just like, "I think this will be successful because I think my idea is better." [Laughs] It turns out that this person thinks success is, "We come up with a business model that saves the company because the business model we've been using... we've been around for decades but the way we've made our money for decades is dying, quickly, and we need a new, fresh way to make money. We need a new revenue source." For them, that's what success is. For somebody else, success is: "We build something really cool that's going to look awesome in my portfolio, so five years from now, when I'm looking for a new job, I can look impressive." For someone else, success is: "Users. More users, more users, more users." That may not actually match up with any of the others.

Dustin

Or some person could be like, "Success is this gets shipped on time. I don't even care what it is. My goal is to make sure this gets shipped on time."

Jen

You end up with this competing passive-aggression. When things start to go wrong it feels like people being passive-aggressive. But it's not even people being passive-aggressive, it's just that no one ever sat down and said, "What does a win look like?"

Dustin

I totally agree. You said that much more succinctly than I was able to.

Jen

You inspired me the other day! I'm like, "That's exactly what was wrong!" It's like dating somebody and you think you're doing to get married and they think you're just having fun and you never talk about it and you end up crashing against each other going, "What went wrong?" It's because we totally didn't even notice that we were speaking a completely different language. We had totally different ideas about what we wanted here. That's not a good metaphor. [Laughs]

Dustin

It totally works. It's really important to have a little sentence or something pasted on a wall that everyone can agree upon.

Jen

That's where it feels like things can start to get hokey. I've walked into offices where there's three sentences on the wall and you're like, you just want to pretend that you never saw that. Because it makes you discouraged because it's so full of... nothing. A lot of effort and money went into a bunch of nothing and that's on the wall. But you don't mean that.

Dustin

[00:20:18] No, I don't mean inspirational posters. It needs to be really actionable. One thing we did at

Medium was define design and product tenants or flagpoles for us. They all had to be super actionable. It couldn't be, "make it fast." Because it's like, why would we ever make it slow? We'll never talk about making the thing slow. Or, "make it beautiful." It's like, cool. No one here wants to make something ugly. Thanks for this design principle, super useful. We always weigh two positives against each other. We'd do direction over choice. That means we actually have to choose one, because both of those are really good. By forcing ourselves to think or two positives and put them in opposition, you have to choose one. And they're both good. With setting up success criteria, it should be something very concrete and actionable. Almost a to-do list item that you could check off. "Did we do that?" Not: "Did we inspire users with this project?" It's like, who knows? It can even be related to metrics if you want to be that concrete about it. "Did we increase the amount of people that came back to our site daily?" That could be the goal. As soon as you have that, then you can go broad and do whatever you want.

Jen

It also feels like to come to the decision, "We want more time spent on site." You have to ask yourself, "Why do we want that?"

Dustin

Right. And is that a user goal or a business goal?

Jen

Yeah. Maybe it is a business goal and not a user goal. But you could figure out ways that you need users to also want that. Sometimes the user design needs a business. Even if you don't like the business ideas, sometimes it's just the reality. Still making a decision that more time on site is important and not more registrations or more new users. I would hope that a good conversation would happen that you can get to that place. That place is a way to keep everybody's eye on the target. But the getting to the place was actually what was much more important. If one person just walked in and said, "This is it. We're not having a conversation about it. I have deemed this is going to be the thing." That's not really helpful.

Dustin

[00:22:45] Not helpful at all. It's crazy, too. I bet many people or companies or project managers or whomever can ask their team, "Why do you think we're doing this?" and they'll get very different answers from many people. That's just a good sign that, "Maybe we should talk about the whys for all of these things before we actually do them."

Jen

If there's somebody who's in a company who is listening and this is resonating. "We really don't have a clear idea of what success is. I don't agree with what success is." That's a great idea, to go around and ask everybody. Do a survey. Talk to people in the hall. Grab people's ideas and document that. Write it all down and show, "Hey, we've got 10 people working on this and all 10 people have a completely different idea of what success would look like. They have a different idea of what we're actually trying to do." You show that to your boss and say, "I think we need to take a step back and do some planning." Basically, strategic planning. What are we doing? What is our product? What are we designing? Who are we creating this thing for? Yeah... handy.

Very nicely, you have four organized points for us. We already talked about not establishing success criteria. Number two is designing for the wrong person.

Dustin

[00:30:31] With designing for the wrong person, the biggest thing I see designers and product people doing is designing for their peers. You often see that on Dribbble, where things get a ton of likes because it looks really great. But when you look at what it's doing, you're like, "Wait, this is visually pretty but not very functionally useful."

I think that's because we like doing something and getting rewarded for it. It's a very concrete reward that when you get a bunch of hearts of Dribbble or props from your friends or other designers, you're like, "I'm doing a good job." Whereas when you ship something and put it out in the world, often no one is commenting on the design. I think we gravitate towards the places where we can get very concrete feedback. We do designs that are following trends or following whatever peers like or our bosses like or the clients like, rather than what our users like.

Jen

What do you think is the solution to that?

Dustin

I think the solution for it is increasing your empathy for people and talking to the people who use our products. Thinking about them as actual people, not audiences. Even when we're talking about social products like Twitter and Facebook, it's individual people using them. You can find and talk to those people. Hopefully you know who they are. You can see how they like your design and how it resonates with them.

Jen

There's nothing like traveling to make me realize that a lot of the people who are designing and building apps, websites, tools... even things that you wouldn't think are Internet-connected apps. Computer applications. They freak out when you're offline and when your Internet connection is slow. It's becoming almost stereotypical, in my own brain. Clearly, there are people sitting in offices with very fast Internet connections, designing things for themselves. They're not realizing that many, many, many other people don't have fast Internet connections or are consistently online.

Dustin

Totally.

Jen

Or other situations. You end up with this, maybe everybody working on iTunes thinks its awesome. Yet every time iTunes is offline, it freaks out.

Dustin

Yes, and you can't access anything. Which is sad and useless. I even find that with the new Photos app. Half of my photos are synced to iCloud whenever I tap on them and I can't look at them. I tried to look at them on my flight and I wasn't able to because I had no wifi connection. My mental model is, my photos are on my phone.

Jen

I understand that I can't listen to music that's in the cloud when I'm using iTunes. I'm not worried about that. Why does it throw me an error message every 15 seconds? It's like, "I can't get the... I'm not online!" Yeah, I know. That's because wifi is off. [Both laugh]

Dustin

You can detect that.

Jen

You, of all people, of all apps. The system software should be telling you. Don't throw me an error message and bounce in the dock and jump to the front of my space. The wifi is off. Anyway.

You could easily be working on something and not even realize that you and your peers don't even think of something or need something that actually most of the people who are using the product do need and are thinking about.

Dustin

[00:34:29] Perhaps you haven't talked to your team or your client about who the users are who you're designing for. I don't mean crafting super intense user personas where they all have names and you have illustrations or photos of them. You can have a simple conversation and jot down a few sentences. Without doing that upfront, you don't even know where to go look, or where to find these people to talk to them or how to run a Craigslist ad to try to bring them into your office or meet them somewhere to look at your product.

Too often we skip that stuff. We skip the conversations about who's going to use our product, or the type of people, or the contexts or the types of devices they're going to use. Because it doesn't feel like progress. It doesn't feel like the same style of progress as sitting down and mocking something beautiful and getting everyone stoked about it. But that is not going to be as informative if you don't do the boring stuff upfront.

Jen

It does seem like wasting time or, "We can skip that for now and come back to it later."

Dustin

[00:35:37] Exactly. Or, "We're too small. We're too scrappy to even think about this." It's like, the people downloading your app don't know that you're scrappy. They don't know that you're small. They don't know that you haven't thought about this. They just look at your app and that's all they know. That's all the context they have. You can't ask them to excuse you for the things you haven't thought about yet.

Jen

Sometimes we are working very hard to do great work. Thinking hard about the person who's offline. Not being obtuse, as I was just describing. But because we are professionals, making work for other professionals, getting reviewed by professionals, it's very easy to not even see the kind of biases that we're bringing in. Not seeing the way in which we're reenforcing a certain set of ideas without getting away from ourselves or out of our bubble.

Dustin

That's a super good point.

Jen

Finding real users, talking to the people who are doing support, go do the support yourself, go find real people who are using your thing, to show you what their experience is. I think it's pretty mind-blowing for any of us. When you do testing and watch a person try to use your thing and you're like, "Ah! I never could have imagined that they would have gotten stuck on that, or had this much trouble with this thing."

Dustin

And you feel so bad. You feel horrible. You sit there staring at them and you're like, "Aw. Darn. They can't do it. They can't do what I want them to do." Or what the test is asking them to do. Hopefully you feel horrible. Hopefully you feel really bad for your poor design.

Jen

How do you get a client? Designing for the wrong person. What if you feel like you are designing for the wrong person, and you've got a client, a stakeholder, and they seem to not be able to wrap their head around what this point is about. They think they know what it is, they know what they want, they come with all of their ideas already sketched out on paper. You feel like that's for the wrong person.

Dustin

[00:38:00] I can imagine it's hard and going to be very dependent on timelines and who your client is. I can imagine if your client or the business owner you're working for is very invested in the product or what you're doing for them, and perhaps you run a few tests and record them. Or get the client to take part in it. I can't imagine that someone who's not really vested in the success of their product, seeing people struggle with their ideas or the direction they want to take it, will hopefully question their sense of what might be good product design. Hopefully they see that they've hired whomever it is working on this because they're bringing something to the table that they can't do themselves. They're egoless enough to put their ego aside and say, "Maybe I don't have the best ideas. Maybe I don't know who my people are." Because these are actual, real people using the product. Maybe they don't get to see it that often. I think that's the approach I would try to take.

Jen

Yeah, once you have something, to test it.

Dustin

Totally. There's a pretty cheap Mac app called Silverback, which I think is $100 or $60. It's a pretty fantastic app for that.

Jen

Yup. I'll put a link to that in the show notes. The show notes, by the way, are at thewebahead.net/109.

Dustin

[00:39:31] Awesome. One of my favorite says for user testing, which I like to repeat every time we user test to make designers feel ok with seeing that perhaps they have the wrong designs and oftentimes we come up with the wrong solutions. I can't remember who said this. Hopefully I can find the quote later. "Design it like you're right and test it like you're wrong." I just love that. It puts you in a place where you're like, "I'm testing this. What have I done wrong?" versus, "What am I proving that I did properly?" If you take that perspective, I think you're more open to critiquing your own work.

Jen

I imagine also not biasing the tests by running them a certain way. [Laughs]

Dustin

Exactly. To prove this is all good design. You should really try to prove the opposite.

Jen

Your third point is not exhausting your options.

Dustin

[00:40:24] Another thing I'm pretty passionate about. When I say "options" I mean approaches to the problem you're trying to solve through product design or visual design.

So often we jump into the first solution that comes to mind. Time and time again, I've found that when you hit the bottom of the barrel, and when you think all of your ideas are gone, that's when really unique and wonderful things happen. They don't need to be more clever, it's a different or simpler approach.

I forced myself with some of my client work recently. I was designing a dashboard for a mobile app. I took a very large piece of paper and drew 20 iPhone shaped boxes and forced myself to draw 20 different dashboards. The first five were pretty obvious. Five to 10 to 15 were getting a little crazy and silly. Past that point, I came up with something that I had not thought about, which wasn't obvious, but turned out to be a much better solution. I tried the same thing with another client for their web product. I think it was iteration 19 that turned out to be the right thing. Oftentimes, it can feel like a waste of time or a lot of unnecessary work. You might go down a crazy path and realize iteration two or three was the best. But without doing all of those and exhausting your options, you don't have a strong argument to why one or two or three might be the best iterations. Because you haven't gone through the whole spectrum of options. These don't need to be high-fidelity. These can be with Jiffy markers—or Sharpies as Americans call them—to force yourself to stay low-fidelity. You can do this with anyone at the company. If it's not in Sketch or Photoshop, anyone at the company can sketch stuff down on paper to a fidelity that they feel comfortable with. You can almost parallel process going really wide and using that to form an argument as to why one iteration or direction feels the best.

Jen

You're talking about designing interfaces, tools, navigation, page layout. The kinds of things you might express in a wireframe.

Dustin

[00:42:52] Exactly. Yup. Totally.

One thing that's scary with this is, if you haven't done one and two, not establishing your success criteria or design for the wrong person, you can be staring at 20 different iterations and have no idea why one is good or one is bad. If you do those first two steps, hopefully you can come from a stance of opinionated critique when you're looking at all of these iterations.

Jen

I think this is pretty genius. I feel like most of the time, I've seen design be under respected. Not understood. People think success happens in the moment where the two or three people in a meeting agree that they need a certain feature. Frequently without defining the audience, without defining the product, without defining success. They walk in with all of these assumptions like we were talking about earlier. Say, "Yes, yes, yes. Let's do this feature. Let's do this feature and that one. This one we don't have much time so let's not do that one. Ok, feature. We have to design it." Or they probably don't even use that word. "Let's build it." [Laughs] Frequently you go straight to the engineers or developers. "We're going to build this thing." Some one person sketches out an idea. I've seen plenty of teams where the developer who's tasked with building that piece of the whole thing designs it as they're building it. They implement their first idea and put it into the rest of everything else that's going on. They're going fast. We're failing fast. We're iterating. This is minimum shippable. Minimum shippable means we just went ahead and built it. There's no time to go back around and think about it a second time.

Dustin

Right. We always tell ourselves we're going to. Always.

Jen

Right. "We'll make it better later!"

Dustin

Yeah. Exactly.

Jen

That feels like the absolute opposite of not exhausting your options. It's like not even trying to have options. The developers are thinking about this by themselves as they're simultaneously engineering the code and figuring out everything else, technology-wise.

Dustin

[00:45:27] I've seen other times where you'll throw the most obvious thing out and someone in the room will say an alternate opinion or a different approach and instantly you'll get shot down. "That's going to be too hard to build." People are like, "Uh, ok." It's just instant. Maybe if option three or four or maybe if those people would have talked it through they would have come up with option six that actually is better and easier to build. Or the same or a little bit harder to build but might be a better approach.

Jen

Right. Or if rather than having a debate, you just sketch it and then sketch something else and then sketch something else and then sketch something else. Expecting that you're going to try to get to 10, 20, or 30 sketches.

Dustin

Yup.

Jen

It seems like what you're describing is a way to have less... "I'm right," "No, you're right," "No, he's right," "No, she's right" energy in the room. More of a, "I don't know, let's try this!" "I don't know if that's going to work, let's do another one. Let's do another one."

Dustin

Exactly.

Jen

Everybody's running in the same direction without needing to decide which one is going to be the one until it's obvious later down the road. Has that been your experience, that's what ends up happening?

Dustin

[00:46:48] Yeah. There's fun parallels to improv comedy with this kind of situation. Imagine two people are standing on a stage. They're improv comedians in front of you. One person says, "Man, it's pouring in here." The other person looks at them and says, "No, it's not. We're standing on a stage right now." It's like, done. The comedy can't go anywhere. Whereas if you're going to build off each other's ideas and try to exhaust them, one person could say, "Man, it's pouring inside. It's raining so hard." The other person says, "Good thing I brought my spaceship. We can get into that." These things can go anywhere at that point. They're doing it collaboratively and building off each other's ideas and not shutting them down. If you're forcing your team to exhaust stuff, you're doing to get tired of people shutting them down and you're going to want to build off each other's ideas. I think that's where really interesting design happens.

Jen

Yeah, nice.

Dustin

By exhausting your options, it's not like, take two weeks and design stuff. It's like, take an hour. [Laughs] Or two hours with a group of people and try it. You're going to see that it's, oftentimes, going to be better than if you jumped into building things. Trying to be lean. Or like you said, ship the most shippable thing. Just try to slow down a little bit upfront.

Jen

Do you find it better to be fewer people in a group like that, or more people?

Dustin

[00:48:16] It really depends. Depending on the format of the meeting, I don't think you can have 10 people all building off the same idea. In that case, I'd break the room into smaller groups. Groups of three or four. Have them spitball together on their own and come together and pitch their top five favorite ideas that they came up with. I think there's a tipping point where you have too many people staring a white board and one person sketch. When you're in smaller groups, everyone feels more accountability to contribute because there are fewer people. If you're in a large room, people might sit back and watch everyone else do it.

Jen

I hesitated to ask you about Medium because maybe there's stuff you shouldn't talk about. But I also feel like you've got to have good stories or juicy insight on how these things work there.

Dustin

[00:49:19] I left Medium about five months ago. I'm sure there's many, many more juicy and interesting things. They've probably revised their process many times since I've left.

I can talk about something super concrete on the design team. One of my favorite things that we did as a design team was the way we did critiques. I felt like it's really where the team came together and we built up a lot of support for each other and created an environment that everyone felt comfortable designing in. Like how you always have your best ideas in the shower, it's because you're relaxed, you're not thinking about stuff, and you enable your brain to bubble these things up. If you can create a relaxed and supportive environment, the same thing will happen at work.

We did something called DCT, which was Design Collaboration Time. It was a daily hour of design critique. The team was about six of us at the time. Obviously we'd have multiple critique session if the team was bigger, but for that size, it worked quite well. The designer had to stand up in front of the group of people with a screen. If it's an iPhone mock, a mock on an iPhone that everyone can access. State what the success criteria was, what the goal or intent was, and who it was for. Give no other context aside from that. The reasoning was that when someone is downloading your app or using your app they don't have a designer standing beside them explaining why the button is where it is or why the font is as big as it is or why the color is the way that it is. The designer was only allowed to say those two things and show it. It also helped keep the critique short. Everyone individually would quietly write down thoughts, pros, and cons about how they felt about the design. Then I would facilitate the meetings and pick a designer in random order to give their feedback. Other designers weren't allowed to talk. it felt really arbitrary and not collaborative in the sense that it's not a room talking about stuff. But it forced only the amount of context that a user is actually going to see. A very quick way of getting good feedback from people, positive and negative. Ina a very quick, quick way. It let us go through a lot of designs. We made it very clear that any designer could take or leave any of the feedback. I want to make sure all of the designers on the team felt accountable and responsible for their work. It's not design by committee, it was like, as a good designer, you should hear people's opinions and incorporate them into your designs. Because it was a very strict format, it also enabled us to bring other people from the company in. Engineers or marketing people. They could fit into of this format without feeling like they really needed to know how to, like, sell their opinions on typefaces.

Another thing I missed was the designer had to state upfront what they wanted feedback on. That helped prevent myself showing a mock of a homepage screen and people talking about the typeface for 30 minutes when really all I wanted to hear about was the layout. By setting that upfront, it caused the critiques to be really concrete. By giving a very structured format, it let everyone in the room have an equal voice. If you're shy or quiet or don't want to speak up over someone else, everyone had a turn to speak. It let everyone give their feedback. Which worked really well for on-boarding new designers or people that might be kind of quiet or not someone to step up and say their opinion and try to speak over everyone else in the room. Those people use our products, too, so it was important that not just the loudest voices in the room are heard.

Jen

It reminds me of the kinds of critiques we would give when we were making theater together. The fact that one person would speak and no one else could speak meant we're not having a conversation right now. We're not going to have a big debate. We're not voting. This person wrote this show. They stood on stage a did a little piece of it. They would ask questions and people would answer those questions. It wasn't like you could say anything you want about their work. They've invited you to comment on a specific thing and you're going to comment on that specific thing.

Dustin

That's awesome.

Jen

And you were not going to have a conversation. That person being critiqued is not going to respond and explain why they did it they way they did. You're not going to re-explain why it is that you think your idea was right, even though they just explained why it was already the way it was. We're not going to do that because there's no need to. We don't need to agree. This person stood on stage. This second person said something. That's it. The first person can do whatever they want with it. The second person is going to move on with their life and never think about that conversation again. [Laughs]

Dustin

Totally. That's awesome.

Jen

Yeah. There was something about the structure and the way you had to wait for your turn before you were allowed to talk that made it really safe, in a way.

Dustin

[00:54:39] Totally. You leave and you don't feel like, "Man, I didn't get to say anything." You leave like, "Ok. That's awesome. This format is interesting." People like structure. People like things that feel like games. No one thought they never got their voice heard. It was the opposite of that, which was surprising, because you don't expect critiques that structured to feel that way. It turned out that it worked well for us.

Jen

Yeah. Because I did all of this theater and went to grad school. In grad school there was no structure. It was, you write a script that's very vulnerable and scary and then your random classmates say whatever random things they want to about it and tell you how they think you should have written it, how they would have written it if it were theirs. The teacher goes, "Ok, who else wants to talk?" [Both laugh] Certain people would dominate. It felt like they were really showing off. Trying to make themselves look important more than help you.

Dustin

Totally.

Jen

Ugh, it was terrible.

Dustin

Yup. That does not sound fun. Especially things like your script or writing or design, where it's so unstructured and it can go anywhere. It's very opinionated. It's not as concrete. Either the bridge is going to work or the bridge is not going to work. Now we can talk about the artistic side. No, this is all artistic and driven by gut.

Jen

The fourth of your four things is being too clever.

Dustin

[00:56:16] This one is a hard thing to talk about as a designer. It's easy for us to think that everything we do needs to be fancy and beautiful and unique and special. We're "creative people." We should be making creative solutions. Realistically, so often, it's following conventions, doing what people expect, making things obvious, that really is good product design. It's not always fun to design that. But oftentimes it's the best way to go. Especially if you're a small, scrappy team trying to get along. Follow the conventions from Google Material Design or the Apple Human Interface Guidelines. Use conventional components. Leverage and stand on the shoulders of all of these super intelligent people that have been thinking about those systems. Don't just jump out of the gate and think, "This needs to be artistic. This needs to be clever. We need to wow people and win design Webby awards." The design is not going to make or break your app. More than likely, it's going to be the product and problems it's solving and how it fits in someone's life, versus if you design some crazy, unique interface.

There's room for unique design. Obviously you can't create all iPhone apps or games with the standard UI components, but it's hard to know where to go into that place. If you're just getting into it or trying to test an idea, try to force yourself not to be too clever.

Jen

Yeah. I guess it's where ego can come in. You want to make something that's going to look awesome in your portfolio. Where you'll be proud to show other designers. You want to redefine everything. It's exciting when you see other people come up with stuff. I remember when Twitterific come up with the pull to refresh.

Dustin

Totally. I forgot about that.

Jen

Genius. There's a way in which we want to strive to do something that is that powerful. It ends up becoming the convention because it's so great. How do you continue to strive for that kind of work, while also doing what you're describing?

Dustin

[00:58:40] It's a tough balance. I think inventing things like pull to refresh are incredibly hard to do. The person that designed that was very clear with what the success criteria was. It was, "We need a good way to refresh this without tapping on something." Who knows why they came up with the idea they came up with. Maybe they didn't want to put a refresh button on the page or something. They were an experienced developer. They knew what they were trying to do. They forced themselves to think about that. It was only one little feature inside of a beautiful app that had a really clear purpose. The whole interface of that app was not clever or unique. It was that one feature that solved one small problem in a really interesting way.

One thing I think you can fall into is trying to do that with every single thing in your app or on your website. Trying to be clever with every interaction. If you're constantly designing new navigation parallels or principles, it's like, people are going to need to learn your app before they can even get to the point of what your app is. It's knowing where to be clever and keeping a good balance of that. But it's hard. It's absolutely hard to do.

Jen

In a way, I guess this gives us permission to lean on the convention. Like you said, stand on the shoulders of giants. If you're making an iOS app, relying on Apple's Human Interface Guidelines. Or if you're making an Android app, relying on Google Material Design Guidelines. That's a good thing. That's not like, "You're a beginner," or "You're a loser," or "Someone else has to help you with your design."

Dustin

Yup. It's true. That's a really good point. I don't think relying on conventions is any sign of your being junior. But I think people probably feel that way.

Jen

It does feel that way, in a way. People know my work. I'm constantly walking around telling people, "Don't keep doing what you've been doing." My talk that you saw the other day. "Stop designing the same old boring thing."

Dustin

[01:01:07] I left your talk with the mindset of like, "Challenge accepted." We can design more interesting things on the web now. All of these sweet spots where it's a combination or venn diagram where the technology and design are finally capable to be sync with each other. We have beautiful typefaces. We can render those online. As you pointed out in your talk, we have all of these new CSS ways of laying out pages. We can now take advantage of that. I feel like the constraint of the technology forced us to not be clever or beautiful. Your examples of the print stuff were beautiful. Interesting layouts that we had to dumb down for what was possible. Your talk showed that a lot of that is now possible. We can start being more clever and pushing the design online.

Jen

Trying to fit what I've been ranting about into your model... part of it is about realizing, this classic, holy grail layout—with the header and sidebar and main content and footer—isn't working. It's about realizing there's a problem that needs to be solved for real humans who are actually really using websites. We can do better. The next step, if people say, "Yes. Cool. I want to make better page layouts. I want to do something really awesome and new," to not do something awesome and new just for the sake of doing something awesome and new. The thing I didn't say in the 2015 talk but I will in 2016 is getting into, "Alright, cool. What's your page? What's your content? What's your voice and tone?" You've got to approach this, as a designer, to figure out how to best show off the content that you have. To take your cues from the content itself, not from an idea that you want to put something shiny and fun on Dribbble or CodePen or whatever. Or you want to use this piece of technology for its own sake. Make triangles because triangles are cool. Make triangles because triangles are going to really highlight the content you have, or solve a problem that actually exists for the real people that are really going to be going to your website.

Dustin

[01:03:42] Yeah. I think that's such an important point that you made there. When all of the fancy scrolling sites came out, where you'd scroll and someone would slide in and give you a thumbs up and they'd zoom away. Next thing you know, you're underground and going down an elevator shaft and the content is zooming by. I just scrolled up and down those pages because I was curious what was going to happen. I don't think I read almost any of them. It's like a pop-up book where you just want to flip to the next page to see what the next page is going to pop up and show you. To our point, those were not complementary to the content. Those were distracting from the content. They weren't coming from a place of supporting the content. I think you're exactly right. If you can design things where the design elements and page treatments actually complement the content and help tel the story, that's really cool. That's going to be neat.

Jen

With the parallax websites, I think there was this moment where we each saw something like that for the very first time and it was mind-blowing. "Wow! That's so cool!" Then the third or fourth time you're like, "Oh yeah, those people are doing that thing." Then by the 40th time, you're like, "If I see one more parallax website, I'm going to freak out." [Both laugh] Where now, it's almost a joke. In episode 100 with Jeffrey Zeldman, we were just slamming parallax websites. Somehow the technology itself was so entrancing. We were so excited. We thought it was so cool. We started using it for its own sake without thinking about why and when and to what degree. Maybe there's a place for a small amount of parallax for a very specific reason based on that website. It could still be genius, although now we've probably overused it to the point where it's distracting because people assume it's something that it isn't.

I don't want people to start using whatever, CSS shapes or flexbox or grid layout, in some crazy way that doesn't have something to do with their website or their content. To make us hate it. [Both laugh]

Also, people hated parallax because it was badly engineered and performance was slow. Then it got in the way. You couldn't even read the article because the page wouldn't scroll properly because the JavaScript was too taxing for the device that you were on.

Dustin

Totally. I think that goes back to what you were saying. If you're only showing your work to the people with $5K iMacs sitting across from you in San Francisco in your fancy office, you don't realize that half of your people probably don't have brand new computers. They're not even going to be able to scroll your website in the first place. Why even make it? Why are you even doing it?

Jen

Yeah. You're on a four year old iPad on a 3G connection and you're trying to load this parallax.

Dustin

And it's content that should be able to be loaded on a feature phone. It's text. Half of the time that stuff is text and we fill it up with all of that arbitrary stuff, which is horrible to other people that don't want to pay that much for data, or can't afford a ton of data.

Jen

Yeah. All of that. It's just being too clever.

Dustin

Yup.

Jen

It's easier to point out with these extreme examples. I think the challenge is for us to look at how we do that in our own lives or our own practice. Where is it being too clever? Where is it that I've gone with my first idea or my third idea and not kept at it until I found something better? Where is it that I'm designing for the wrong person? Where is it that I haven't even thought about what success is going to look like?

Cool. Thanks so much.

Dustin

I appreciate it so much. Thanks for having me on the show.

Jen

Where can people follow you or find you?

Dustin

They can follow me online. Twitter is probably the best place. It's just @dustin. Which is my first name. That's a good place to find me online. Same with Medium—@dustin on Medium is where I do my writing about this kind of stuff.

Jen

Nice. People can find the show notes for the show at thewebahead.net/109, along with links to Dustin's stuff and Twitter and Medium. Thanks to Media Temple for sponsoring the show. I guess that's it. Until next time, thanks for listening.