Design in Agile Software Development

Derek Neighbors: Welcome to another episode of ScrumCast. I’m Derek Neighbors.

Jade Meskill: I’m Jade Meskill.

Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich.

William Price III: And I’m William Price.

Derek: Today we want to talk about…

Jade: The third.

William: The third.

Design in Agile Software Development

Derek: Design in Agile Software Development. I just want to start an open dialog on, what are some of the challenges, of implementing design in an iterative methodology.

Jade: We are talking web design specifically.

Derek: Lets start with web design and if you want to go beyond that we can. But lets start there.

Jade: It sucks.

Hard Transition

William: I think my experience with design for a website or whatever is that a designer comes up with some idea of something. It’ like a waterfall. Everyone’s used to the designer comes up with something and makes this nice pretty PSD. Somebody else slices the PSD up and it turns it into HTML and CSS at some point in time, and then that becomes your web app.

I think that’s probably like 90 percent of the people out there, their experience with doing design. When you take than and try to put that into Agile, it makes it really difficult to say, “Well, this week we’re working on this set of features, and we need to design for that now or soon or whatever,” because I don’t think that’s how most traditional designers work. They need more lead time than that.

Overlapping Of Skillsets

Clayton: Yeah, I think from a designer’s perspective the lead time is typically considered the biggest challenge, just the pace. I think a bigger challenge is knowledge and appreciation that overlaps as much as possible between developer and designer.

You often hear people say, “Everyone is a designer.” That makes me kind of uneasy, because I think design is a craft. It’s a skill that you have to hone over time. Anyone can hone it. Anyone can learn it. Anyone can learn to draw. Anyone can learn to think well and design. The thing that makes me uneasy about everyone is a designer is that when you say that it’s like, “Oh, so now I’m a designer today, instantly.”

As a designer that makes me uneasy, but what I need to do is develop relationships with developers and with product owners where I can appreciate their input and work with them as fully as possible. As a developer, being involved in that process and considering it meaningful I think is often missing.

There are some developers that will say, “Oh, yeah. I think that’s important.” But do you spend time learning the fundamentals of design and things like that? Or do you just go by what you think looks good?

Then as a designer, appreciating the developer’s input and not just thinking, “Whatever sexy pretty thing I come up with, is the best solution” because it may not be the best solution for the process.

It may be a huge nightmare for everyone involved. It may be far more expensive than it’s worth. You might be developing something that looks great, feels great, to the product owner but gets torn out a month later because users don’t use it. Working together and having a tight relationship, that’s the biggest challenge in my opinion.

Everyone is a Designer

Jade: Well, I think to address something you said. You’re talking about everyone is a designer. Some of that came from a Thoughtbot article that we read as a team and had some discussion about. What I think he’s…

Clayton: Or is it, Derek who said as a team like three years ago?

Jade: Yeah, yeah, yeah. Where’s your Mike Cohn I‑know‑everything card? Can you pull that out right now?

Clayton: [laughs]

Jade: Now I just lost my train of thought. Thanks.

Clayton: [laughs]

Derek: Thoughtbot.

Jade: Yes, Thoughtbot. So I think what they’re trying to drive at is not that everyone is a professional designer in the sense that we think but that everyone plays a role and should be conscientious of design, right? It’s not acceptable for developers to just say, “Well, I don’t know anything about that because I just write code” and crank out some really crappy‑looking interface.

We should be at least conscientious of the basics of what we’re doing and that it should be professional and not, like I said, some hack job that you know a developer put together because you can just tell. I think that’s what they’re driving at.

Sensible Defaults

Clayton: Yeah, so I think an analogy would be I wouldn’t be able to figure out a good color scheme and whatnot for, say, my house. I’d probably paint the walls white and leave them some stupid color, and I wouldn’t bother decorating. But when it came to arranging the furniture, I wouldn’t put the couch in the middle of the room facing away from the TV or something stupid.

So I think there’s something to be said for maybe you’re not very good with the design theory or color theory or some of the things that may be more traditional design when you think of design are. But in terms of maybe the user interface or how things flow or just sensible decisions, I think that’s the kind of designer that everyone could be. Just take a step back and say, “Does this make sense? Yes or no.”

Driving The Car

Derek: Analogy wise maybe it’s similar to, I expect most adults to be able to drive a car. I don’t necessarily expect most adults to be able to race formula one, or race NASCAR, or race the Baja 500.

I think that there’s definitely a difference of level of, and I think there should be expectation of people who are developing software to understand, like you said Clayto, to not put the couch facing the opposite direction of the TV in a functional living room space where 90 percent of the time people will be watching TV.

I think we see developers do that every single day, do things that make absolute no sense. I think to me I’ve got two additional questions on a design in iterative fashion.

One is we start to see iterations become shorter and shorter. I know one time in a Scrum that was pretty much a given that a sprint was a 30 day or month long function or iteration, and now we’re seeing sprints down to, a week are pretty normal. Two weeks are probably now the standard.

In some days we’re pushing more towards Kanban where it really is a sprint might be, an iteration might be, in a day, or less than a day. How’s it feasible to, not even talking about coming up with the design, but how’s it even functional to implement the design in that quick of a time frame.

What are some of the challenges? We’re starting a sprint on Monday, we’re ending a sprint on Friday and we’ve got to go from design implantation in five days. What are some of the challenges around that?

Tools Lacking

William: I think one of the challenges is the tools. Just to make an excuse for designers, that I think is legitimate, is that the tools suck. There’s been a push to do all your design and development in the browser. Then there’s this push to handle it all CSS3.

Do everything you possibly can CSS3. Granted the great designers out there are able to be really involved in the front end development and do minimal stuff in Photoshop. In general to work fast is difficult with the tools that we have. I would love to see that improved.

One thing I’ve been trying to get in a project that we would do here from a designer is to as much as possible think on a feature oriented level, instead of a site wide level. To design just for what needs to be designed, you don’t need to design a whole page.

If you’re developing a feature and it’s a widget in the corner of a page, the whole page could be a wire‑frame and that widget could be designed. The challenge there is to be consistent throughout, to have a good vision of where you’re going.

I think a designer that has good skills should be able to do that, should be able to stay consistent throughout, to keep going within the same vein of things. To keep the look and feel going but be able to turn around a widget fairly quickly and not to get so concerned about the whole page.

I’d be really interested to see a project go from conception to launch with that whole process. So far it’s been a challenge to see that. I think that could be a potential solution.

Understanding The Big Picture

Jade: That’s one of the complaints that I’ve heard from a lot of designers. I need to understand the big picture. I need to understand the world before we can start implementing some of these designs. If we start on sprint one, let’s just say with no design in place, we didn’t do a design iteration or anything like that.

How do you see that developing? How do you maintain that vision of the bigger picture and the bigger idea when you’re doing it week long sprints?

William: That’s not a rhetorical question? You want me to actually answer that?

Jade: No I want you to.

William: [laughs] That’s a difficult thing to ask. I think there’s different scenarios. Are we talking about sprint one is a true sprint one and there isn’t this backlog of things that have been predetermined. I think that’s one thing that weighs designers down is when there’s already a whole bunch of stuff predetermined, and they’re saying, “Wait, I can’t think about this. If this is going to happen, I need to think about this.”

I think a great example of success is Tumblr, which is founded by two guys who had a division of labor between them, but they had a major overlap. They were both very invested. One was a developer and one did business and design and stuff like that as far as I know.

And they worked iteratively. I think Tumblr has a beautiful interface. It’s very usable. It’s very simple. I don’t know what their sprints were, but they worked a portion at a time. They kept maintaining. I think whenever they came to a big impasse, as far as I can tell, where there’s going to be a major shift, that’s where you look at, “Do we refactor design?”

I think there has to be a willingness to say, “OK. We’re going along. We’re consistent. We’re going a certain direction. OK now, we’re going to make a big leap in a different direction, or a change. We’re doing something we never foresaw doing, and so that means that we need to go back and rethink what we’ve already done.”

I think the big fear is, “We’ll never get a chance to do that, and if we don’t got it right the first time, we’ll never be able to improve.”

Jade: I think that’s a little bit easier to accomplish when it’s a couple of people, and you’re personally invested in…You’re not only just the developer. You’re also a stakeholder and product owner and all those things. It’s easier to manage that relationship because the relationship is with yourself.

In a typical scrum team of five to nine people, that gets a lot messier and a lot harder to deal with. I don’t know what the answer is to try to do design at the same time as development. You see a lot of people trying to run design ahead of the game, but that leaves some opportunity for mistakes and waste.

“If we don’t do that story next sprint, now what?” The world changes, and we’ve got to re‑prioritize the backlog because some new business requirement came up or some new opportunity showed up, and now, there’s no design for that. Now, it’s chaos and panic.

Modern Skills

Clayton: I think that as we get towards the shorter iterations, the idea of doing work in Photoshop and then slicing it and chopping them off into a lot of stuff, I think that totally goes out the window.

The same way that I don’t think you can go forward from, today, being a developer who just writes code, you have to have other skill sets. I don’t think that you can be a designer who doesn’t know HTML and CSS.

I think that if you can get to a point where you are getting out of Photoshop as early as possible, that gives you the ability…I think there’s something to be said for having a Photoshop mockup of something to show people because people think that way or they like that stuff.

If you can do design upfront or at least do a week ahead, whatever sprint ahead, where you’re not designing specific features that you might not do, but if you’re doing things where you say, “Here is the overall look and feel of the site…”

Personally, I think that if we got towards where people are using style guides where you could say, “Here is the overall look and feel of the site, and here’s the style guide for 80 percent of what you’re going to run into as you’re developing the feature,” then the developers can hit the ground running with their iteration, not having specific design for every single feature, but they could have enough to get by where they’re not going to get hung up on something.

And if they do, it’s probably just a quick fix. They could just talk to the designer about what’s the best way to handle this. Then, now that that frees up the designer to work on…If there are specific feature things, you could do something where they’re one step ahead of you where the world isn’t going to change that much perhaps.

Style Guides and Frameworks

William: Yeah, I think a style guide is a great way going back to what I’m saying later about keeping that consistency. You could spend that time upfront developing that style guide of colors and padding and margins and things like that, grid, all that kind of stuff, and then live inside that model, that framework.

Designers do great inside a framework. I don’t know a single designer that resents having a framework to work with within. It’s actually freeing. I think another thing that can speed up the process is, I agree with Clayton totally. That you ought to have that ability to be a front‑end developer at least the HTML and CSS and to do that.

But instead of spending all your time in Photoshop, maybe spend more time with pencil and paper. One of the first things that they’ll teach you in your design fundamentals class in art college is your first idea usually seems great and almost always sucks. Sometimes your first 10 ideas suck.

One of the first assignments I ever did was I had to do a logo of my initials a hundred times, a hundred different logos. It was bang your head against the wall annoying. After 50, 60, 70 of them, you can’t think of any new way to do it.

As a designer, you learn to be that way. So if you go straight to Photoshop, it’s a struggle to do that because it takes time. But if you go straight to the browser, it’s even more frightening because it’s like, “Well, if I do all these and I get it but it’s not the best solution, I have to rip it all out and start over and rip it all out and start over.”

But maybe if we spend more time as designers with pencil and paper going through that mental process of bad idea, bad idea, bad idea, decent idea, bad idea, bad idea, bad idea, there’s the one, and then go straight to the browser and implement. Or like you said, minimal time in Photoshop creating an element like a tiled background image or an icon or something like that, and then get that in there.

I think that could be a great process for a designer where they know their style guide. They know their framework. They hash through all the ideas on pencil and paper. Then they get to the browser as quickly as possible.

Usability and Discovery

Derek: One thing I thought that was interesting at the beginning, as you said, it’s really difficult when you see the entire backlog and to not think about everything in that backlog. I think that developers fall in that same trap. “We’ve got an architect for the 491st thing in the backlog even though we’re on sprint one.”

In the back of my head, I’m wondering, “Is this one of the reasons that maybe Kanban has taken a little bit of frontrunner approach, and that a lot of people are liking it is that it tries to move so quick and obfuscate more than the next 10 items? Does it give a calming effect to designers and developers that they’re only worrying about the next two or three things as opposed to item number 391?”

I think it’s part of a different discussion but interesting nonetheless. So product owners hide as much of your backlog from your developers and your designers, and you might see their velocities go up perhaps. It’s a theory. You might try it out, but you might try it out.

The next question I have, and this starts to go into a different element of design and what we’ve been talking about here which is probably more of the visual design and that is…I hear a lot of people say and really talk about, “How do you do usability or discovery?”

“How are you going to ask an audience of people? How do you really get these questions answered about what the product is really supposed to do and how it’s supposed to work?” I think a lot of people even ask, “What happens to the business analyst?”

We used to have this business analyst. Now, we’re in this Scrum team. How does a business analyst go gather data for a particular user story during the actual sprint?

If I’ve got a 5‑day sprint, how do we do discovery on what the best way to solve this problem is within a 5‑day sprint or a 10‑day sprint, opposed to being able to gather some of that information up front to understand that? Maybe talk a little bit about some of the challenges or some of the things that we lose by not doing that as much anymore as we used to, or how we can incorporate that into a shorter sprint length or sprint cycle.

Clayton: I guess I’ve never really been convinced that…Even if you had a business analyst and you had people that were out doing a bunch of research and interviewing potential users and blah‑blah‑blah, you’re never going to come up with a great solution on the first go anyway. It seems like you have to go take that leap of faith into Scrum or Agile or whatever and say, “I’m not going to get it right the first time, but I’m going to get something out there that we can start working with and gathering feedback on.”

I feel like it’s like an “emperor has no clothes” thing, because there’s a lot of people that are probably thinking, “That might work for your project, but, trust me, I really need to know all these details for my project.” I don’t think that is the case in almost any instance.

Derek: Let me, maybe, rephrase it to make sure I’m understanding. You’re suggesting a way to combat this is to actually release shippable software as often as possible and use the shipped project as the way to collect that information. Once you get that information, iterate and make the changes necessary, based on the feedback you got from real customers.

Clayton: Right. Yeah. Actually use the point of Scrum or some other process.

Okay To Not Be Perfect Right Away

Jade: I think that’s pretty interesting. Maybe that is some of the source of the problem. We’re OK with not getting development exactly right, right out of the gate, but a lot of the projects I’ve worked with, they’re obsessed with the design being correct the first time out of the gate.

“We’ve got to get it right. We can’t afford to mess this up, because then nobody will ever come back and use the system again.” We’re psyching ourselves out, because we feel like we’ve got to nail this thing the first time around. We completely forget to be Agile about the design itself.

Excitement Vs Mundane

William: Yeah. It’s a lot like the whole Flash mentality of, what, the early 2000s, which was, come out with this Flash app that’s your whole site, that’s so fun and there’s things flying and noise being made. The Internet was so new to people that they went and used it and were like, “Oh, my…You can do this on the computer? This is amazing!”

Then, it lost luster because people were like, “I just need to get this data. I just need to know how to get there. I just want to know what the hours are. Just tell me.” Now, obviously, with mobile, everyone knows the implications of that.

Point being is there was this ability that people had, developers and designers to shock and awe people and to get them really thrilled. That was mostly because the Internet was so new to most people. That’s over now. It’s done. You’re rarely going to put something out that is going to excite someone just because they looked at it.

If you’re a designer, you’re going to look at design and be excited by people’s good work. If you’re a developer, you’re going to look at ideas and concepts in development and be excited by their elegant solutions and things like…

Jade: APIs.

William: And APIs. Yes.

Jade: [laughs] Their sexy, sexy APIs.

William: And their fables.

Derek: Shiny.

Jade: [laughs]

William: But your common user doesn’t care. I mean, they do but they don’t. It’s really a combination of everything that matters to them. Can they get what they want quickly? Can they get through it easily? Is it confusing or not? Does it look good? Meaning, good to the layman, decent, not look bad. Does it look broken? Does it look inviting? Does it communicate the brand?

Those kind of things are the big pile of influence on whether or not a user wants to keep using it. The big temptation, I think, with design is that a lot of times, product owners that have an eye for design and designers want it to be so attractive and so exciting that anyone who looks at it is going to be really impressed.

I don’t even think it’s an ego thing most of the time. It is sometimes, but most of the time, it’s a business value thing. It’s like, “I think that if this gets perfect, then people will be thrilled and excited and think it’s the best thing that’s ever happened.” But it’s not that simple. Users don’t work that way.

What Can I Understand

Clayton: I think another big part of it is that if you’re the product owner for some start‑up or even just a product owner, maybe you don’t understand the technical details, but you know what looks good and what doesn’t, according to you. I think that’s why everyone gets so caught up on the design stuff.

It’s like, “I don’t really know how this workflow should work, and I don’t really understand what you’re doing in the ‘backend,’ but I can look at this and say, ‘Wow, that’s really pretty.’ There’s other websites that I like, and they look kind of like this, too. The people that I want to attract on my website, they look at those websites, too.”

It’s just something…It’s simple. It’s a high‑level thing, but everyone has an opinion about it. Product owners generally don’t have an opinion about how you implemented that technical thing, but they have an opinion about how it looks.

Jade: I think it’s a trap, too, because it might look really good, and it’s a total disaster from a functional standpoint. It might look shiny and pretty, but when you go to implement it, users just can’t understand it. “But, man, it looked so good on that comp that I got.”

Overnight Success Fallacy

Derek: I think the biggest trap that people fall into is, everything was an overnight success. If you look at ‑‑ I use an example of Twitter. If you were to look at Twitter today, it looks pretty reasonable. It’s got some pretty sexy UI elements. It’s got some nice UX layouts, where they’ve got some sliding drawers and some techniques that are a little bit more cutting‑edge.

If I were to try to create something that competed with Twitter or had functionality similar to Twitter, I wanted a timeline feed, perhaps. And I said, “I need my timeline feed to look just like Twitter, because people will not accept a timeline feed that’s not as good as Twitter’s timeline feed.” What we forget is, rewind back five, six years to when Twitter started and look at what Twitter’s timeline…

Jade: Look at the first release of Twitter. Ugh. [laughs]

Derek: The new, and I’m doing air quotes here, Twitter didn’t come out until a few years ago, after or, not even a few years ago. Less than 12 months ago, after they’d already taken almost $60 million in funding.

I think, with it, that people get obsessed on, “I have to compare myself to the thing that is fully funded and has been out for a better part of five, six years and has hundreds of millions of users on it. That’s my benchmark.” Instead of saying, “We’ve been working on something for three months, and we want to release the first version within the next quarter. We need to iterate over how our users use this product.”

I think you’re absolutely right. People get way too fixated on, “We have to ship finished, and we can’t iterate, but code wise, you can do whatever you want. If we need to add a feature here and there, that’s great.

But the minute we put a feature out the door, it has to be perfect, because we can never come back and visually make it different, functionally make it different, or aesthetically make it different, or people are going to say that we failed and we didn’t work.” I think that that’s a mistake.

Feature Parity

Jade: I think there is some challenge in that, though. Because the Internet is moving at such a fast pace, there are some pretty revolutionary things that come out, that do become almost mandatory, that do become expectations of how things should work. I think that is a challenge that we’re always going to be faced with, is how to keep up with the things that are now mandatory, that six months ago were nice‑to‑haves.

William: I agree with you, Derek. I think, I would challenge a little bit the idea that people, product owners in particular are comfortable with not having all the functionality as well.

Derek: Yeah, I agree that a lot of them don’t do that.

William: You go, “I want to go up against this x thing that’s been around for six years.” They’ve had six years to develop all their features. When I come out of the gate, I want to be at par with them, in six months.

I think that’s a major issue for design, because what you end up doing is just, as quickly as you can, designing everything. It over‑accelerates the pace of development. You shouldn’t be trying to develop. The one that product owners love to reference, Facebook.

Jade: Facebook. Yup.

William: In six months.

Jade: But it’s already been done, Billy.

William: “But it’s already been done.” Yeah. So why are you doing it again?

[laughter]

Derek: My idea’s different.

Understanding The Problem

William: Here’s the thing about really great design. Going beyond the skin of it, going beyond even the couch analogy, is, it takes time to really understand whatever your problem is ‑‑ however you want to look at it. Your problem, your problem‑solution analogy, your friend, your creation, whatever. It takes time to sit with it.

Going from an iterative perspective, allowing things to come out of the gate less than perfect, and building from the ground up. I’m not talking about slowing down development or doing it deliberately more slowly, but increasing the amount of releases you have, and accepting that you’re not going to make a world‑changing design on day one.

What that does is, it allows your design team to really get to know the brand the way the users encounter it, to get to know the way the users want to use it. You get that time to realize, what people are doing with Twitter is not what we thought they were going to do with it. The way people are using this or that product, this was not what we expected, but this is what they believe we are and what they want us to be for.

Then, it allows you to go back and do what new Twitter did when they said, “We’re not a social network. We’re an information network. From now on, that’s what we’re focusing on. We’re going to design for that.” Then, you can come out with something that’s sexy and impressive and great.

Jade: And functional, and accomplishes the business goals.

William: Yeah. It’s not contingent on success, that you come out of the gate at that point. Which is the big fear, is that if we don’t come out of the gate at this level that’s way up here, then we’re going to fail, because no one is going to want to look at it. But you don’t even know where people are at with it yet.

Derek: Thank you, guys, for your time. I think, hopefully, in the next quarter or so, we’ll do another one of these on design and talk about some of what we’ve learned and where we’re going with it and maybe invite in a couple of outside guests and see how some other shops are doing it. Until next time, we’ll see you. Thanks.