Ryan Singer from 37signals on software design, workflow, and “Judo”
Design | November 28th, 2012
As part of my upcoming book, I had the pleasure of interviewing Ryan Singer of 37signals. We talk about defining the problem, designing around tasks and individual workflows, and Ryan’s design process. If you make software, you really should listen, or if you prefer, a transcript is available below.
There are a few Skype issues early on, but they are fixed later in the video.
You should signup for the email list here, or using the form after the transcript. The book will be 25% off on launch day, so you don’t want to miss it.
Designing Around Tasks
Nathan: So I’m talking today with Ryan Singer of 37signals. And Ryan, you’ve been a huge influence on me as far as my approach in designing the user experience of the application and how you break down those first problems. So thanks for talking with me today.
Ryan: Yeah, sure thing. Glad to be here.
Nathan: So I wanted to ask, starting off, after you’re presented with an idea for a new application, where do you start in the process?
Ryan: So the short answer is, I always start by sketching out some kind of interface. First of all I want to be able to break the problem up into a set of important flows or processes that you’re going to go through. I’ve found that when I start designing a single screen I can get a little bit too caught up in just making the screen look cool.
Ryan: Or making it interesting to look at. And most of the time it’s actually not the individual screen that’s so interesting. It’s more like, how do I take people through a process, you know? So, for example, I’m working right now on this application for doing some non-profit membership. It’s like, if you have a non-profit, you can sign up with this thing, and then you can really easily create a membership form that you can just drop onto your website. Like you can embed a little button on the side and it will take you to a membership form, and then somebody can fill out this form, enter an amount that they want to pay, and then they’ll create an automatic monthly membership for your organization.
And what I notice is that it seems so simple, like, okay, I need to make a membership form. You know? And in that case, it’s a no-brainer, right? I’m going to make a form to submit the membership, and I’m going to think a little bit about the state that I need, like I need to know their name and their email address, and I to want to know the amount they’re going to pay, and I need their credit card info, right? And then I need to have some kind of success state. So that kind of case is really easy.
The case where it starts to get a little bit more difficult is like, I’ve got the idea for this membership app, but now what do I need to do in terms of managing these memberships? Do I just make a big spreadsheet-type table of members and just call it a day, or can I think a little bit deeper about it? And one of the things that I noticed is that if you run any kind of monthly membership or monthly payment system, you really want to know about people who drop off because of expiring cards.
One approach would be, I’m just going to make an admin interface, you know what I mean? And then I’m just going to–all the members are going to be there, and there’s going to be a status column for active or about to expire or something like that.
But what I was realizing is that there’s actually some discreet tasks that you would want to do. One thing is I would want to check in on the system and be like, do I have anything that I need to worry about? I ended up designing a screen called Things to Do. It was basically–here are things that you need to take action on, for somebody who’s responsible for managing this system. And I ended up showing cards that are about to expire in the next two months and any payments that failed recently. And then there’s specific actions that allow you to– There’s something for you to do here. And what I’m trying to get at with this example is I had to decide that there was going to be a screen called Things to Do. You know?
Ryan: To decide that the important information on it was, I’m going to show these about-to-expire cards. And then I had to think about, if a card is about to expire, and I’m showing that this person’s membership is a problem right now, then what’s the process I’m going to go through to change that. You know? Like an updated card button. And then does that take me away to a different screen? Does it reveal a dialog? Does it expand in place? You know, there’s some decisions to make there.
And then what I want to do is I want to design that whole flow and then review it as a unit. So I’m going to do the Things to Do screen, and then I’m going to look at it. There’s three cards that are about to expire. And then I’m going to click on the Update Card; I’m going to update the card, and then I need to think about, where do I end up after I’ve finished the process. So I end up saying, you don’t have anything left to do because you updated everybody, or what. You know? Or do I land on the person’s member detail page, saying thanks, your card’s updated, and anything else you want to do here? I don’t know, right?
Ryan: The thought process. It’s about like, how do I decompose the problem into specific tasks that matter to the user. And then when I have the specific task that the user’s trying to do, like for their job or for their life, how do I think of that in terms of screens that I need to provide, and then elements on the screen, and then a flow-through time.
Nathan: What I really liked about that is rather than just listing the data that somebody might want, the default response would just be to list all the recent transactions. But you’re really focusing on, not here’s all the data, but here are the actions that you need to take as a manager.
Ryan: For me this is like a real practical application of the idea. People are trying to do something in order to make progress in their life. And that they even opened up their laptop, or why they grab the iPads. Because there is some reason that they went to your tool, because they’re trying to make some progress somewhere. And it’s not just like general, like now I’m going to do member management. Like I’m about to make a purchase decision on behalf of the organization, and I need to look at our cash flow in order to figure out how quickly we’re going to be able to refill our reserves if I make a major purchase.
Ryan: Or I’m looking ahead to do some budgeting, and I want to know, can I rely on every–Like maybe I think I’m going to need every dollar that we’ve got coming in monthly right now. And if one person doesn’t pay, then it’s going to be like, negative that amount. Do you know what I mean? Like maybe it’s that close. So then I’m looking at that. I want to make sure that I can rely on let’s say the next three months out, that every payment’s going to be there, unless somebody cancels. Do you know what I mean? That all the cards are in shape.
Nathan: Right. So you build in a method potentially to easily contact the expired cards, or things like that.
Nathan: I mean, just how important that is. I think–I was reading a blogpost from the guys who built the LessAccounting software and they talked about hiring somebody just to go through and call everyone who had expired cards. And just the difference that it made as far as their bottom line was substantial.
Nathan: Because these were all people that wanted to keep paying them. They just hadn’t gotten around to updating a card or anything like that.
Ryan: That’s really interesting. Because it shows how the jobs also–they’re not really a property of the tool. Like the job is something that a person has. A different person in the company with a different role is going to have different jobs. So if you’ve got — actually have a role in your company who was like, expired card monitor person, you know?
Ryan: You know, or nagger, or whatever, you know? That person is going to have very specific things that they need to see all the time. It might be different from, let’s say, the accountant. Where the accountant signs in and they want to see the Quickbooks export like as the first button, or something like that. You know?
Designing For Different Roles
Nathan: So how would manage those different roles, or those different jobs that people need to take into account without going too far and making it an interface where every single element can be customized?
Ryan: There are different entry points sometimes. So it could be that I don’t need to really make a different homepage, let’s say, for each role, but maybe it’s more that I’m aware that the person who’s interested in expired cards is also the same person who has X, Y, and Z other main tasks that they do.
I find it’s very often that you need to have the same interface behave in two different ways for two different roles. It’s usually more like, you know, responsibilities in a company tend to get divvied up. So it can just inform how you group the different features together in the interface. Like the accounting features, one way to do it would be to sprinkle them throughout the entire app. Where any time you’re looking at an entity, let’s say you’re looking at a member, or you’re looking at member behavior over the last month, or you’re looking at all expired cards.
It could be that each one of those pages has your accounting tool button on it, but a different approach would be like, what if the accounting person only comes in because they just need to get their data and they want to get out again; they don’t actually browse the system at all, in which case it wouldn’t make sense to offer this button all these different places. It would be like, they come in and they come out again. They just want to grab their export. So let’s just put the export button right on the bottom of the home page and we’ll condition that so that only the person with accounting permissions can see it. Something like that.
Ryan: It’s not so often that I have to really show this instead of that for this person or do different designs. It’s more about, how do I cluster the features and which ones need to be accessible relative to each other, if that makes any sense.
Relating Test Driven Development to Design
Nathan: Yeah, that does. So you talk about in several of your blog posts how test-driven development influences your design process. Can you talk about that here?
Ryan: You know, I’ve been thinking about that lately and I noticed that maybe it’s not even correct to say exactlythat you need to bring TDD into your design process. It’s more like a really nice example of a sensible working technique. Years ago, when I was kind of nerding out on development process and ways to work, and stuff like that, Christopher Alexander, he made this set of books called The Nature of Order, and Book Two was called The Process of Creating Life.
One of his key ideas is that order or design, or like the intelligent arrangement of things always happens in a step-by-step process of unfolding. You don’t just like make a five-year-old person. The person actually starts as a couple cells, and then they divide, and then things grow and expand and build on each other, and it’s this step-wise transformation. He argues that the design process should also be a step-wise transformation, where you’re going from one state to the next, and you always know where you stand, and then you make the few tweaks to get you from point A to point B.
And the reason that he argues, is basically that if you try and solve all of those problems at the same time in your head, man, that’s impossible. If you change one thing at a time, then you can see how it impacts all the other variables that are in play. You can see how it affects everything that you did so far, so you don’t have like 67 or 10 or 20 variable things all hanging in the air at the same time, affecting each other. The design process is like, I know what I’ve got, one thing, and then is it better? Okay, it’s better. Okay, I’m going to change one more thing. You know? And really taking the sort of conscious step-by-step approach, and to me I think that TDD is basically a formalization of that.
Nathan: Yeah, that does. You start with a failing test, and then you write code against that until it passes.
Ryan: Except, so, what’s a failing test in design? I mean, for me it’s like, this element feels like it’s floating in space too much. You know? Or this line of copy doesn’t clearly communicate what it needs to communicate, so I’m going to rewrite the copy and keep hitting reload until it’s good, and then it’s like, when it’s good, it’s green. You know what I mean? And then move on.
If you’re changing a piece of copy, and you’re changing the color of a shaded box, and you’re changing the border, and you’re changing the margin, and you’re doing those all at the same time, and then you change all four again and hit reload. How do you know where the improvement is? You know, because you have way too many interdependent variables that are all changing at the same time. So the essence of it is just like, picking one thing at a time and tweaking it against a stable background, and then judging pass or fail and then moving on like that.
Nathan: In one of your talks that you did, you were going through designing software for managing–I believe that it was also for non-profits, and you had an example of cutting out a whole bunch of possible form elements of this fairly complicated data model using a technique that it sounds like you call internally judo. Can you tell what you mean by that and how people can apply it to their software problems?
Ryan: The example you refer to is, I was working on an app for–it was also related to doing memberships, and we had the idea that we should have some kind of detailed model to track if they had been given a gift in return for their membership, and if it was a gift, like let’s say it was a T-shirt, like what size are they, so that next time we give them a T-shirt, we give them the right size, and stuff like that. And the data model was getting really complicated with all these attributes, so we decided, how about instead of all that modeling we just put a text area? And then you can add additional notes any time something happens.
And the upside of that is it’s really flexible, and will handle any kind of case we want. And we can build it in, you know, 10 minutes. Of course we’re not going to be able to query to see how many people have a size small shirt so that we can order the right number of small shirts, right? It’s really about the simplifying stroke, where you said, like, this idea of Judo, and what is the momentum of the situation, and make one simple design decision that just massively simplifies the problem.
The way that I usually think about it is, you know, the reason that I made that tradeoff and gave up all of the power of modeling the shirt size and so on is because it didn’t matter relative to the value of making progress on all the other things. I had this app out the door. But if I decided to go ahead and model all this extra data, it would have easily added another two, three, four weeks onto the project.
Ryan: So the question becomes, what is the value of this addition relative to shipping, you know?
Nathan: Well, and the other thing is, there’s nothing preventing you from coming back later and adding it in, if that data model is truly needed. And I think another point that you made is, in almost all cases when you’re building business software, you’re replacing something like an Excel spreadsheet, or all these other less sophisticated tools, and so the solution you’re creating is many steps above that already.
Refactoring a Design
Ryan: It’s interesting what you said. You said, “There’s nothing to prevent you from going back.” But what’s interesting is that in so many teams, there’s a lot to prevent you from coming back. A programmer would say, “How well factored is the original design?” Like, how nicely composed are the different pieces of my design? So that if I need to replace one of them later, then I can easily find sort of the cut-a-long.
Ryan: And that is such a huge part of it, that people I think often overlook, because I’ve noticed that it’s really easy for those of us who are accustomed to being really careful about how we code things to say, “Oh, I’ll just come back and change it later.” But really, it’s not so common that people code with so much attention to the factoring, that they make the components with such clear boundaries relative to each other. People don’t often give themselves the freedom to make those changes later. You know what I mean? And it’s your design decision and the way that you implement the design that actually gives you that freedom later. So I think it’s just good to mention.
Ryan: It’s true. Like, I can always go back and make that change, but it’s because of some conscious decisions I made in how I structured the original design, you know?
Nathan: Right. If you design it correctly and write your code well, then you’re switching out a puzzle piece rather than trying to remove a card out of your house of cards.
Designing Tools, Rather Than Marketing Sites
Nathan: All right, so let’s talk about web applications versus websites. I think a lot of designers come into building a web application, and their entire background is in building marketing sites, and that kind of thing. How is the process different, and what would you tell those designers who are just making the switch?
Ryan: When you start working on an application, you can identify the major jobs that people are trying to do. I don’t think you can do that so well on a marketing site, you know? It’s really hard to identify five or six discreet things that for sure somebody who goes to the site is trying to do.
Nathan: Right. Because it’s not as task‑based.
Ryan: Exactly. Because it’s not a tool. So I find it helpful to draw the line around, is it a tool or not? If it’s a tool, then you have really discreet, clear tasks that the person is hiring it to do. If somebody’s using it for a purpose, then you can find out exactly what that purpose is, and then give them the best possible fit.
I would say that people’s marketing knowledge is not nearly that sophisticated where you can say, this is exactly what somebody wants to know, and the way that they want to know it. and I can judge different kinds of processes and stuff like that. I mean, I just don’t see that, you know, marketing seems to be —marketing is the land of A/B testing, right? It’s a crap shoot. And then you use measurement, usually, to figure out which of your random ideas is actually successful, and eventually you zero in on, you know, that way?
So I think that is the biggest difference, is becoming really focused on accomplishment, on making progress for people, on helping them do what they want to do, and then get going from that awareness of what those tasks are to expressing those as flows in the app. You know, as like sequences of screens or clicks or whatever.
Nathan: At that point you probably have a small number of users that are doing the same tasks over and over again, possibly many, many times a day, so there’s a lot of need to refine those tasks, make the completion of them as efficient as possible.
Nathan: That just wouldn’t be there in a marketing site.
Ryan: Yeah. That’s like the nature of the tool.
Ryan: You have a certain kind of clear, repeated task that you want to support. So that’s on the sort of design side in terms of, what are you thinking about that’s different, you know? I think you could also say that the role of graphic design and style and art is a lot less in a tool than it is in something that’s supposed to give you more of an emotional experience, you know? Like if you’re making a support tool, the effectiveness of your ability to promptly answer email and have low friction throughout your day is going to be much more valuable than what the color is or something like that, you know.
And then the other side, probably on the technical side, whenever I do things like websites I don’t care at all about the coding quality. Like, I just don’t care. Because there’s a certain baseline of flexibility I want. I want to be able to play with it and change it and mold it as I get new ideas, you know? But I don’t put nearly the amount of care into the code that I do with an application. And that’s because two or three years from now, I’m going to be going into that same application code and I need to understand it, and I need to make changes to it, and do so quickly. Whereas with the website, I mean, come on, you usually just scrap it and start over, right?
Nathan: Right. Especially if it’s a personal blog or anything like that where you just rework it every time.
Ryan: Yeah. So I think somehow the amount of awareness you have of, let’s say the kind of API, or how are you connecting with the code underneath, and that sort of thing. This becomes much more important when you’re doing application interfaces versus sites.
Nathan: So, let’s talk a little bit about workflow. A lot of people go straight into creating pixel‑perfect mockups in Photoshop, or something like that. That’s not really your approach. Can you talk about what your approach is?
Ryan: My approach is, if I have the basic concept for the flow, I can sketch that out on paper. I prefer to start more from the tool side than from the visual design side. So I’m going to say, what are the different affordances that I need to have on that space? You know what I mean? Like, I’ve got this box of space, you know, like this screen that’s my home screen, and I’m willing to go 950 pixels wide or whatever by this tall, and what do I need to have on there? I’ll just throw the elements on there that I need to have, and I’ll do it in code, so I’ll put a list of expired cards on there. I don’t know what the right format is, but I’m just going to put them there. You know, like maybe it’s a table, maybe it’s a bullet list, maybe it’s just a series of ideas. I don’t care. And I’ll put the right data that I need inside of that table or list or whatever, like the person’s name, the amount that they pay, so I know like how urgent it is, you know? If their card lapses maybe not a big deal, but if their $200 payment lapses, then bigger deal, right?
Ryan: So I’m thinking about, what do people need to see? What needs to be present here in order to afford the actions that people need to conform, to do the job. You know what I mean? So it’s more like I’m going to fence off a region of space, like here’s my home screen, and then I’m going to dump my little — all the pieces I need onto it. Like, I need to have a button for the Quickbooks export, a button for the member list, and my list of soon‑to‑expire cards. And then when I have those things in HTML, like really rough, basically unstyled, I’ll shuffle them around on the page until it starts to take form and make sense. I love this analogy that Brett Victor used. I saw him at the Strange Loop conference in St. Louis maybe a month ago now, and he was saying that the creative process is at its best when you’re like molding clay. You know, when it’s just like a lump of clay in front of you and you’re like, yeah, not right, and you pull it a little bit, and you squash it a little bit, and you’re like aha, there it is. You know? And the clay, for interfaces, is not really Photoshop pixels; it’s buttons and labels and containers and separators and links. You know what I mean?
Ryan: So what I want to do is I want to put the right — on the screen and then push them around until the arrangement works and it makes sense. So it’s somehow about identifying the region of space that I’m working with according to this flow that I sketched and then helping the elements that need to be there to do the job all into that region of space and then moving around to see if I can get it to work.
Nathan: So I find sometimes when I go straight to designing in the browser, rather than in Photoshop, and maybe this is a good thing, I end up with simpler designs and I don’t try out as many ideas because, to me the cost of seeing if this content should be over here, it’s higher in code than in Photoshop.
Ryan: Yeah. So I actually use Photoshop in this process—
Ryan: –in order to simplify this problem, so I’ll dump all the parts onto the screen, but then if there’s something that I have an idea for that’s going to take me too long, you know, I’ll actually take a screenshot of the screen, paste it into Photoshop, and I’ll quickly just make some selections around the elements that I have, like the field there, I’ll pop them into new layers, you know, and then just move them around a little bit so like I might imagine like, what would happen if I totally took this column and moved it over here and moved it under this other column, and I don’t have to worry — I don’t want to have to worry about breaking all my floats, or whatever layout I have working. So I’ll just take the screenshot, drop it into Photoshop, select those things, and kind of mash them around, to see if it’s promising, and then if it’s promising I’ll go back to the browser to do it.
Nathan: So instead of it being this linear process with clear stages, where you sketch, you do high-fidelity mockups, you do Photoshop, you code it, it’s a very interactive process where you move back and forth between those steps, using whatever tool’s best at the time.
Ryan: They’re not stages of the development process. They’re stages of the idea. And you can have a new idea, anytime, and it doesn’t mean that you have to rewind the clock on your development process. It’s more like, if I have an idea, what is the tool that I need in order to work with it in a sort of lump of clay way, and sometimes the right tool is pen and paper, because the idea’s really rough, and sometimes the right tool is Photoshop, because the idea is really visual and sensitive to detail. And sometimes the right tool is HTML because it’s more about getting the right elements on the page and functionality. Do you know what I mean?
Ryan: I can have an idea, and go straight to HTML, because it’s just clearly formed in my mind how to do it. I could also have an idea for an alternate way to move the design and then I’ll break away and sketch a few things even though I have a fully built — working. You know what I mean?
Nathan: Right. Yeah, that makes a lot of sense.
Ryan: And I think it’s about also, there’s something about like, how you said, if I go straight to HTML, I’m going to do things a little bit more simply, because it’s what’s easier, you know? And I think that’s actually fine, as long as you keep this critical mindset where you say, if it’s not good enough, I’ll go to Photoshop.
Nathan: In web applications, it’s so important to focus around those tasks, because you are creating a tool. We don’t want to get caught up too early on in what textures to use or, you know, how I’m going to design this really detail, glossy header, or something like that.
Ryan: If you were making a website for a band, then the style is going to be way more important than anything else, because it’s about the emotional feeling that you want people to connect with, in order to say this is my kind of thing. Right? So it’s total interesting: When you get into this “jobs to be done” stuff, the original article that Clayton Christiansen wrote about it — I think it’s called Marketing Malpractice. A Harvard Business Review article, and he actually breaks jobs into three dimensions. He says that, jobs can be functional, social, or emotional, or any combination of the three.
I think when we talk about tool‑making, and focusing really on the tasks, we’re talking about the functional dimension, and then that isn’t to say that there might not be — maybe there is an important emotional dimension or social dimension to the tool in some way, and then that’s a place where we can say, let’s really bring in our design talent — our artistic visual design talent, and make that important in this part of the app. You know? I think the important thing is being conscious of what your prioritizing as you’re designing a certain piece. And is function the thing that matters to my customer right now? Or is it more the emotional thing, and then depending on the answer to that question, I can decide which to focus on for a given part of the project.
Maintaining a Quality User Experience For Your MVP
Nathan: So there’s a lot of talk in software and startups right now about creating a minimum viable product. And often that means — I think some people take that to mean, slapping together the quickest thing possible that gets the job done, and just getting it out there. So how do you maintain a quality user experience while still trying to get your MVP out?
Ryan: I think it’s all in the M part. What do you call minimum? That is an undefined term that everybody gets to bring in for themselves. You know? So like at 37signals, we’ll usually say, it’s a minimum in terms of which features we choose to build, but the features that we do choose to build, we have a minimum baseline of quality that we insist on. You know? So like if I’m going to build this feature, I want it to be well rounded, well tested, and I want to feel basically proud of it when I deploy it. You know? And if I don’t have the resources to give the feature that well‑rounded treatment, then maybe I shouldn’t build the feature right now. I think it’s as simple as, you choose your own baseline, and the whole principle of this whole MVP stuff is just being conscious of, how far do I need to go in order to provide the value that I need to provide. You know? And playing with that long.
Nathan: Because one thing that you don’t want to do is rush a feature out. Say you’ve maintained this level of experience all throughout your application, and then you have a feature that a customer’s asking for and so you want to get it out quickly, you don’t all of a sudden want something that’s really low quality that doesn’t match the rest of your experience.
Ryan: Yeah. The thing that really gets me concerned about that kind of pattern is that it’s fine if you do it once, but nobody does anything once.
Ryan: You know? Everything — it’s like the — it’s the downfall of marginal thinking. You know, if it’s like, this one time, it’s worth it to make it just a little bit better, even though there’s all these problems, it’s like if you keep making that same compromise over and over and over again, you’re going to reach a point where half of your app is junk. You know? So I think it’s really important to have a kind of discipline and an internal standard and a conscience about what you consider quality and consider being quality and what you want shit, you know and then using that as a criteria for whether or not you’re going to take on a feature at all.
Nathan: Let’s say a developer, who’s just getting into doing the design for their application, what’s some advice that you would have for them as far as the most important things that they should pay attention to?
Ryan: You can make a distinction when you’re doing visual design between a color choice that you choose for a style reason, and a color choice that you choose for a functional reason. And the best way I know to sort of point out this difference is to refer to Edward Tufty’s books. He wrote the classic book, The Visual Display of Quantitative Information.
Ryan: That was his classic. And what he’s doing in that is he’s saying, here are design principles for how to use color and contrast, and so on, but the design principles are rooted in cognitive tasks. So he’s saying, make it red because somebody who’s looking at this needs to see it—it needs to pop out to their eye, it needs to play on their brain in a certain way. Not because, like, red is cool, or because it has the right emotional tone to it, or something, you know? And this way of thinking is, I think, maybe easier for a developer-type person to relate to than an artistic way of thinking, which is more like, what kind of emotional response does it create in me when I look at it, you know? I mean, this is more an artistic thing. But, really, a lot of the design work that I do, I don’t consider myself to be strong at all with color and art and stuff like that. But I can make the visual choice about size and weight and position and relationship and so on, based on what needs to happen cognitively. Like, the fine print is small because you don’t want people to read it. You know?
Ryan: And the headline’s big because you don’t want them to miss it. These are like functional dimensions, it’s just that the domain is more in the perception and the brain, and stuff like that, than it is like, I need to have the expired button so that I can update a card info. You know what I mean? It’s still in the functional area, but it’s a bit more subtle, because it has to do with how the eye works, and how perception works, and how people scan, and stuff like that. So I would say if they first focus on the flows, and the jobs, then that already is like a very coarse-grained good way to make progress on the design.
Instead of making a giant spreadsheet table and then having captions, which is the default programmer way of looking at it, think of it in terms of separate tasks, and think about how to offer those separate tasks in terms of flows. And then the question becomes, if I’ve got three or four different tasks I need to offer on the same screen, how do I position them relative to each other, how do I emphasize one button and deemphasize another button, and why? And this is a good way for a very analytical, rational person to get into design, because then you can say, I know that this feature is more common and more important than that feature.
Nathan: And then you get into using size and contrast, and all of that to emphasize those, deemphasizing the other features.
Nathan: So what are some mistakes that, like, beginner mistakes that you see people making that really frustrate you or that you’d like to correct?
Ryan: I think I need to spend more time with beginners…
Nathan: I guess that’s true.
Ryan: …to really answer that well. The thing that I notice generally when I evaluate work that people are doing— There’s certain mistakes that we make even after we’re beginners. Beginner, middle, and end, we continue to make the same mistakes, which is that we don’t focus enough—we don’t ask ourselves the hard questions enough about what matters.
Ryan: That’s important. We don’t really decompose the problem and say, which things are important here? Why am I doing what I’m doing? And I mean this in a really practical way, like why am I putting this label here? Why am I writing this headline? Why is this paragraph here? Why would somebody read it, like, what is its purpose? Really taking that to heart and asking, what am I doing here, why am I doing it, why would somebody read it, why would it be interesting to them, what is important? That is so, so important.
And then the other thing is, I notice that when I review things with people, that they have a very strong tendency to focus on the pixels in front of their eyes. Like they’ll be working on a screen, let’s say this expired card screen, and they’ll be really focusing on the padding between elements, and how nicely the headline sits above the table, and stuff like that, you know? And how nicely it all looks unified and coherent, and so on. And you kind of have to snap people out of that and say, well, how did you get here? Like, what did somebody do to get here, and then, where are they going next? And think of it more in terms of, not pixels and space, but actions to time. This, I think, is really under-appreciated, that the main thing with an interface is actually the flows, the processes through time. I’m here, and I need to get there. How do I do it, and what does that process feel like? And it’s really important to review the process. We too easily review a screen. Like we’ll paste a screenshot to somebody and say, what do you think? Like, you can’t review a screenshot.
Nathan: Without knowing the flow and the actions around it.
Ryan: It’s the feel of it that really matters. And it’s a constant—it’s an evolution of context. You know what I mean? You have something in your mind, and then you click this, and then you click that, and your background knowledge as the user is shifting in response to all these steps. And you kind of need to build that up in yourself in order to properly review it. So it’s like, instead of looking at a screenshot, I want to deploy this thing to a staging server, and put myself in the mindset of the person who has this problem. You know? I need to create a new project. Okay. I guess I click this, and then I go here, and I do that. Really going through the process on the live code and using that as the judgment. Not looking at a screenshot or a Quicktime video or something.
Nathan: That’s good. Well, I think that’s actually probably a good point to end. So thanks very much for talking with me, and I hope people learn a lot from this interview.
Ryan: Thanks for having me. It was fun.
If you enjoyed this interview, signup below to get 25% off Designing Web Applications on launch day (December 12th, 2012).