Episode #94 – Agile Design and UX

Featured speakers:

Clayton Lengel-Zigich Clayton Jade Meskill Jade
Play

Clayton Lengel-Zigich, Jade Meskill and Kevin Goldman of 29th Drive discuss:

  • Agile in Design
  • Pen Sketching
  • Ideation and collaboration

Transcript

Clayton Lengel‑Zigich:  Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich.

Jade Meskill:  I’m Jade Meskill.

Clayton:  Joining us today we’ve got Kevin Goldman from 29th Drive. Hi there, Kevin. Can you tell us a little bit about what 29th Drive does?

Kevin Goldman:  Sure. We design and sometimes develop software.

Clayton:  We’ve actually done a little bit of work with you in the past. We wanted to talk to you today about design, and you mentioned design a little bit of software, and the Agile framework. What’s your experience with that?

Kevin:  Jumping right into it.

Clayton:  Yes, right away. It’s a 15 minute podcast. We’ve got to get going.

Kevin:  Oh! Its 15 minutes. That’s good to keep in mind.

[laughter]

Kevin:  Yeah, I was thinking about some things we could talk about today in terms of how we use some Agile processes in our design work. I think the thing that we’ve been using most, a process that we’ve been using most lately, is sketching.

When people talk about Agile UX, oftentimes they’re talking about getting away from deliverables, from traditional deliverables based on predetermined milestone schedules in a waterfall process. What we’ve been doing more and more, is really embracing the idea of rapid ideation, and using pen sketches to replace a lot of what we used to do, around flushing out our ideas in digital form.

Clayton:  Like a Photoshop comp. kind of thing? Is that something that would maybe be the old way?

Kevin:  Yeah. Let me describe it that way. Old way might be having an idea, wire framing it, iterating on the wire frames. Then taking the wire frames into visual design, iterating on the visual design in Photoshop. Then taking those visual designs, and then throwing that over the wall to the development team, and them developing.

Now what we’re doing is ‑‑ we have an idea. We’ll do a lot of pen sketches. We’ll bring in development right away, and actually do pen sketching with them, and start talking about the idea from end to end; talking about implementation, and all these development issues early in the process with design.

Instead of moving from the pen sketches into Photoshop, or the pen sketches into digital wire frames like an omnigraffle, we’ll move right from the pen sketches into prototype. The prototype might be built in Twitter Bootstrap. It might be built if it’s IOS, a prototyping tool for IOS or it might even be prototype to nextcode.

Clayton:  Yeah one thing I’ve always, I have a background in doing what you described as the old way of the designer creates kind of stuff in Photoshop that’s very flushed out and very like final basically.

Throwing it over the wall and then slicing it all up and turning it into a website and I’ve always thought it was interesting that when you got to that low fidelity like pin sketches kind of thing where you could really sketch something out and the crumple up the piece of paper and start all over again.

That was so freeing and it made it so much easier to collaborate with the people that were editing, the traditional kind of design developer barrier like the mis‑communication that always happened, that seemed like it went away.

Kevin:  It’s so true so that idea of collaboration I think is a big part of what development teams think about when they think about agile development. And the same thing with UX so you don’t have to be an artist to pen sketch.

Any of the stakeholders in the project can sketch an idea on paper. Customers, business, stakeholders, marketing analyst, anybody can sketch on a piece of paper. And so by making that the medium it allows the design process to be a little bit more inclusive.

Clayton:  Can’t lower the very so you don’t have to be a designer or artist or something.

Kevin:  Yeah and we’ve gone so far as to work with new customers or even existing customers and encourage them to bust out the pen and get their ideas out on paper and send them to us or a lot of times we work remotely with our customers so they’re not here in town so we don’t have the ability to just sit next to the person and flush out ideas but we’ll use sketch cameras.

There’re these great little IP Vogue cameras that sit on your desk, they’re only $79 and if we’re using a Google hang out or a go to meeting it allows us to show what we’re sketching on the screen and through the go to meeting or Google hang out. So we’ll send those cameras o our customers so they can do those same things back and it creates the concept of having a white board, but doing it remotely.

Clayton:  That’s pretty neat. Have you found that your customers are embracing the idea, are they resistant to it? Do they not want to jump into what they consider your domain, the design territory?

Kevin:  Yeah, there’s a lot of, there is a. For people who aren’t designers, there’s a feeling that their sketches aren’t going to be pretty. There’re a lot of disclaimers. I’m not an artist, I’m not a designer. That’s OK. We’ve gotten some really great ideas and sketches from non‑visual people.

Jade:  What’s it been like working with the designers like the people that maybe used to do it a certain way and having to adapt into this, even like you said, using Twitter which drafted current prototype, I’ve worked with a lot of designers who were very comfortable creating things in Photoshop, but when you get more clear towards the front‑end, they’re actually writing something that actually works and you can look at, they didn’t want to do that necessarily. What’s your experience with that?

Kevin:  I can only speak from my experience in the team, the people that I’ve worked with, and all of us have some degree of understanding the front‑end code, some more than others.

In some cases, a designer of the team might be able to create an entire prototype by themselves and they’re very familiar with all the latest CSS3 and familiar enough with Java script to get some of the basic interactions working, and at other times, we just have to collaborate.

If the designer on that particular project isn’t as comfortable, then we just pair them up with one of our front‑end developers so that they can really work day‑to‑day throughout the day on this task of creating the prototype.

Jade:  What’s like transition period been for you guys in making this change? Is it something that you were able to pick up pretty quickly or has it been a few months that you’ve been learning as you go or what’s that been like?

Kevin:  It’s been a constant evolution. In some ways, I want to say going back 15 years when I started doing design work because you’re always in the process of designing the design process, if that makes any sense.

Jade:  Sure, yeah.

Kevin:  I say with pen sketching, we’ve really been getting back into it. It was really a part of my early training coming out of industrial design. There’s a culture of sketching in industrial design, and then of course, there’s whole lot of years where I used only digital tools and now with the team that we built at [indecipherable 07:47] drive, which is relatively new, we’re really looking for new ways to collaborate when we started to pen sketch more, it really gelled and it was very quick.

Clayton:  What do you think is the biggest contrast that you see between moving towards this new maybe more agile direction versus the old way that you did things, the more waterfall, lot more hand‑off, and more formality around that?

Kevin:  The contrast between them?

Clayton:  Yeah.

Kevin:  Without sounding like a bunch of hype, I think the more agile processes in pen sketching in this collaboration that we’re talking about creates better ideas quicker. It really allows you to generate a lot more ideas, so therefore find the bad ideas more quickly and invest your time into the good ideas more quickly.

Jade:  Why do you think it allows you to do that?

Kevin:  The pen sketches, no matter what, specifically looks sketchy. It’s just so fast, you can’t get bogged down in pixel pushing, even if you’re doing what we call Greybox wireframes, which are very low fidelity wireframes. If you’re in OmniGraffle you inevitably just end up spending a lot of time trying to figure out how to invert an object, you have to search in through help and menus.

If it’s a pen sketch, you’re going to just sketch that in a few seconds and be done with it.

Clayton:  You’re not as tied to the concreteness that a digital tool might give you.

Kevin:  Yeah.

Clayton:  Some of that formality of presenting it to your customer and having them review it, all that stuff tends to add overhead and really changes the interaction that you have.

Kevin:  Totally changes the interaction. With pen sketches, they never confuse the sketch with something that might be final and that happens a lot in design where if we present a wireframe, we know in the industry what a wireframe is and what to expect out of a wireframe, but sometimes a customer, they might just wonder why everything’s grey. We’ve actually heard that.

Jade:  I don’t actually like this color palate.

Kevin:  Why is every button grey or why is that font not consistent? They get caught up on those things. But a pen sketch is so far removed from the final that whole confusion or misinterpretation of what you’re trying to communicate is not an issue.

Jade:  I always try to ask like practical questions, maybe I’m a project manager or I’ve got a team that has some developers and some designers and we’re doing it the old way, what advice would you give to someone like that, who wanted to try and do something that was a little more collaborative?

Is pen sketching the first steps? You just jump into doing that or what would you suggest that person do?

Kevin:  Yeah, pen sketching is the first step. The sooner you can knock down that first hurdle of that first person drawing their first line and feel it, that they don’t have to be an artist, the better. It’s very quickly that people, I think, get over that. The other thing I would recommend is we do something called a design studio, which is an old concept that also comes out industrial design.

The idea is that you get a bunch of stakeholders, designers, developers, whoever is on the team together for a half a day. Let’s say two to six hours and you have either a whole product concept or part of a product that you’re trying to develop and you work together collaboratively to flush out the idea for that section of the product.

What we do, the way that we’ve structured a lot of the design studios is we’ll have an introduction and that’s lead by, usually it’s a lead designer on the project, who will give the context and constraints for what we’re trying to solve.

Then, we’ll do, let’s say a half hour where everybody goes away and pen sketches their ideas for how to solve that problem. Then, you come back and each person gets five minutes to present their idea to the team.

Then, you repeat that process sometimes two, three times and what happens in two or three hours, you get 40 ideas of how to solve a particular problem. Even more importantly, you get everybody on the team on the same page about what that process was. What worked, what didn’t and you get this building of ideas on top of each other. You have an idea, triggers an idea in my mind and then, we build on that.

Jade:  Agile talks a lot about continuous improvement, so I’m curious, what’s something that you think you might try in the future to improve on this process?

Kevin:  Oh, man.

[laughter]

Jade:  I didn’t mean to put you on the spot.

Kevin:  Just about everything so down to how we can communicate better in the sketches with call‑outs and interactivity and how we can communicate those ideas, more of a how we can…Sometimes, we do need to have a snapshot of what happened in that design studio, so we can refer back to it.

Often times in the design studio, there’s a lot of hand waving that goes along with the pen sketches, so we’re trying to figure out to capture that. I think there’s a lot of room for improvement there. Working remotely with customers is just how it’s done these days. I think there are just a lot of places where we can improve in our work with people remotely.

Estimating projects is always very difficult, probably on the development side as much as it is on the design side. We can definitely try to improve how we set out expectations for how we bill something, how we structure timelines in advance of actually doing the work.

That’s a big shift. One of the biggest, especially for service companies who are in‑house. If you’re basing your bids and your timelines off of waterfall deliverables, it’s very easy to say, “This milestone is this much and this much and this much. It happens on this day, this day and this day.” When you follow a more collaborative approach, it’s not as clear cut at the onset of a project.

Jade:  You have to go into more value based fees…

Kevin:  Exactly.

Jade:  …and it’s a lot more difficult to sell.

Kevin:  Exactly.

Jade:  Kevin, we really appreciate you coming down. To be fair, just so everyone knows, we asked Kevin yesterday if he could… If you’d like to record a podcast and you said, “Sure.” So we said, “Come tomorrow.” It was a little short notice, but we appreciate you making it out here.

Kevin:  Yeah, thanks for having me.

[music]

Announcer 1:  If there is something you would like to hear on a future episode, get over to integramtech.com/podcast where you can suggest a topic or a guest. Looking for an easy way to stay up‑to‑date with the latest news, techniques and events in the Agile community, sign up today at agileweekly.com. It’s the best Agile content delivered weekly for free.

The Agile weekly podcast is brought to you by Integram Technologies and recorded in Gangplank Studios in Chandler, Arizona. For old episodes, check out integramtech.com or subscribe on iTunes.

Announcer 2:  Need help with your Agile transition? Have a question and need to phone a friend? Try calling the Agile hotline. It’s free. Call 866‑244‑8656.

One thought on “Episode #94 – Agile Design and UX

  1. Pingback: Integrum’s Episode #94 – Agile Design and UX | 29th Drive

Join the conversation on Facebook