The goal of Lean UX is to take the focus of user-centered design off of documentation and put it squarely on the experience. The way to do this is to view any design idea as a hypothesis. With a focus on the experience, you can validate or invalidate this hypothesis much quicker. The sooner you reach this validation, the sooner you can focus on designing and building the correct solution.

Jeff Gothelf is a firm believer in the Lean UX process. One of the key aspects of Lean UX is how collaborative it is. Jeff says that the separation between design and development really needs to be broken down. That the people who are collaboratively building this experience or product need to be collaborating with each other much more frequently. Jeff discussed the idea of Lean UX in his virtual seminar, Lean UX: Getting Out of the Deliverables Business, and the audience posed a number of great questions.

In this podcast, Jeff and Adam Churchill address the questions that there wasn’t time for during the live seminar.

Here’s an excerpt from the podcast.

“…The core of Lean UX is bringing dev and design into the same time frame. That’s what we’re focusing on now.

To do it successfully, there’s an amount of upfront thinking, at the very least, that’s done by the product and design teams before we plan the next iteration.

There’s a little bit of heads up that says here are the things that we’re likely going to be working on in the next iteration. Let’s do at least a little bit of thinking around that. If there needs to be a little bit of illustration or visualization of that thinking, then it’s very, very lightweight.

It could be a sketch on a piece of paper, it could be a very rough wireframe. We’ve gone into iteration planning meetings where we’ve drawn on the whiteboard and said here’s how we’re thinking about solving this problem.

That engages the entire team in a low-fidelity way of articulating how they think the problem should be solved. Because it’s a sketch or it’s a whiteboard drawing it’s erasable. People can write over it. You can redraw it. You can redo it. That encourages collaborative problem solving…”

Tune in to the podcast to hear Jeff answer these questions:

• How do you validate with the engineering team what they’re going to need before the project starts?
• Does Lean UX require new tools or skills?
• Does the UX team build the wireframes or is it the developers?
• Does Lean UX work for larger, legacy organizations?
• What can you do if you don’t have access to your end users for testing?
• Where does user research fit into this process?
• How do you overcome expectations for wireframes that are already set?
• Does the Lean UX process reduce the number of hours spent on a design?

Do you have experience with Lean UX? Share your thoughts in our comments section.

Recorded: December, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: Welcome to the SpoolCast everyone. Jeff Gothelf recently stepped away from his busy role as the Director of User Experience at TheLadders.com and joined us for a virtual seminar, Lean UX: Getting Out of the Deliverables Business.

We know Lean UX is an important topic and, quite frankly, one that some folks are still trying to get their head around.

We had lots of good questions and comments during the seminar. We decided to have a follow-up conversation that we knew we could make available as a podcast for you.

Jeff has graciously offered to come back and tackle some of the questions that we didn’t get to address and some of the ones we thought were worth talking about again.

If you didn’t get to listen to this particular seminar you can get access to the recording in UIE’s growing User Experience Training Library.

Right now we’ve presently got over 80 recorded seminars from wonderful topic experts just like Jeff giving you the tips and techniques you need to create great design. Hello, Jeff, welcome back.

Jeff Gothelf: Hi. It’s great to be here.

Adam: Jeff, for the people who weren’t with us for your seminar earlier in the month can you give us an overview of what they missed?

Jeff: Sure. We talked about this idea of Lean UX. Really it’s a way to rethink about the way user-centered design is being done by taking focus off of the documentation.

Instead of the end goal of the design phase of any project being an actual document that describes an experience and focusing more on getting to that experience as quickly as possible to validate your designs.

The idea was any design idea, any user experience focus of a project is initially a hypothesis, regardless of how experienced you are or how much subject matter expertise you have.

You have a hypothesis about how to solve a particular business problem. And so the sooner that you can validate or invalidate that hypothesis, the sooner you can be designing and building the right experience, the right product for your customers and your business.

The focus is taking user experience design practices, taking a look at the entire toolkit, and figuring out which tools to use at the right time and at the right depth.

Now in addition to that, it’s about taking those tools, using them at the right time and at the right depth, and collaborating much more openly and much more frequently with the team that you’re actually building the product with: with developers, with product managers, with QA, stakeholders, and subject matter experts and really building this culture of shared understanding of where the project is going, where the product is heading, so that as much parallel work can take place.

In other words, instead of waiting for the IA to finish their work and the interaction designer to finish their work and hand it off to the visual designer who then hands it off to the developers to build, how much of that process can happen collaboratively and how much can happen in a parallel track?

That’s a lot of what we talked about is different techniques and ways to work more collaboratively as a team with UX design driving a lot of that focus.

Adam: Great. Let’s get to some of those questions. John wanted to know how do you validate with the engineering team what they’re going to need before the project starts and during the project do you need to circle back with them? Is it enough?

Jeff: That’s exactly what I meant by collaborative. This separation of dev and design really needs to break down as much as possible.

The project teams that are working together to build a particular product or a particular experience need to be collaborating much more regularly and much more frequently.

That’s really what this whole Lean UX idea is about. It’s about designers reaching out and saying, here’s what I’m working on, here’s the direction that I’m heading in, here’s some lightweight ideas.

I want to get your feedback and I want you to know what I’m thinking well before the pixels are dry on the page, if you will.

By maintaining this active conversation, by engaging the other members of the team, especially engineering, in the design phase, in the user research, in the stakeholder meetings they’re always aware of where the project is, what changes are being made, why those changes are being made.

Their dependency on UX as a maker of documents so that they can do their work diminishes greatly just by having that open air of conversation and collaboration.

Adam: If you’re going to be good at Lean UX are there new tools or skills that you need?

Jeff: I think the main skill that you need is the ability to collaborate and to have frequent conversations with your team.

And that potentially is a new skill in that there’s a certain comfort for a designer to be handed a particular problem and for them to go off and sit behind their monitor for a period of time, whether that’s a day or a week or a month, and then come out and say, “OK. I’ve solved it. Here it is.”

The different skill is to be proactive about the direction of the solution of the design that the UX person is creating and to do that much earlier in the process.

You have to get up, you have to get out, you have to circulate your ideas in what perhaps historically would have been seen as an unfinished form of the design and is now indicative of the type of direction that you’d actually like to head in.

By sharing those early and often you’re building that culture, that transparency, into the design process and with that transparency comes trust.

The one new skill, I would guess, beyond obviously all the other UX skills we already have, is proactive communication. If you’re not doing that today I would say that’s key to the success of Lean UX.

Adam: There were certainly some folks that were curious as to how things get done at TheLadders.com. One of the questions was who tends to build the prototypes there? Is it the UX team or is it the developers?

Jeff: It is almost exclusively the UX team. We use whatever tools we are either comfortable with, and that varies from person to person, or whatever is available to us in the time that we have to create those prototypes.

Occasionally we will test live code that’s in production with users and of course then it’s not necessarily a prototype, that’s actual production ready code.

But for the most part it’s the user experience team working either in markup, in HTML or CSS, in Fireworks in the past, we’ve even done some Flash prototypes, and we’re experimenting with some new and different tools these days.

Adam: There was a question that was in the seminar but I think we agreed it made sense to circle back on. The team at Piehead made the comment that it seems like a Lean iterative process works really well for small or new clients but maybe not so for larger clients like big, corporate systems. They were looking for your thoughts on that.

Jeff: So, I tend to disagree with that. I think the Lean UX approach can work on any size project in any environment.

One thing, though, there’s definitely a lot more upfront work that needs to get done in these larger legacy environments.

I actually wrote a blog post about this on my blog, which I’ve got at jeffgothelf.com, called “Lean UX Let Me Down”.

Which was, we took on a legacy project, perhaps overzealously, and didn’t dig into the existing systems and the architectures that were affecting the piece of the experience that we were there to fix.

As we peeled back the layers of that onion, the scope of the project grew and grew and the pitfalls and the different directions we had to go to fix things really came back to bite us.

So yes, I think it can definitely work in larger, more legacy projects but the goal would be to get a very clear sense of what’s affected by the piece of the project that you’re currently working on.

You really need to get a sense of the entire system, perhaps at a high level, and ensure that when you’re digging in with these rapid iterations there aren’t other pieces of the application that you’re breaking.

Adam: Jeff, one of the things I know you and your team do pretty religiously is that every week you’re talking to and watching your users with your product. Shaw wants to know what to do when you can’t get at your end users.

Jeff: That’s a great question. If you have no access to the end customer the best thing you can do is launch software quickly and iteratively.

Now obviously you need to be in an environment where that’s possible. If you can get software out into the marketplace quickly, or at least into a beta test, at least you have people using your ideas and you’re getting quantitative feedback on what you’ve put out there and how well it’s working.

At least you get a sense of what people are doing with it and if they’re actually succeeding at whatever it is that that particular experience was supposed to solve.

You need to do that regardless of whether you have access to your end customers or not but that provides the quantitative feedback and some insight.

Ultimately, if you don’t have specific access to a person if you can put surveys on the site itself or in the experience that allow the customers to actually reach back out to you via those mechanisms, anything you can put in that gives customers some sort of an opportunity to give you that some of that feedback.

But ultimately their usage would be really helpful.

Adam: I guess a related question, let’s get you to say more about that. Jerome wanted to know where you place user research in this process.

Jeff: We place it as often as possible. We found a system that works well for us where we test every week. For us it’s on Thursdays, it’s Thursday mornings, and we bring three users in every Thursday.

We run multiple teams so what happens is that testing that happens on Thursday is not unique to any particular team. There’s not one team that owns the testing that week.

That is usability testing for the week and if you have something to test regardless of what team you’re on you can bring your material to that test on Thursday.

Obviously, we do plan that a bit in advance and make sure the test plan is written out at least a day in advance and that there is a decent flow to the script that we have with the participants on Thursday, but that is a shared resource that happens every week and that anyone can hop on as necessary to validate their thinking.

Adam: How do you overcome already set expectations for wireframes?

Jeff: There’s two ways. It’s qualitative feedback, so every Thursday you’ve got people looking at the experience and they’re giving you feedback on something.

With a short video snippet or a usability report you can show that this is working or this is not working. We thought this was a good idea and this was not a good idea.

Qualitative feedback, in other words, usability testing, is one way, especially if you’re doing it often.

If you’ve got a regular track of communicating qualitative feedback to the organization. Even if you designed a wireframe on Monday if it bombs in the user test on Thursday you’ve got that feedback to get right back to it.

The other is quantitative insight and to say we’ve set these expectations, we’ve actually built this, and we’ve got people using the product and there’s data coming in saying that people are succeeding with this or people are not succeeding with this.

What we initially thought was a good idea is actually failing in the marketplace. We want to iterate on that. So it’s really customer validation is the key to continually improving and encouraging an evolving point of view on what the right experience should be.

Adam: Sarah’s looking for a little bit of insight on what Lean UX does to man hours. Does it actually decrease the number of hours you spend on a design when you’re using Lean UX or do you use the same number of hours just in a more collaborative or productive way?

Jeff: So it definitely does not decrease the amount of work or the amount of hours you’re spending. It just simply distributes the time more evenly over the course of a project’s life cycle, whether that’s in iteration or a design phase or however your process works within your organization.

It just distributes those hours in a different way. Whereas traditionally in a waterfall, gated process design was heavily, heavily concentrated upfront.

What you’re doing is you’re taking the heavy concentration and you’re distributing those hours across the entire project life cycle.

Adam: Ty asks a question and so I don’t butcher it I’m going to ask it exactly the way he wrote it. At scale, multiple teams of developers, product people, designers, et cetera, is there a greater risk of inconsistency in interaction patterns or brand application?

Is there a mechanism built in to protect this or is it a lesser consideration because this is really small? Again, that assumption that it’s for small teams or in start-ups.

Jeff: Yes. Great question. The short answer to the first half is yes, there’s absolutely a risk of inconsistencies and different patterns being applied and different approaches to solving the same problems manifesting themselves in the experience.

That is absolutely a risk, especially if you’re running multiple teams across a product suite like we do.

I’ve found two very effective ways to mitigate this particular problem. The first is having a centralized user experience team. What I mean by that is there is a UX team. Now, that team my be distributed out to individual Scrum teams if you’re an Agile environment or individual project teams if you’re in a Waterfall environment but there’s a home base for the UX team to come back together.

They have weekly meetings, they share knowledge, they share project work, and they show each other, they’re constantly talking to each other and sharing what they’re working on and how they’re solving the particular challenges that they’re facing.

That can happen on an ad hoc basis, it can happen on a very formal basis in a weekly UX team meeting where there’s work sharing and that kind of thing. That works really well as a knowledge sharing, kind of an informal solution to this.

A more formal solution is to codify a lot of these patterns in a style guide or pattern library or a component library where that is readily available to the entire organization so that if one team has solved how to do sign-up forms that is saved in a particular online environment.

It provides people with the ability to go and see how one team solved it and to take that UI and to take that code and to plug it into the pieces that make sense in their particular project.

That should evolve and grow as people change those solutions but that should always be the first place someone goes when they have to go build an experience or a product that uses existing components.

We’ve developed that at The Ladders and that’s worked very, very well for us as a centralized hub and a starting point from which to maintain a consistent user experience across our entire product suite.

Adam: Jeff, tell us more about the participants that you have in those weekly tests. How do you do the recruiting, where do you get them, where do you get these folks? Do they come from a pool of users or customers? Are you rotating through the same folks? Tell us about that.

Jeff: We work through a two-sided ecosystem. We have job seekers and we have recruiters. The first decision we need to make is who we’re bringing in this week and we typically make that decision on Mondays and we’ll decide if we’re bringing in job seekers or recruiters.

The next thing is we’ll ask what are we testing this week. If there are improvements to existing work flows we will likely dig into our existing user base.

So whether that is a set of recruiters or a set of job seekers, and we’ll make certain determinations based on the type of individual that we need to get in there to use the product that we’re currently designing.

For example, we could say we’d like to bring in folks from the Midwest who earn $50,000 to $75,000 and work in the tech sector, for example. That could be something we decide to do.

At that point we could say we need existing customers or new customers. Now, we won’t actually fly those folks into New York into our offices. We may do remote testing or we may just do phone calls with them.

Even in New York we’re grateful for the large population there and create those segments very, very quickly.

Then we decide whether or not we want to bring in external users or people who are already familiar with the product to see if we’ve made improvements.

That really depends on what we’re testing that particular week. We source those individuals, again, either from our member logs, we can create those queries and pull those usernames from our databases, or if we’re looking for external folks we’ll go to an external recruiter.

Our external recruiter, we can hand her a list of our names or we can ask her to provide non-Ladders members who fit this particular demographic profile or psychographic profile.

We use an external recruiter. She does all of the recruiting, the scheduling, the make-up, the finding folks when somebody bails on a particular session.

For us, given that our action designers do the usability testing at The Ladders, that takes a significant amount of work load off of their plate and we’re happy to have that external vendor provide us with that particular service.

Adam: Carolyn poses a problem that I suspect a lot of folks run into. She says they’re having a hard time integrating UX practices into their Agile approach and planning even with Lean UX in mind.

So she asks the question is there a way you found to be possible without having disconnected design sprints before a development sprint?

Jeff: Yes. Absolutely. That’s really the core of Lean UX is how to bring as close together dev and design into the same timeframe. That’s what we’re focusing on now.

The way that we’ve done it successfully is there’s an amount of upfront thinking, at the very least, that’s done by the product and design teams before we plan the next iteration.

There’s a little bit of heads up that says here are the things that we’re likely going to be working on in the next iteration. Let’s do at least a little bit of thinking around that. If there needs to be a little bit of illustration or visualization of that thinking, then it’s very, very lightweight.

It could be a sketch on a piece of paper, it could be a very rough wireframe. We’ve gone into iteration planning meetings where we’ve drawn on the whiteboard and said here’s how we’re thinking about solving this problem.

What that does is it engages the entire team in a low-fidelity way of articulating how they think the problem should be solved. Because it’s a sketch or it’s a whiteboard drawing it’s erasable. People can write over it. You can redraw it. You can redo it. That encourages that collaborative problem solving.

What happens at the end of that iteration planning when you’ve got everybody kind of tearing up wireframes or looking at sketches together is that everyone, when they leave that iteration planning meeting they understand what we’re building, why we’re building it, and what direction we’re heading in.

There’s an amount of shared understanding that you’ve built during that process that allows developers to then go and build that perhaps infrastructure layer so that you can continue to refine the design as a designer.

The other thing that’s critical as you plan your iterations in Agile is to have the UX person heavily involved in the prioritization of the back log. The back log is just the list of the stories or requirements that you’re going to build in a priority order.

The user experience designer has to be involved in the prioritization of that back log because they’re the person who knows how they’re going to design out or refine the designs they currently have as the iteration moves forward.

And so a developer may say, “I need this page, this tertiary page, in the experience design first.” And the UX designer can push back and say, “Well actually I can’t give you the tertiary page until I design the secondary and the primary page. Let’s figure out a way. Maybe there’s a task that doesn’t require any UI that you can work on first while I design the primary and secondary pages and then I can get to the tertiary pages.”

It’s critical for the user experience designer to be present and active in the prioritization of every iteration in an Agile environment.

Adam: That’s great, Jeff. Thank you for giving us more of your valuable time. I appreciate it.

Jeff: My pleasure. I hope that was helpful.

Adam: It was. To our audience, thank you so much for joining it and your support of the UIE virtual seminars. Goodbye for now.

The Agile development process is often accused of being too focused on delivery over the user experience. But that’s not to say that Agile is the bane of UX. Anders Ramsay believes it’s important to distinguish between Agile methods and Agile values. Many, such as fast prototyping and shared understanding are also valuable in the user experience world.

In general, the difference is a fundamental one. Agile development is very solution-focused and user experience practitioners are more interested in the problem. But it’s the commonality that is important and the realization that they are out to accomplish the same thing. Weaving UX into an Agile process and emphasizing the shared values leads to greater collaboration. Ultimately the goal is to arrive at better designs and better products, faster.

Of course, this isn’t an easy adjustment to make. Coming out of the heavy document and detailed wireframe world, Anders says that it’s more a matter of recognizing what aspects of the documents are waste and are things you could easily just have a conversation about. He admits that it can be a shocking transition to make:

“…this is people who have ridden a horse and buggy their entire life, and now I’m going to put you in a car. That’s just not going to happen overnight. It’s a new way of getting from point A to point B.”

In this podcast, Anders and Jared Spool discuss designing with Agile. Anders will also be sharing more of his insights in the first of our virtual seminar Next Step Series in collaboration with Rosenfeld Media. Don’t miss Designing with Agile on Tuesday, January 24.

As always we love to hear your thoughts. Share them with us in our comments section.

Recorded: January, 2012
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Jared Spool: Hello, everyone, and welcome to another episode of the SpoolCast. I am very happy and excited today, because I have a chance to talk with Anders Ramsay, who is delivering a virtual seminar, in conjunction with Rosenfeld Media. We’re doing a bunch of what we call the Next Step Series, and he’s doing our first one. It’s called “Designing with Agile: Fast, Effective UX Methods that Work.” And that’ll be on January 24th. You probably don’t know this, but Anders is also working on a book for Rosenfeld Media, called “Designing with Agile: Lean User Experience for Successful Products.”

Anders joins me from New York, I believe, yes?

Anders Ramsay: Yep, I’m in New York.

Jared: Excellent. Anders, how are you doing?

Anders: Good, good. How are you?

Jared: I’m doing very, very well. So, I’ve got some questions about your work with Agile. You’ve been in the business for quite a long time, right?

Anders: At least 15 years. I built my first commercial website in ’96.

Jared: OK, yeah, so just after the web had started to really take off. So, given that you’ve been around, Agile hasn’t been around, at least the values were all written up in about 2001, if I remember correctly.

Anders: Yes.

Jared: And so, when did you start working in Agile?

Anders: Well, I think I was practicing techniques probably already as early as 2004, 2005, but I wouldn’t have called them Agile because I hadn’t really become familiar with Agile at that time, and so I would say more explicitly adopting Agile methods more closer to 2008 or 2009, and since then having, obviously, been practicing that. But that’s one of the interesting things is that it’s a way of working that it’s not necessarily tied to that you have to follow, for example, these very explicit values. That’s one of the important things to understand about Agile, I think.

Jared: Yeah. I mean, what’s interesting about Agile is that there are all sorts of different layers to it. It feels to me sort of like an onion, in that you’re always seeming to peel things back, and at the core of it are these Agile values that really, I think, speak a lot to what people are trying to do and why this really is something more than just a fad or just a re-branding of something we already were doing.

Anders: Yeah. So what’s interesting and maybe confusing for people who aren’t aware of the history is that even though the “Agile Manifesto” you know, was formulated in 2001, that was something that was many, many years in the making. And it’s really sort of turned upside-down, because the methodologies that people are familiar with, they actually existed before that term “Agile” was coined. And, in turn, those methods originated from what was generally referred to as lightweight software-development methods.

So I see myself as being more of an adoptee of these earlier, original elements that became the basis for Agile. And Agile is more just like a brand, a term. It’s something that we can all refer to. We can just talk about Agile. We’re referring to this kind of way of thinking about design in general and software specifically.

Jared: Right, right. So what would you consider to be the project that would be the, accomplishment, you know, the UX/Agile accomplishment that you’d be most proud of?

Anders: There are probably several, but one that certainly comes to mind is a project I worked on, I guess a couple years ago, in which we had done a lot of maybe what we might think of as more traditional UI design work for this project. And it was a very complex enterprise project, very domain-specific. And there was really sort of a morality struggle in the project, in which the product owner and the team in general felt that, one, they felt overwhelmed by the user interface. Also, despite all our efforts to present these various wire-frames and other more traditional UX documents, they were just very concerned about, “How are we going to be able to get all these various features? I don’t really understand it. It’s not making sense to me.”

There was really a struggle, low morale with the team. And at that point, we were finally able to bring on software developers, front-end developers, onto the team, which we had been wanting to do all along, and so be able to shift then to more of an Agile approach, in which there was an intensive back-and-forth between myself and the developers, so that rather than, for example, me having a meeting with users and then coming back with some wire-frames and trying to communicate the design concepts and get their approval on that, we instead would incorporate a construction of the actual tool.

And so, what that resulted in was that we took this one concept that effectively involved the system sort of responding to the various window sizes of the tool. And this was a really critical part for these particular users because some of them needed to work on small screens, some of them needed to work on large screens. And we were able to have them actually interact with this feature. And suddenly all this hand-wringing that they had been experiencing about, “Oh, all this complexity! I don’t understand it. I don’t get it,” suddenly just melted away, and they just kind of grokked it, to use a nerdy term. It just made sense.

That was a truly powerful example of the idea of cross-functional pairing. So we’re taking pair programming and adopting or adapting that to, or extending it to, include UX. In some ways, unofficially at least, it saved the project. The morale just was boosted, and suddenly people really believed in the product and believed that this was going to be a success.

Jared: Say a little more about this pairing-up thing. How does that work in a UX frame? Because I understand how it works in programming, right? Basically, you have two programmers sitting next to each other, and they’re actually coding together, and having the two brains sort of focused on the same activity, they spot errors and defects and they come up with ideas faster. Right? That’s the idea behind it when it’s programming, but what is it when you’re talking about it from a UX perspective?

Anders: So the difference there is that we’re doing the same thing but we’re doing it across disciplines. So, in this particular case, the way that it worked is we would both start at a white board and white-board a little bit together. And then the critical part there was that the developer was very actively engaged, and he would say, “OK, I feel now that we can add more value and evolve the design more effectively by moving to starting to build.” That was a critical part.

So we made a critical shift there, when we moved to the white board and moved from sketching to sitting next to and sitting in front of the computer. And then he would start doing some construction, and then I would just kind of continue to sketch, sitting next to him, because he may need a little time to build up certain pieces, but have some quick questions, like, “Did you mean this? Did you mean that?”

And so, the debugging that’s happening there is not so much in terms of code quality but in terms of experience quality. And one of the reasons that this works, this particular instantiation of cross-functional pairing that we were doing is something called “designing in the browser,” if people want to Google that. The reason that you can do it is because, in a modern kind of software front-end development world, where we have so many patterns and things like jQuery, a lot of highly abstracted tools–jQuery, obviously Python, Ruby and so forth, and Rails–they’re able to work at a very high speed. So we’re able to actually sit next to each other and actually build, almost like building blocks.

So it’s very powerful. And it certainly does not replace pair programming; pair programming has its own place. But it’s something that is great to do for highly detailed design work, particularly when the team already has established somewhat of an interface language, so that I, for example, can say, “Yeah, let’s use that list table, and let’s use that compact dashboard and so forth.” And you’re able to work very intensively back-and-forth and really do atomic-level design work, right directly in the browser, or in your mobile device, as the case may be.

Jared: So you’re taking advantage, if I’m understanding right. You’re taking advantage of the code components that already exist and the elements that are already there. Plus you’re using these languages, like jQuery and, potentially, Ruby or things like that, that let you get things done very fast. And as a result, that means that, sitting next to the developer, you can see the interactions and those little, subtle nuances that can’t easily be explained, like, “No, wait. When you click on that, it has to fade in a little slower. Otherwise someone may miss that it’s appeared.” Right? That type of thing. You’re able to sort of work through that and say, “No, that’s too fast,” “No, that’s too slow,” “OK, that’s just right.”

You can have that conversation. And because you’re having it with the developer at that moment, it sounds to me like that gives it an advantage. Tell me if I’m wrong here, but that gives an advantage. Later on, when you’re not sitting next to the developer, that developer understands your intent and can make decisions, saying, “Oh, I bet you what Anders was talking about was this,” and can make a decision, is more likely to make a decision that matches what your intent is when you’re apart because you had that time together.

Anders: Exactly. And so, things you want to do, then, is do what in some circles is called “pair stairs,” where you want to make sure that, as a UX designer, you kind of tour the entire team or tour all the developers and actively make sure that you are actually going to be pairing, not just with this one developer, but you want to make sure you’re pairing with everybody. What happens then, which is the same with pair programming, is you’re distributing knowledge. You get knowledge distribution across the team, and eventually I don’t even necessarily need to be as much a part of the picture. Like you said, they pick up the language on their own.

But I wanted to pick up on something else you said, which was the whole reason that we’re able to do this is because of a higher velocity, of being able to kind of build faster tools. What’s interesting is that’s really the origin of Agile in general.

One of the reasons why Agile has become so powerful is because we are able to deliver working software at a higher velocity. There was a time when you could make a case for big specifications because coding was slow, time-consuming, and expensive, and that no longer is justifiable. So it is, the whole reason we can even talk about doing two week sprints or one week sprints or hour-long sprints, if you’re doing a hackathon or something, you can be turning things around in very short cycles of time, is because developers are basically able to speak in a more succinct and eloquent way with machines, use more words that have more richer meaning. Back in the early days of the [indecipherable 11:11] , it was like you’re in third grade or first grade and you have only a few words that you know. Now, we speak this very rich language. So that has then cascaded into we’re now wanting to adopt the UX practice to that new world.

Jared: This must have been really different from the ways you were working when you were doing Agile. I mean you said you started in ’95, ’96 and you had that block of time in there where stuff wasn’t Agile. This pair programming and using these components, were those the big differences or were there other big differences that sort of stand out in your mind?

Anders: The fundamental difference is really just looking at and thinking about what is valuable and effective. So in those days, to me, well let’s be clear. In the very early days, everything was just chaos and ad hoc. There was no process. So, around ’98, ’99, we started to develop and formalize specification documents and so forth. At that point, the holy grail of UX design or information architecture or whatever term was used at that time was the perfect specification document, the perfect wireframe, the document that would just absolutely crisply communicate what needed to be built, and then you know, you could hand it to somebody and they would build it.

The problem was always with the document and if it wasn’t working, then we need to make the document better, and they need to be clearer and need to add more detail and so forth. So there’s been a fundamental shift there where, rather than a document-centered model, now it’s a conversation- and human-centered model. It’s a fundamental paradigm shift.

Jared: And so by having this human-centered model that you’re focusing on, I mean this is where a lot of folks get freaked out, right? If we don’t document the overall design, how will we make sure that it all fits together?

Anders: Right. Yeah, this gets to the core of what somebody who’s coming from a very document-centered world – somebody who’s really been indoctrinated into the design document as the culmination of one’s work, of one’s practice – it can be scary to think of a world in which you’re really centering your communication around conversation, direct interaction. For me and as for most people who adopt this, it’s something that is gradual. It’s not as if one day you’re doing heavy, big specifications and, the next day, flip the switch, and now we’re just going to talk and use barely sufficient artifacts. It’s something that is progressive.

So, early on, somebody who’s adopting an Agile approach, they’re probably going to continue to create fairly detailed wireframes. Over time, they’ll discover, they’ll think of it more and more as waste. They’ll think of it as, “Why am I adding all this detail? Because we could just have this conversation.” So it’s more that you have an increasing understanding of what elements in the documents that you create are waste. That is something that is, as your practice matures, your ability to perceive what is waste in the documents or whatever artifacts you’re producing increases. It becomes more acute.

Additionally, it’s not the simplest thing. It’s not a cut and dry thing as far as either it’s waste or it’s not waste. It’s highly contextual. It’s specific to each team, each project, and who you’re working with. So, for one project, it may make sense for me to maybe crank out a very detailed wireframe which has all kinds of annotations or whatever in a certain point for a certain project. Then, on the next project, it doesn’t make any sense at all. There’s much more value in me just scribbling a few lines on a whiteboard and then talking to those scribbles with a developer. It’s highly contextual. But it’s also certainly not something that happens overnight. We’re talking about basically this is people who have ridden a horse and buggy their entire life, and now I’m going to put you in a car. That’s just not going to happen overnight. It’s a new way of getting from point A to point B.

Jared: I think that a lot of people feel, though, they’re sort of thrust into this world where they have to not only go from the horse and buggy into the car, but they go from the horse and buggy to driving in NASCAR. [laughs] That that’s what’s expected of them. That’s a hard transition I would think.

Anders: It is. So part of what I’m trying to achieve with the webinar, with the book, and all the workshops and everything is to provide UX designers with a combination of thinking tools, basically a mental model to understand Agile, how to think of it, to see it, to give them a clear mental model of it. Then, a readymade set of tools that they can use as a starting point to be able to function in this very different world. Then hopefully as they understand Agile thinking under Agile values, they can customize and create their own tools and shape them to their particular situation. Certainly it is challenging, but that’s one of the reasons why I feel it’s important to be doing what I’m doing.

Jared: It seems to me that getting your head around those Agile values really helps a lot, because when I first saw them, I looked at them and I said, “You know, that’s sort of what we were doing all along.” This idea of individuals and interactions over processes and tools. That to me feels like focusing on the users, focusing on the way that we talk about our users, everything from having good personas so that we can talk about users and what they do in a realistic format to working along with the developers directly and having them see usability tests, all that stuff. That’s one of the core values is this individuals and interactions over processes and tools, right?

Anders: Yes. So one of the things there that’s important to understand is that those values are the equivalent of you reading a description of Rome in a guidebook versus going to Rome. [laughs] So it is an attempt to convey the most key attributes but, at the end of the day, it’s just something you have to do it to really understand it. Once you’ve done it, suddenly these statements take on a whole new meaning.

At the same time, I feel as if they are very, very high-level and it’s almost an understatement to call them the tip of the iceberg. I mean it’s just the very, very ultra-distilled representation of what we mean by Agile and there is such a universe of this entire culture, you know? So here I go, I read this one paragraph blurb about Italy and visiting Rome and Italian culture. And what have I understood if I’ve never been to Italy? Well, not a whole lot. But if I go Italy and I spend time there and then I come back and I reread that same blurb, it’s going to have a whole other much richer meaning, as with anything else. This isn’t anything particular to Agile. With anything else, it’s helpful but you have to do it.

That is why I try to take a very active, kind of workshop-oriented approach when I can when I talk about this stuff, to actually get people engaged and in some fashion experience what Agile means, or provide instructions, to say, “Now that we did this, here, go out and try and do this activity, activity X, activity Y.” So it is in some ways its own culture, its own set of values and norms, and that has both a good side and a bad side. There’s a dogma that is called a sort of negative side of Agile. It’s a curiosity in my opinion because the idea of dogma in itself is antithetical to Agile values, but it’s there. You have to just be accepting of that reality and then work through it.

Jared: I was talking to somebody just yesterday about that dogma. What occurred to us was that it seems that when you’re new to something… Of course, a lot of UX people who are new to Agile are actually working with entire teams that are new to Agile, so everybody is new. When you’re new to something, you almost require that dogma to be there in order to be successful because you’re sort of taking it on faith that the way you’ve been doing things needs improvement. That dogma is really important to having that faith-based approach to things until you’ve had enough time to know that you can break the rules and which rules are really effective and which ones aren’t. You need to have solid rules and be really dogmatic about those rules in that period. That’s sort of getting used to something.

Anders: So one of the problems is that the rules that have been devised by methods such as Scrum and XP are intended to achieve a different set of goals and a different set of objectives in contrast to what a UX designer does. A case in point is a user story is one that is solution-focused. Basically, it’s one where it’s been designed to find the most effective route to get the customer or the client or whoever it is to tell the developer what to build. Tell me what to build.

Jared: You know, as a doctor, I need to find my patient’s X-ray.

Anders: Yeah, so that’s design. You’re asking them to do the design. Now in UX, a core aspect of UX is that, in many cases, what we do as UX designers is we effectively give the customer what they do not know how to ask for, right? So in that regard, what we want to understand is not what the solution is. We want to understand what the problem is. The developers are not really interested in that. Just tell them what to build.

Jared: The problem for that particular story might be more complicated. Like, as a doctor, I want to discover that there have been tests that just came back that I didn’t realize were ordered because they were ordered by another doctor in the ward. And therefore, I want to take that information into account when I’m doing my rounds and diagnoses.

Anders: Yep. What’s interesting is for any one problem there’s, of course, any number of possible solutions. That is where the UX expertise comes in. It’s in helping shape and determine which the best solution for the particular context is and so forth.

And that is not something that Agile methods… And I want to be really clear about distinguishing between Agile methods and Agile values. Agile methods, such as XP, extreme programming, Scrum, other methods, are focused on delivery from the perspective of a developer. I’m being very simplistic. I’m being very generalizing. But from a very generalizing, simplistic perspective, those methods are delivery-focused. This is about shipping, shipping early and often. Once it’s out the door, I’m onto my next feature. I’m building my next feature.

But, from my UX perspective, at that point, sometimes that’s where the real game begins. Now we’ve got to validate this thing. We’ve got to make sure was it really as good as we thought it was going to be and so forth. Then, of course, there is the question of what are we going to ship, what are we going to build, what is the product going to be, and that requires sometimes a much more holistic perspective than this more incremental model that many Agile methods tend to lean toward.

Again, I am generalizing in some regards, but that has been my experience, that the well-established Agile methods are focused more on being told what to build and then finding the most effective way to deliver that. That’s a very good and important thing, but it does not in itself make a whole practice.

Jared: That’s a really important fact that I think gets glossed over a lot. One of the realizations that I had very recently – I hadn’t considered this – was that a lot of the stuff that we see for Agile, the practices that have evolved, they all have a heritage that comes out of internal system development where the customer is somebody who often works down the hall and eats in the same cafeteria. So the teams when they say, “OK, we’re going to have a customer on the team,” they don’t really have a customer on the team. They have someone who is pretending to think about the needs of the customer but who may not have any more information than anyone else on the team has.

Anders: Yeah, I mean, some interesting things that may be sort of shocking to a user experience designer is actually that Agile in its original methods are actually not user-centered. They’re client-centered.

They’re all originating from an enterprise world, and they’re originating in the early enterprise universe in which it wasn’t so much about, “Oh, is that button right or does it feel right?” It’s like, “Does it work?” Allow me to click on the button and build it so that the thing that I need to get done when I click on the button happens happens, and that’s it. So that is why, in the early days of software development…and I mean early. In the day when… I guess this would be in the 90s, mid-90s, 80s. Obviously software development goes further back than that, but as far as when we were just getting into GUIs, graphical user interfaces, at that time, particularly in an enterprise context… I don’t want to talk about Apple and all these things that were happening at the same time where we were getting much more into formalizing human factors and so forth.

In the context of an enterprise, the user interface design, that was just another task that the developer would undertake. So they would select a drop-down or a radio button, whatever the case may be, and what most pragmatically and effectively would achieve the feature that the customer had asked for. And so that has then continued on within Agile methods and, in a pure XP model, the user interface is just another task that is part of delivering the story. Now, of course, there’s an awareness, obviously, with the evolution of more advanced user interfaces and so forth that that is not sufficient, but that has been part of the growing pains of Agile and part of the changes that have been necessitated by that and part of what the Agile UX movement is all about.

Because we’ve gone from a world in which, if Agile were a restaurant, it’s gone from being this institutional cafeteria where basically whatever you get is what you get to a food court where if I want to get a to-do app on my iPhone, I have at least 50, more than 50. So which one do you think people are going to pick? Well, they’re going to pick the one with the highest, best experience quality, because they all pretty much have the same features. So it’s this new world where experience quality is a fundamental factor determining success, and that was just not really part of the equation when Agile, you know, originated.

Jared: To me, it seems like UX folks who are new in this environment, they can benefit a lot by sort of understanding this history of it and being able to talk the language of Agile and say, “Look, what I want to do is exactly what you want to do. I want to get us closer to those users so that the things you’re building are the right things and really are valuable to the people who we’re trying to design for, and I want to do it as quickly as you can.” And so having techniques and methods that aren’t so documentation-focused but are really, like you said, pair programming, sitting down with people, talking about them, getting everybody on a common ground, and having tools like fast prototyping, things like that, all of that becomes really essential to making this work.

Anders: Yeah and for me, one of the core attributes of an Agile UX practice is the idea of active collaboration. So we’re replacing this intensive rapid kind of “passing game”. I like to use rugby as a mental model for an Agile approach, and we’re rapidly passing the ball back and forth between team members. We do that, for example, through various workshop-oriented activities or pairing or other types of activities. And by doing this intensive collaboration, we reduce the need for writing things down, and that’s actually a very good thing because what’s interesting is, as software development philosophy has increased, traditional documents simply are unable to cope with that type of velocity. They were not designed for that pace of change.

I mean for a while, wikis, trying to use wiki pages and so forth, and that certainly had its place, that allows for somewhat of an increased velocity of change, but even that is in some case falling to the wayside. Ultimately, one of the few communication methods that can keep up, can cope with the everyday chaos of a software project, is direct conversation and human interaction. That’s something that’s implicit in the value statement. When it says, “We value direct interaction,” it’s really saying it’s more than we value it. We must have it in order to survive and be successful. So there’s an element of urgency that is not explicit in the Agile manifesto but, for anybody who has kind of lived and breathed an Agile project, it’s there.

Jared: Cool. Well, you’re going to be talking about how to do this in our January 24th virtual seminar called “Designing with Agile”. I’m looking forward to that. That’s going to be a lot of fun.

Anders: Yeah, I’m looking forward to it as well.

Jared: And I’m also looking forward to seeing the book, “Designing with Agile: Lean User Experience for Successful Products”, which is going to come out from the wonderful publishers over at Rosenfeld Media. And so I’m sure that’s making its way through the gristmill.

Anders: Yep.

Jared: Fabulous. Well, Anders, thank you for spending time with us today.

Anders: It’s been my pleasure. It’s been great.

Jared: I want to encourage everyone who’s listening to check out the books and to join us for the virtual seminar on the 24th. You can find all that out at uie.com, and thank you very much for taking the time to listen to us today, and, as always, thank you for encouraging our behavior. We’ll see you on the SpoolCast later. Take care.

Story mapping is a way to build a model of user experiences. More than that, in the Agile context, it allows you to tactically plan for what should go into each release. It is a way to get everyone on the team thinking and talking about user experience. Getting people into a discussion mode starts to create a very collaborative environment.

Jeff Patton is a consultant and expert in Agile development. In his sold out virtual seminar, Story Mapping for UX Practitioners: Tying Agile and UX Together, Jeff outlined how to create a story map and how it fits into the Agile process. Jeff ran short of time to answer all the questions during the seminar, so Adam Churchill caught up with him to answer those remaining for this podcast.

Here’s an excerpt from the podcast.

“…A lot of the answers to selling [story mapping] is, to not, just get started. If people can see and physically engage with something big and something they can touch, [the answer is] to get it up there and get them to engage in it.

I’ve seen a lot of folks spend a lot of time trying to introduce the concept to people, trying to convince people it’s a good idea for them to do it. If you’re a user experience person, build one of these maps on the wall, physically in your area, and if you’ve got someone to collaborate, lead them over to it and say, “This is what I’m seeing happen. The person using our product is doing this, this, and this. And here’s where the real pains are.”

And when I’m working with people on these things, I really watch closely for their body language. I watch for people to start to point and start to use words like “here” and “there” and “down here” and start to engage with it. I’ve found that these things end up selling themselves. Trying to sell it doesn’t work.

There are a lot of products that are hard to sell. And I think I’ve heard from people talking about TiVo this way. TiVo has a hard time telling people what their product does and why you like it, but you use it and you know why you like it. And it does better being sold via word of mouth, or maybe you just have to experience it…”

Tune in to the podcast to hear Jeff address these points:

• Who do you have build the story map?
• How do you get the right people in the room?
• How do you story map when you’re designing with multiple personas in mind?
• How many users should you interview prior to building the story map?
• How do you ensure non-functional requirements don’t fall through the cracks?
• How do you scale this process to different-sized projects?

Do you incorporate UX into and Agile environment? Share your thoughts with us in our comments section.

Recorded: September, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: Hello, everyone. Welcome to another episode of the SpoolCast. Jeff Patton recently joined us for a Virtual Seminar titled “Story Mapping for UX Practitioners: Tying Agile and UX Together.” Now, the seminar sold out, and the activity we were watching in both the Adobe Connect room as well as the Twitter stream was a lot of fun to watch. Lots of good comments, lots of good questions.

Jeff’s seminar spoke directly to folks working in an Agile environment who struggle with knitting user-experience design practices together with the iterative process they work in.

Jeff’s graciously offered to come back and tackle some of the questions we didn’t get to address in the seminar. If you didn’t listen to this particular seminar, you can get access to the recording in UIE’s growing User Experience Training Library, which presently has over 70 recorded seminars from wonderful topic experts just like Jeff Patton.

Hello, Jeff. Welcome back.

Jeff Patton: Hello. How are you doing today?

Adam: I’m doing very well. We had a lot of fun yesterday, didn’t we?

Jeff: We did have a lot of fun. We packed a lot into a short amount of time.

Adam: Well, let’s get right to it. For those who weren’t able to join us yesterday, can you give them an overview of what we did talk about?

Jeff: Yeah. My goal was to introduce people to a practice, something that I’ve been doing for a lot of years and something that’s growing in popularity. A lot of people are doing this. We focused on story mapping. And for a UX person, I’ll tell them story mapping is a way to build a map of user experience, something like task analysis.

I’ve seen lots of flavors of task analysis that yield sort of a map that looks like a story map. But if you’re working in an Agile context, you’ve got to build a backlog and come up with a bit of a tactical plan for what we’re going to put into a release and how we break it down into bits and pieces to build.

So we talked about that idea of a story map and how it sort of plugs that hole. And the big benefits, for me, are we’re able to tactically plan and execute like we need to do in an Agile context, and we’re able to get everybody thinking about user experience. So, for me, this is why it’s a bit of a bridge-gapping practice.

So during that talk, we talked, basically, about what an experience map was and how to quickly create those. And then we went into a lot of depth about what user stories are and what they aren’t. And one of the biggest misconceptions, or one of the questions I hear constantly, is “How do I write good stories?” One of the points to make about stories is they’re called stories because they were meant to be heard. They were meant to be discussed and talked about, and how they’re written isn’t as big an issue as what people talk about and what pictures they form in their heads.

Definitely, we have to write things down, but the form that we write them is really contextual. Then, when we combine these ideas, of the idea of a story or the things that we talk about and the idea of something like an experience map that lets us see the big picture, that’s where we get the story map.

After introducing that idea, we talked about the basics of how you build a map. Start by getting the big picture, what I would call the backbone of the map, down, and some of the details, then how we pile in lots of details. And then, where we ended up with was talking about how we use that simple square structure of a story map to carve out or slice up a product into incremental product releases.

This is where I think the shape of the map shines. It arranges information left-to-right based upon users’ experience and decomposes it top-to-bottom into parts. And when I slice it left-to-right, I start planning or thinking about releases in holistic product slices. And I get better releases. I get both thinner releases, releases that have less in them, and more comprehensive releases, releases that really satisfy users’ needs.

That’s where we ended up. There was a last tail-end section that I came into the seminar hoping that I could fold time or do a lot more than we did. And the section we didn’t get talked about tactically working with story maps, and tactically working with stories for that matter, during Agile-style iterative and incremental development.

Adam: Well, let’s get to some of those questions that we didn’t get to answer yesterday. There was a question about, how do you sell to the group, and how do you get started with that group?

Jeff: A lot of the answers to selling it is to not, to just get started. If people can see and physically engage with something big and something they can touch, it’s to get it up there and get them to engage in it.

I’ve seen a lot of folks spend a lot of time trying to introduce the concept to people, trying to convince people it’s a good idea for them to do it. If you’re a user-experience person, build one of these maps on the wall, physically in your area, and if you’ve got someone you’ve got to collaborate, lead them over to it and say, “This is what I’m seeing happen. The person using our product is doing this, this and this, and here’s where the real pains are.”

And when I’m working with people on these things, I really watch closely for their body language. I watch for people to start to point and start to use words like “here” and “there” and “down here” and start to engage with it. I’ve found that these things end up selling themselves, and trying to sell it doesn’t work.

There are a lot of products that are hard to sell. And I think I’ve heard from people talking about TiVo this way. TiVo has a hard time telling people what their product does and why you like it, but you use it and you know why you like it. And it does better being sold via word of mouth, or maybe you just have to experience it. Does that make sense?

Adam: It does. It does. And yeah, there’s a list of products like that. Twitter would be, I guess, another good example. You don’t really understand what it is until you use it.

Jeff: Yeah. Yes. Something like that.

One of the key points out of yesterday’s discussion was, and several people pinged me afterwards, and I’d asked them, “What were your takeaways from this?” And I strongly made the points that it’s not what’s written on paper that matters; it’s what’s in people’s heads that matters. We’re working really hard to collaborate together and form shared understanding in people’s heads, and that’s a value that people don’t focus on much, and it’s a real benefit we get out of these big, simple models on the wall.

Adam: So, Jeff, who do you have to have in the room to build the story map? Do you involve clients, the development team, the user-experience designers? Who’s in the room?

Jeff: What’s interesting about a story map is–well, I’ll go back. I’m lazy. I don’t want to build multiple things. A story map, initially, for me, is about thinking through and understanding user experience. Subsequently, it’s about explaining user experience to other people. And then when we start breaking things down and planning, it starts to be, well, about that, about planning and about tactically figuring out how we’re going to get this product built. And there’s different audiences for each one of those activities, as you can imagine.

When initially using the story map to kind of understand what I’m doing, maybe this is a habit I picked up from working in an Agile context. I like to pair, and I’ve seen a lot of designers that focus on pairing. And there’s an old Yogi Berra quote: “Pair up in threes.” So I like these small groups of two, three, sometimes four, to think through and build things. It’s a single-pizza-sized group. These are the people you want to pull together, that have some understanding, to initially build the map.

Once you’ve got a map initially built or initially structured, then I want to start to pull in other people with different kinds of experience, different sorts of subject-matter experts, and I want to vet my understanding with them, and I want to add to it and change it and richen it up. If, by building the map, I see I’ve got holes, and I’ve got to go out and do more research or learn more, then I might do that and come back and fatten up the map that way.

Then, once I’ve got a little bit of a map that starts to explain a product, oftentimes we’ve got to share that with other stakeholders or share the vision of what we’re getting with this product with other people. So we’ll bring people in. And the purpose is not to add to the map or validate it so much as use the map to explain, “This is how we see people using this new product, and this is the flow of that use, and this is how it breaks down into pieces.

Then, downstream, when we have to start taking this apart and planning it, that’s when we want to pull more engineers and more QA people, other people that know, tactically, what it’s going to take to get this thing built, into the room.

So it’s not if all those other people should be involved. It’s more of a when they should be involved.

Adam: Any tricks to helping you understand if you’ve got the right people in the room?

Jeff: Adam, looking back, there was a question. And I’m going to repeat somebody’s question. What if a key stakeholder, a product manager, checks out of the process and starts thinking, “That’s not my job. It’s engineering’s job”? And the reason I’m bringing them up is, how to tell you’ve got the right people in the room, sometimes they sort of vote with their focus, and if they’re losing focus, they may very well be the wrong people.

Now, getting the right people in the room. One of the things I’ll focus on is a team, I leverage a mantra and often draw a Venn diagram that looks at these three concerns: valuable, usable, and feasible. Valuable to the organization building the product, usable to the people that end up using it, and feasible to build.

Now, strictly speaking, if it were just building a map of user experience, I could just focus on people who understand users and how they work with things, and the right people to initially build the map could be just user-experience people. Some organizations just have business analysts that take care of that capability.

But I want people in the room that are also thinking with their business hats on and really gaining some empathy and understanding for users. And while they may not be contributing to the map, I want them in the room.

Then there’s a dysfunction I commonly see and everybody commonly sees. A business comes up with a great idea. User experience works out the details of how users need to work with it. And then we produce all those details for engineering and engineering says, “That’s going to take a long time to build.” And then we go back to the drawing board because it far exceeds the budget that we’ve got.

Having engineering in the room earlier on gives us early warning for that, and oftentimes gives us perfectly reasonable ways we could do things that would be cheaper, more cost-effective to build and still satisfies users and still reaches the business needs.

The right people in the room for me is a balanced team that includes someone who understands some engineering concerns, someone who understands business concerns, and initially, when we’re building out the experience, people that deeply understand users’ experience today and then the experience we’re striving for with the new product.

Adam: Edwin wanted to know how you do the story mapping when you’re designing with multiple personas in mind.

Jeff: That’s a great question, and I’m glad you asked it. I’ll answer another question first, or point out another concern first, and then answer it a little bit more squarely.

There’s a standard user story template that’s used by a lot of people in Agile development. It’s the, as a kind of user, I want to have something do something so that I get some benefit. And that template, in the “as a,” it seems to call for one answer there. And for me, I’m always looking at the product from the perspective of multiple personas or different kinds of people that would use the same functionality and have different concerns when they’re doing so.

Edwin’s question was, how do you story-map when you’re designing with multiple persona’s in mind? The story map is about the product and it’s about the experience. Gosh, it’s a little bit about both. You need one map because you’re going to build one product.

Initially, to get the shape of the map in place, I’ll think through it from the perspective of one persona and get the backbone and the basic shape of the map going, and the basic shape of the map starts to reveal the shape of the product. And then I’ll grab other personas with different concerns and walk through it from their perspective and see if it breaks it, changes it, does other things.

And to remind people that this product is for multiple personas, at the top of a story map, we’ve got big activities that break down into users’ tasks, and those break down into the tactical details of what we might build. Right above those activities or above sections of the map, I’ll post those multiple personas or hang them there, so that people can see, clearly, these big activities in this map serve these different personas, and they have different concerns.

Let me give one more detail here. Some folks that are building an application where multiple personas use the same functionality will go through and tag all the stories. They’ll tag their personas each with different-color dots, let’s say, and then go through and tag all the functionality that’s particularly relevant to one persona with that color dot.

This does a little bit of an analysis so that we can see that for these personas, they’re really concerned about this functionality; these personas are concerned with this other functionality. And we can see a bit of overlap that way, too.

Adam: So when you’re doing that research, how many users do you need to interview to know that you’ve got what you need to build the story map?

Jeff: Research is a troublesome thing for me. I’ll be honest with you. I came to doing what might be more rigorous user-experience work in about 2001. Before that, I was just spending a lot of time with users and building stuff, and I didn’t know that I was doing research. I would spend a lot of times with users using the software. Maybe I didn’t know that was contextual inquiry. So it wasn’t so rigorous. It was after 2001, when I dug in deep, that I started realizing, to be rigorous, I probably should be doing a few other things.

Now, if I fast-forward, I often find that organizations don’t do any research, because to do it rigorously takes a lot of time. So they go back to doing what they were always going to do, and they follow what I heard Jared call the MSU process, or “making stuff up,” only Jared didn’t use the word “stuff.”

Adam: [laughs]

Jeff: So, how many users. In working with some folks, for every distinct audience segment or role, I’ve heard general guidelines of three to 10 people. And it depends on how much variation there are in those roles, so if I were covering half a dozen roles, I might be interviewing lots of people.

However, one of the strategies I leverage when initially building personas and initially building story maps is to leverage tacit knowledge that’s in the room. Pruitt and Adlin talk about building assumption-based personas, and I build assumption-based story maps and assumption-based personas. By initially building a story map, we make clear what we do and don’t know, and then we can look back at this and say, “Gosh, where is our information hazy?”

Then let’s design a research plan that helps us not just learn about people. Since we’re modeling work or activity with a story map, my research plan can be very focused on the specific activities where I don’t know anything. And more importantly, if we’ve got businesspeople in the room, we’re looking for this intersection between stuff I don’t know and stuff that matters a lot, and that’s where we’re going to focus. [laughs]

Adam: Jeff, just a couple questions on nonfunctional requirements. And Ariadna asks, “If story mapping mostly concerns itself with functional requirements, how do you ensure that some nonfunctional requirements don’t fall between the cracks?”

Jeff: That’s a great question, and that’s a great question that’s applicable in any software-development process or any scheme to try and get your head around what requirements are for what to build.

So I don’t know if I have any fabulous answers. And one of the shortcomings sometimes with user stories in general is, I mentioned the initial idea of user stories, where you write down something and have a discussion, and out of that discussion comes the details of specifically what to build, and over time, the goal is to get smaller and smaller stories so that we could build smaller and smaller things.

When you look at nonfunctional requirements, the things that automatically pop to mind for me are things like scalability and performance and usability and all those things that people call “ilities.” Security, which doesn’t end in “ility,” that’s one of those also. These are big, cross-cutting concerns. I don’t just implement the scalability story and call it done. They’re quality characteristics of the product, just as usability is.

You don’t measure usability on a single check-box. It’s not necessarily sensible to if we’re concerned about usability of someone accomplishing a whole task.

So, let’s track back. Those sorts of nonfunctional requirements, yeah, we don’t want to lose them, but they’re cross-cutting. They’re big. I find that the story map helps me a lot because they’re often activity-centric, and the story map reveals what those are. So I might have particular scalability and usability and performance concerns in one particular activity and a lot lower scalability-usability-performance concerns in another. One of the things I’ve done personally is go up to that activity level and document or record stuff at that level.

As Ariana asks, how do you keep them from falling through the cracks, or falling through the story so to speak, oddly, it’s not easy to make them stories. They become concerns that we constantly pay attention to during development. We constantly do things to measure usability, maybe by testing, measure scalability by testing, except different kinds of testing.

Then, as we encounter problems, that’s when we get these more emergent, tactical stories that we inject to fix things or make things better. I document the concerns up at the activity level, and I would pay close attention to them during development and inject stories to correct problems as I find them.

Adam: One of our attendees acknowledges that he understands how you break stories into smaller chunks and chunks that you can develop in shorter time frames, but how do you do the same with those usability tasks that encompass full systems, like ease of use?

Jeff: [laughs] I’m looking at Eduardo’s question, and he also has a cool term after that. He says “confusability,” which is a term I’m going to use from here on out. [laughs]

Usability is a nonfunctional requirement. It’s a nonfunctional requirement sometimes. Some people are more focused on the technical nonfunctional requirements, but things like usability is a strong one. And just like other nonfunctional requirements, they’re big. Like Eduardo points out, they’re not localized to a little story.

We have to look at them as a cross-cutting concern. And it’s during this iterative and incremental development, we have to keep asking, “Is this activity usable?” And we add more stuff to it: “Is it still usable?” And we add more stuff to the software: “Is it still usable?” We keep checking that stuff over and over again.

And exactly how and where that goes in Agile software development, and exactly what story card it gets written on, well, there’s no set answer for that, and there’s no one story card it goes on, and it’s not so simple. I find that you’ve just got to keep your head engaged [laughs] while you’re doing this stuff. And again, back to the previous question we talked about, I like documenting those concerns at the activity level, and I like testing for those concerns at the activity level.

Adam: One last question, Jeff, and I know that you and I talked about this one as we were kind of mapping out this podcast. And it’s a bit broad, possibly vague and tough to answer out of context, but I’m going to ask you to give it a shot because I think it’s important for our audience. This technique of story mapping, how do you scale it to different-sized projects?

Jeff: [laughs] When we were talking ahead of time, I winced a little bit, because I get asked this question all the time. I find that different people who ask “How do you scale?” mean very different things.

So when we look at scale with respect to different-sized projects, I hear some people mean we have a lot of people working on this project. In some contexts a lot of people means 20, and in some contexts a lot of people means 200. I know some organizations where they put 20 people on the project, but those 20 people are spread across five different countries.

Scale, for them, isn’t big in terms of number of bodies; it’s big in terms of number of time zones. I hear people talk about scale in terms of how big the product is: “This is something that’s going to take a year-plus to build, and it’s going to take dozens or over 100 developers to build it.” Scale means a lot of different things to different people, and it has to do with size of teams, size of product, geographic distribution, lots of other things.

So, given all that, given the question, my first question is usually to ask people back, what do they mean by scale? What I tend to find, though, is, for big products, for instance, it becomes difficult to build a story map for the entire product. That’s tough.

I’ll find I’ll end up building a lot of local story maps. We’ll break a big product down into separate problems and then map that problem and look at a single experience or a single activity. And I might create a big map for the entire product, but create it at a higher abstraction level. And it becomes more informational. It becomes not tactical. I don’t use it to find the detailed stories to push down to individual teams. Rather, I use it as some way to connect individual pieces that are going on with different teams or different groups of people.

And then one of the questions we answered in the online seminar and I always get asked, what about geographically distributed teams? That’s always an element of scaling also.

At the beginning of this, we talked about these different activities that revolve around a story map, and one of them is initially constructing it and filling it in and doing some planning. I find that nothing beats getting a core, small group of people to initially build that map, and getting them together face-to-face to do that. And even in big, geographically distributed teams, it doesn’t work to get a big group of people together anyway to do it. Get a smaller group of people together, and then the problem becomes, “How do I socialize that with a lot of people?”

And you get excellent story-map visualization practices, like Todd Warfel’s Task Analysis Grid. I don’t want to claim Todd Warfel’s practice as a story-mapping practice, but gosh, that Task Analysis Grid is a perfect representation of a story map that also conjoins a lot of the missing context that’s not always in a story map, like users and where they’re using it and pain points. There’s a lot of great things in that.

If we’ve got a large team, oftentimes it’s a small team that builds the map, and oftentimes we then need to build something that’s more of a design-communication version of a story map, to share that with other people.

Adam, I’ve hit a number of different elements of scaling, and we could probably go deep into that for a while, but it’s a sticky subject.

Adam: Well, Jeff, thanks very much. It was a lot of fun, and I appreciate you circling back with us. To everyone listening in, thanks for joining us and for your support of the UIE Virtual Seminar program.

In Agile, these contributions and expectations aren’t nearly as clear. Waterfall gave us nice “hooks” to hang our UX work on, but Agile doesn’t do that. The team breaks up work into small chunks and just starts chipping away at it. There’s no clear point when requirements are done (they are gathered in parallel with trying out the designs). There’s no clear point when design is done (it evolves over the duration versus being declared up front). It doesn’t seem that there are any clear hooks in an Agile process.

Interestingly, if you dig deeper, the hooks are there. In this issue of UIEtips, we’re revisiting the conclusion to Jeff Patton’s two-part article on his best practices for integrating user experience work into an Agile development environment. He talks about how teams he’s worked with have found the hooks and made it work.

Read the article 12 Best Practices for UX in an Agile Environment – Part 2.

Jeff is also presenting our next virtual seminar Story Mapping for UX Practitioners: Tying Agile & UX Together. If you work in an Agile environment and you’re struggling to weave UX thinking and principles into the iterative process, you’ll definitely want to attend this seminar. This seminar is on pace to sell out, so save your spot today.

The same can be true in an Agile development process. Often times, the team will start with a piece of the project that isn’t the first thing the user experiences, but instead might be at the end.

In this week’s UIEtips we are revisiting part one of an article we published by Jeff Patton in 2008 on his 12 Best Practices for UX in an Agile Environment. Jeff has been working with Agile teams and user experience professionals to discover the best methods to work together to create great results.

Jeff mentioned that user experience designers on the Agile team end up adopting a similar role to the person who gets the credit of “Continuity” in a film. It becomes their job to make sure the final experience makes sense, even though the order of construction was not linear. This is a huge challenge and one that has come to the forefront as more teams move to an Agile development method.

Read Jeff’s article 12 Best Practices for UX in an Agile Environment – Part 1.

Jeff is also presenting our next virtual seminar Story Mapping for UX Practitioners: Tying Agile & UX Together. If you work in an Agile environment and you’re struggling to weave UX thinking and principles into the iterative process, you’ll definitely want to attend this seminar.

Story mapping is a way of organizing Agile user stories that communicate user experience. It allows us to build the collection of stories that become the backlog. Agile expert Jeff Patton will show you how story mapping gives you a tool: a tool to both quickly think through and simply describe the user experience. This strong technique helps you put the big picture of UX and the little pictures of Agile in one place, engaging the developers and stakeholders you’re working with.

Users will always have an experience with your product. Story mapping will pull your UX focus into your organization’s process and ensure that experience is a great one.

You’ll learn:

How to build a story map—something you already use—from scratch

You’ll learn to keep the focus on what people are doing, while decomposing into the things your organization designs, and how development happens.

• Bring user experience to the project early and often, while still letting the Agile folks move forward in their process of breaking everything down into little pieces
• Explore ways of describing user experience with Agile stories, and get involved with the “what to build” part

How to overcome the Agile dogma that often starts projects off on the wrong foot

You’ve heard stories and are suspicious, or maybe even had an experience of your own.

• Make sense and avoid trouble in your projects when talking about the user experience, something seemingly antithetical to the agile process
• Story mapping gives you an intermediate structure to represent both the big business “whys” and the specific development “whats” of what the user is trying to do

Why the story mapping vocabulary can alleviate the lack of common understanding that comes with tying Agile & UX together

Between project management, developers, and the UX contingent, you can get everyone on the same page with the terms you introduce and define.

• Use language that still helps you plan and track progress, but doesn’t lose the user experience
• Succeed in working with others on your team who may not be UX-literate, using story mapping as a conversation piece and a collaborative element

You can put this process in place for projects you’re working on right now

Regardless of how far along your team is on a project, it’s never too late to put this technique in play.

• Take control of current projects. Use story mapping to ensure the user experience is an integral part of the product you deliver.
• Reap the rewards of story mapping when you’re stuck, or unsure of next steps, even several iterations into a project

A team deep in the Agile process need things at a certain time, in a certain way. That’s foreign to the traditional UX effort. Story mapping is a way to merge these two worlds. Jeff will dig into why the two approaches are different, and what user experience professionals will do in this Agile environment.

Start story mapping in your agile environment and you’ll be tightly integrated as active team members in the whole development process, and not added as an afterthought. Others will see you as a critical contributor to the process of what to build, and in framing and delivering your product. Join us on September 1.

Get Jeff’s Agile Primer:

Register before August 25 and get complimentary access to Jeff’s 2009 virtual seminar: An Agile UX Primer. Agile refers to a class of processes, and Jeff’s the guy we turn to for this aspect of the design and development world. It’s not a prerequisite, but it’ll add to your takeaways from Jeff’s seminar on Sept. 1.

The introduction of CSS3 and HTML5 brings with it a host of new capabilities. With most modern browsers supporting CSS3 and HTML5, implementing them into your designs is becoming easier. Understanding what is now possible with these new standards can help you create better designs more efficiently and effectively than ever before.

Stephanie Sullivan Rewis and Greg Rewis will be presenting a full day workshop at the User Interface 16 Conference November 7-9 in Boston. They’ll dive into what the introduction of HTML5 and CSS3 means for designers and developers, and what you can accomplish today by putting it into practice.

Here’s an excerpt from the podcast.

“…We’re talking about these capabilities like the drop shadow or the text shadow that up until now have required a designer to go into Photoshop, do it all, export that as a JPG or a transparent PNG or, God forbid, a transparent GIF then hand it off to a developer to implement into the design.

While that’s worked for us perfectly for 15-16 years of web development, the issue is if we all lived in the perfect world where the client said this is what I want. I want it in this size, this is the wording, I will never change it, I promise to never change my mind. Then we wouldn’t even be having this discussion. But as every designer knows, that’s a utopia we’re never going to achieve because clients always change their mind. They always want to tweak

On the viewer’s side, this is an image with no SEO benefit since there’s no selectable text. So if we can create this image using CSS and HTML, then we have it appear correctly and still get SEO benefit from it since it is text.

Not only can we make a change by simply going into a text editor and correcting the spelling, but we also can go into that same text editor and make a few changes to the CSS and completely change or update the look of the design as it’s presented in the browser…”

Tune into the podcast to hear Stephanie and Greg address these points:

• What can designers take advantage of today with these new CSS3/HTML5 standards?
• How have CSS3 media queries changed designing for multiple platforms?
• How does a tool like Modernizr work?
• How do CSS3 and HTML5 help with Accessibility?
• What do designers need to know so their design gets coded as intended?

Do you have experience with CSS3 and HTML5? Share your thoughts in our comments section.

Recorded: July, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Jared Spool: Welcome everyone to another episode of the SpoolCast. I have with me today Stephanie Sullivan Rewis and Greg Rewis who are going to be delivering a fabulous workshop at the User Interface 16 conference in Boston.

They’re going to be delivering the workshop on Everything a Designer Needs to Know About CSS3 and HTML5. Hey there Greg and Stephanie. How are you doing today?

Stephanie Sullivan Rewis: Good. Hey Jared.

Greg Rewis: Doing great, Jared.

Jared: So I’m really excited about this workshop and I really wanted you guys on the program this year because what I’m seeing, and you can tell me if you’re seeing the same thing, is that the new changes that are coming down with HTML5 and CSS3, the browsers are finally getting to a point where they’re adopting these things.

So you can actually do much of it, though not all of what’s in the specifications, and because of that there’s all this new power and capabilities and there are all these things that you used to be able to do that you can’t do anymore.

All these things have changed and I think it really behooves a good designer to understand what this is all about so they can talk intelligently with the developers they work with and understand the capabilities and design for them. Is that what you guys are seeing too?

Greg: Absolutely. I think that there’s a lot changing and I think, even more importantly, there’s a lot of confusion out there about what’s changing, you know, what can we do, what can’t we do.

Sort of exactly as you pointed out that we hear a lot in terms of the buzz of HTML5 but then when you dive into it you then you start running into the, “oh, but you can’t do that yet, oh you can’t do that yet, or yes you can do that but only on a Thursday wearing a red shirt.”

You know? So I think that’s probably one of the biggest challenges for designers is trying to cut through the marketing of HTML5, if you will, and actually start seeing both the forest for the trees and the trees within the forest I think, to use some really weird hobbled together analogy.

Steph’s looking at me right now going what? Forest with trees?

Stephanie: No, I got it. I got it. I think, like Greg is saying, you know, HTMl5 does not include CSS3 but the marketing for the new Web 2.0 HTML5 certainly makes you believe everything is under the HTML5 umbrella.

And of course we’ll be talking about all that but CSS3 is a completely different specification and is probably more interesting to designers even than HTML5 itself.

CSS3 is going to give us, or is already giving us, amazing new capabilities for more flexible design, more succinct, light weight design which is always better for SEO and accessibility and things like that.

Greg: And rounded corners.

Stephanie: And drop shadows for everything.

Jared: Oh good. I can put my drop shadow cream away. I store it in my medicine cabinet right next to the make your logo bigger cream.

So along with drop shadows and rounded corners help me understand. So what are some of the things designers could take advantage of today because the browsers are supporting them that come with these new standards?

Greg: I think there you go. Rounded corners. Jared, I mean, once we have rounded corners the world is a utopia, right?

Jared: It absolutely is. It is. I think the whole reason the debt ceiling is having problems is because every chart that they show us has square corners.

Greg: That’s true.

Stephanie: Oh my gosh. We could solve so much.

Jared: Exactly.

Greg: There is certainly, obviously, rounded corners, drop shadows, the text shadow. Those things are obviously going to add in some interesting capabilities, if you will, for designers.

And you know, I’m sure a designer might even, at this moment, be thinking well wait a second, I can do that today. I go into Photoshop, I make a box, and I put a rounded corner on it or I write some text and I put a drop shadow on it.

Sure you do but that’s exactly the problem. You’re in Photoshop and you’re not in a browser. One of the truly, sort of, exciting things for these new CSS3 capabilities is the idea of tearing down the need for images themselves. Now, before the designers go running for the door going oh my God we’re going to have a web without pictures.

That’s not what we’re talking about. We’re talking about these capabilities like the drop shadow or like the text shadow that up until now have required a designer to go into Photoshop, do it all, export that as a JPG or a transparent PNG or, God forbid, a transparent GIF and hand it off to a developer to implement into the design.

While that’s worked for us perfectly for going on 15 years of web development or 16 years, whatever it’s been, the issue is, as any designer out there can relate to, if we all lived in the perfect world where the client said this is what I want. I want it in this size, this is the wording, I will never change it. I promise to never change my mind. Then we wouldn’t even be having this discussion but as every designer knows that’s a utopia we’re never going to achieve because clients always change their mind, always want to tweak.

And in that work load that we’ve had established for these last 15 years that means the designer has to get involved again, even if it’s just, “oh my God I misspelled the boss’s name in the graphic.”

The designer has to go back in, go through the Photoshop, Fireworks, whatever, Illustrator reader, whatever program they’re using, workflow, to re-output that image. Then on the flipside you go OK that’s great. I have time to do that.

I want to do that. On the other side, on the viewer’s side, this is an image. This is not selectable text, for example.

That means I’m not getting any SEO benefit out of the text that’s baked into the pixels of that image. So if we can do things in pure HTML, in the markup of the page, and CSS to give us that creative expression of the drop shadow or whatever it happens to be then we’re benefiting on two sides.

Not only can we make a change by simply going into a text editor and correcting the spelling but we also can go into that same text editor and make a few changes to the CSS and completely change or update the look of the design as it’s presented in the browser.

Stephanie: Right. They may want a green background instead of a blue one or a green gradient. We can do real gradients now with CSS3. Or they decide they want a different font style. We can do real fonts on the web now. Actual web fonts, not the boring Georgia and Verdana and Arial and the things we’re so sick of at this point.

Greg: I’m not sick of Arial. I love Arial.

Stephanie: Yeah, The Little Mermaid. We can actually use real fonts that have licensing that allows us to use them on the web and we’ll talk about that a little more. And change everything from the gradient, the amount of rounding on the corners, or drop shadows, or background colors and fonts all without ever entering a text editor again and that’s a lot of power.

Because everybody knows, like Greg said, clients invariably or bosses invariably change their mind. We’ve also got some amazing things we can do with opacity and RGBA.

Greg: And we can even combine it all by laying it all on top of each other by using multiple backgrounds and things like that that’s really, really exciting as well.

Stephanie: Lots of changes in the backgrounds and borders module. We can do border images. Then, if you really want to get crazy, you can start rotating things and making them move and animating them all with CSS.

Greg: And you should.

Stephanie: No, now I like to say just because you can doesn’t mean you should.

Greg: But I do.

Stephanie: However, Greg likes to do those things.

Jared: Greg has always been a sort of MySpace kind of guy.

Stephanie: Yeah. There will be gratuitous movement when Greg does his portion of the session.

Greg: Every attendee will go out with the knowledge of which one of us actually has a design sense and the answer is not the male part of this partnership.

Jared: So it feels to me like there’s really a lot of really important things in terms of these standards but there are also just a lot of capabilities. You know, some of the stuff that I’ve seen people doing with like drop shadows it takes me a second to look at that and say “Oh wow that’s a really cool effect.”

I’ve seen really neat sort of 3D effects and stuff that was all done by just changing a couple of simple attributes.

Greg: That is one of those areas where you call it out. We’re really on the cutting edge. In terms of, even though I realize that in the specification it does say 3D, I sort of have a beef with them calling it 3D because 3D, for me, is coming out of a 3D program. You know, I’m seeing an Avatar style model and it’s really not that.

It’s more what I like to call “postcards in space”. It’s a two and a half D. I can turn the post card over and see the back side and have something actually on the back side and that is really, really exciting and starting to be embraced by some of the browsers, specifically if you’re in the mobile arena, developing for the IOS or Android platforms.

It’s there. It’s available right now and we can start using that. You’re right, that’s truly amazing when you start thinking about hey wow, that’s not even necessarily a graphic that was exported out of Photoshop but rather is all done live, if you will, rendered by the browser, out of text really.

Stephanie: Greg brings up a good point and that is the point about mobile because many designers are now being pushed to go ahead. And a lot of them, I think, started with print then they get pushed into well now you need to design for the web and now it’s being pushed forward to and let’s add mobile into that or maybe even designing for the TV.

Designing for a lot of different sized screens and experiences. And the interesting thing about mobile is we do have a lot of web kit based browsers there and web kit, in many ways, has some really interesting properties that are web kit only like masking. Masking is you know, a way… it’s just like in Photoshop or Illustrator when you apply a mask and only show a portion of it.

We can do that in web kit browsers now. And mobile, you know, Android and IOS, having so many web kit based browsers, that’s a real bandwidth saver and technique that we can use, or designers can use, right now for those devices.

So there’s a lot of really interesting advanced features in the mobile space that we can actually use today.

Greg: I think if you were to sort of be coming at it in a newbie today I’d almost say it’d be more exciting to head in that direction than on the desktop browser because of the excitement going on in the mobile space.

The best news of it all is we can actually design, one of the other great new capabilities of CSS3 is something called a media query that allows us actually to design for both at the same time and have a responsive response, if you will, to the device that the page is being rendered on or shown on so we can move from the desktop through the tablet space down to the mobile phone in your pocket space all with the same content being adapted through the CSS.

That makes it even more exciting, I think.

Jared: So let me understand the media query thing. So previously, before HTMl5 and CSS3 and many of the servers, you had to do some sort of device detect and then you’d send your phone pages, off your small screens, off to an M dot page which would then have a completely different design and then if you made changes on the site you had to change them in both places simultaneously. But now…

Greg: You were basically maintaining two different versions of the same site.

Jared: Right, right, which had all the implications of that. But now with these media queries I can actually tailor CSS to the different devices.

So I only have one design. It’s semantically marked up and then the CSS decides well if I’m looking at this on this device then I show it this way and if I look at it on this other device I show it that way.

Stephanie: Right. And for the most part that is a good way for many sites to handle.

It’s not to say there won’t be any M dots. There are times where it’s still appropriate to have a completely mobile site but many sites would benefit from the one web approach which I like a lot, the put your content up and then show it in different ways to devices with different capabilities and sizes and resolutions.

Greg: In our session we’ll actually be talking about that because one of the topics that we’ll cover is exactly that, is how do you approach designing for the different style screens and Steph will begin a very, very long explanation about her love affair with something called Modernizr.

Jared: Talk to me about Modernizr because people keep talking about this and I don’t know what it is.

Stephanie: I adore Modernizr.

Greg: See? I told you.

Stephanie: Everything that I’m building right now… Because I am a front end developer and everything I am building right now uses HTML5 or CSS3 to some extent or another depending on, clearly, the client’s browser specs and such. It depends on how far I can take it but I’ve got a couple that are just full bore.

But either way I use Modernizr. I’m very against browser sniffing which means using JavaScript to try to figure out using the UI string or whatever, you know, what browser is this and what should I serve it?

The problem with that is people don’t keep it up and so new browsers are literally coming out every week and sometimes what happens is they’ve got something that your browser sniffing string doesn’t understand and so it kicks the user back to some old, crappy version of the site, if you will, and not the most modern, capable version.

So there are a lot of reasons I don’t like sniffing but hat’s one of the main ones. Modernizr is a JavaScript library. It’s very small. The reason I love it is it checks for the capabilities. It doesn’t sniff for you know, “what user agent is this?” It says, “what is this user agent capable of?” And it’s very simple to use.

It requires a simple class on the HTML element and then you include the JavaScript. What it does is when the user surfs to your site they hit the site, Modernizr tests their browser very quickly and gives you back a whole string of classes on your HTML element.

That will tell you, it’ll say like multiple backgrounds, no CSS transform, and just goes through all the HTML5 and CSS3 new properties and capabilities and gives you feedback on what you can and can’t serve to this browser.

Then you can choose to either progressively enhance and serve something different. Say a browser doesn’t do border image. OK, great. Now I know that. Well then I’m going to write a class using no border image as the first piece of that selector to feed it a plain border image, something more simple.

But the more modern browser that does border image now gets the beautiful experience that is enhanced and then you can also find through JavaScript or serve through JavaScript different scripts to, what I like to call, regressively enhance meaning OK maybe it doesn’t matter if this older browser gets rounded borders and we’re going to leave that one square but it does matter that they can’t do local storage.

So I need to serve a JavaScript that’s going to store that in cookies or something like that.

Then I can store a script loader that says oh there’s no local storage available therefore I’m going to serve this JavaScript only to the older browser. It just gives you a super, fine tuning ability to not throw all the scripts and things you need for your site onto modern browsers that don’t need them.

So the better the browser the better their experience and older browsers can have an enhanced experience with JavaScript or extra CSS or whatever you need to do. I absolutely love it. It’s super powerful.

Greg: Told you.

Jared: This sounds really cool. Now, can this also help me with making sure that the stuff I’m producing is as accessible as it can be?

Stephanie: Yes. It definitely can help with that in that part of accessibility is making sure that everyone can see it. You don’t want to do a CSS3 technique that causes your people not to be able to see things.

Let’s say you have a gradient and some text on it or you’re using a technique that without the technique the text may not be very visible on the background.

If you know that technique is not possible you can feed that browser a nice, high contrast background where something might be missing for them, say a lovely subtle gradient.

Greg: The idea we talked about earlier with a text shadow. Very often you’ll use a text shadow to pull the text out of the background to give it that stand out readability, if you will and if my browser doesn’t have that text shadow capability the text falls into the background and becomes less readable.

So that, you know, that would be one of those situations where I would want to use Modernizr to perhaps swap out that background or in some way…

Stephanie: Change the color of the text.

Greg: Yeah, change the color of the text or whatever that might be to pull that out. So very definitely just from those visual style of techniques but speaking just from just general accessibility that’s one of the other exciting things that it doesn’t get a lot of play, if you will.

It’s not the sexiest of topics to talk about when we do talk about accessibility but it is a very important thing to consider throughout the designs.

As a designer who is approaching a project how do I need to be thinking in order to provide a design that can become accessible in terms of when it becomes code, if you will.

Stephanie: And accessible doesn’t mean… You know, a lot of people think about it as “Oh that means my page works for non-sighted viewers, for blind viewers.” That is not the only thing accessible means. Accessible also means the person with carpal tunnel that needs to tab through your page is able to access all the content and links or the person with low vision, hi that might be me.

Once you’re over 40 let’s face it. We all get lower vision as time goes on. If text size increases, and I’m a big stickler for this, if text sizes are increased by the user you need to make sure your design doesn’t fall apart.

I had a site that I showed in a talk I did yesterday that I built for somebody last month. Really cute design, very whimsical, very beautiful, well designed, very graphical.

And on the home page of her site her navigation, which was real fonts using font face, is all on these little, like, garden vegetable bins that look like they’re sitting on a little…

Greg: Little signs that you see in the gardens.

Stephanie: Yeah, little signs and there’s a bin of corn ad a bin of tomatoes and they have little signs and that happens to be her navigation.

Well, what happens when the person surfs into your site with say 32 pixel base font instead of 16 pixel base font, which is the default, that means they now have giant text on your site and all the cute stuff on the vegetable bins is now blown out all over the page because the vegetable bins are still sitting there.

Well, the beauty of some of our new CSS3 techniques are we have something new called background size and I was actually able to make that page fit the text no matter what size that user is surfing with on their text using a background sizing technique that makes the whole page basically zoom to the size of the text just like a browser would do.

If you hit to increase the text size many browsers will now zoom but if somebody comes into your site with larger text already they don’t zoom and so there are some very simple CSS3 techniques that if you think about it will make your site work and be more flexible and more accessible to all users.

Greg: I think that’s one of the really exciting things right now, Jared, is that you know, because this is all so new you tend to look at a technique or at a specification and you go, “oh, OK, well that’s how we’re going to use this.”

But, the really cool part is because it’s so new we haven’t explored all the different ways to use this and a lot of this is just sort of, you know, creative exploration where you suddenly go, “wow. Hey, wait a second. What if?” and “Can I use this?”

Another simple example that I’ve seen Steph use is using a drop shadow to become a border. You go wait, how can a drop shadow be a border? But you know, there’s some really interesting things you can do with that to even overcome some of the limitations of CSS3 because oh yes there are limitations too.

Stephanie: We have no ability to do multiple borders.

Greg: Yeah, exactly. Something as simple as hey we’ve got multiple backgrounds but we don’t have multiple borders but there’s some really neat tricks that we’ll be talking about in our session on how to overcome those limitations and sort of creatively use some of the new capabilities to do that to give the illusion of what you’re trying to achieve even though you actually did it without doing what you thought it were doing, as it were in the case of a multiple border.

I think that’s one of the really exciting things because this is all so new that we’re seeing a lot of experimentation going on and we’re hopefully going to share with the attendees some of the experimentations that we’ve been doing and the successes that we’ve had with those.

Jared: Yeah I mean, it feels to me like the new specifications give us some really interesting building blocks.

I remember when I was a kid I got my first Lego set and it had just square blocks and the occasional curved thing but it didn’t have all those weird shaped unusual pieces that you get in the Lego set today which all of a sudden gives you this capability to build things you couldn’t build before.

Greg: In other words, your Star Wars Death Star was just a cube?

Jared: It was a cube. It looked a lot like my basic fortress and my GI Joe’s bunker house.

Stephanie: Your castle.

Greg: Exactly.

Stephanie: Right. Exactly. One of the beauties is really experimenting with each site that I build. And sometimes Greg, he will be looking over my shoulder or he’ll be helping me.

I always like to get him to do my JavaScript. He’ll be doing something and he’ll go, “hey, what if you did this?” And then I go, “Oooh.” Then I’ll try something new that I never would have thought of before.

So we kind of feed off of each other. What if you could do this? What if you could do that? So it is kind of an exciting time.

Greg: Except her part of feeding is, “Greg, don’t rotate it that much. Don’t make that move.”

Stephanie: Greg, that doesn’t need to go out of its boundaries just because it can. But seriously you know, it is really fun because there is so much that we’re figuring out.

They give us the spec but it’s up to us to put it through its paces and figure out all the cool things we can actually do with it that are super practical and that really give us flexibility in our designs and, like I’ll say over and over, real text which is so great for real search engine spiders and people needing to use assistive technology.

Jared: So one of the things that you and I talked about when you were explaining to me this session was that there are things that designers can do that make the coder’s life easier and there are things they can do that makes the coders life hell. So the person that’s actually taking the design and translating that into what the browser’s going to see.

And you’re going to talk a little bit during your session about what a good designer needs to know in order to make sure that the design they give to the developer is easy enough to code up that it actually gets implemented the way they want it implemented instead of, you know, reinterpreted.

Greg: That section is going to be called “How A Designer Can Increase Their Lifespan” or “How To Shorten It Very Quickly”.

Jared: So what are some of these things that can get us into trouble if we’re not paying attention?

Stephanie: Well, I basically do work for a lot of different agencies so I work with a lot of different designers. I don’t design myself. And many times, or I should say most of the time…

Greg: Well you don’t design anymore.

Stephanie: I did.

Greg: Because you are a tweak-aholic.

Stephanie: I’m a horrible tweak-aholic and so I find it much more cost effective to pay someone to do the design to get what I want rather than try to do it myself. And you know, there are much better designers than I am, and I learned that early on. I work with a lot of different designers, whether I’m hiring them or I’m being hired by the designers.

And usually, that means I’m getting a PSD. Many, many, most designers work in Photoshop even though I wish they would work in Fireworks. And so Photoshop there are different ways that effects can be created using masks or smart objects or what’s the little drop-down? It’s called effects. Greg, I’m looking at Greg because he knows the Photoshop lingo so much better than me.

Anyway, there are ways to add effects to an object in Photoshop. There are ways to keep it more editable, and one of my biggest complaints is that now we can do real gradients on the web, there is a way that a gradient can be created so that it’s still actually a gradient.

I can open it, and I can see what color did this gradient start and end on, and what color are the stops in this gradient, and what percentage of the gradient did this stop get put on?

There are other ways that gradients can be made where they’re just created as an effect and a bit map, and I have to sample, sample, sample the little bits and try to figure out how to recreate this gradient as code.

And these are the days where Greg probably likes to be in a different office than me because I’m just ready to throw things through the window after awhile.

And so, there are ways to make your coder’s life more simple in the way that you create things, and another one is…

Greg: Can I mention something?

Stephanie: I don’t know if I should let you. Keep it kosher.

Greg: I’m thinking consistency.

Stephanie: Ah, yes, there’s one. I just finished or I’m finishing right now the most beautiful design from a very well respected agency that I was very excited to start on for a startup. Because in my mind there was this assumption that this meant we would have grids and well spaced and thoughtout things, and a certain number of colors of grey text, and a certain consistency to the rounded borders that are everywhere and in their color and size and blah, blah, blah.

What happened was not at all. I have like 18 colors of grey text with a variety of sizes. I have 38… No, no, as of yesterday 39 different gradients that I have had to export because none of them are ever quite the same enough to re-use, and my client has an eagle eye and notices if I don’t use the exact gradient that the designer put.

They’re all shades of gray, essentially, except for a couple.

So, consistency, reusability is really good for your design.

Greg: Another thing that we’re talking about when we talk about screens is how to create certain design elements that can grow or shrink based upon the content that’s going to be poured into them because as designers one of the things that very typically happens is the Lorem Ipsum syndrome.

You’re working with dead text, a dead language, if you will. You’re not working with the real content that’s going to be poured into this design.

Stephanie: And you can make sure that it fits just perfectly.

Greg: Right. All those three boxes that sit side by side on the page are all exactly the same height because you use the same three Lorem Ipsum paragraphs to fit into them.

And so, one of these things that we try to get across to designers is you need to begin to think in terms of that flexibility that the web is built upon. That this is not a magazine design, that I can nail everything down, cut it all out with scissors and paste it up because it’s never going to grow.

This is one of the hardest things, I think, for designers to get their head around, and they still go, OK, but I still want three boxes of equal height right here.

Well we’ll tell them, you can have that, but you’re going to have to give us some reusable elements. It might only be three pixels, please give us more, but it might only be three pixels of vertical color that is the same that we then can use to allow to grow and repeat, you know, in order to adjust for that varying content.

It’s these things that we’re going to try to call out and show through some of Steph’s painful experiences. What went wrong in this design, and how might it have been created to have been much more flexible, much easier to implement from a front end developer’s perspective.

Stephanie: And that only helps the designer because I know how I am about my code. When I hand code off for someone to build a site with it…

Greg: It not only helps the designer.

Stephanie: Right. When I hand my code off to the back end team that’s going to implement the CMS or whomever is going to build the actual site from it, that’s my baby.

I mean, I really want that code to keep its integrity and to stay beautiful and to not get cluttered up, and designers feel the same way about their design. They did things they did for a reason, and they want it implemented.

When they see it on the web, they want it to look like their design. There are things they can do to help assure that that is exactly what happens because I don’t blame them at all. I feel the same way.

Jared: Yeah, no, it makes perfect sense to me, this whole idea that when you have those translations that happen because the way that they designed it doesn’t translate nicely into the code language that you have to put it in.

Then, there’s interpretation, and that interpretation is very likely to change the underlying meaning and intention of the design, and that’s just going to break what the designer wanted to do.

It’s funny we’ve been doing work, the new UI16 website’s being designed by Dave Shea, and I’ve been teasing him about… He’s a fabulous designer, but his mind reading skills really suck. He says, yeah, I keep working on it. He says, I try my hardest. I said, yeah, but…

Stephanie: Actually, I saw that yesterday when you tweeted something, and it looks beautiful.

Jared: Yeah, the site has been great to work with, but there are exactly those things. He’ll come back with some stuff, and we’ve been working with a guy named Marc Amos of Boston Design Studio. He’s coding up Dave Shea’s stuff, and Dave does a fabulous job of handing off.

Few people know CSS like Dave does, so you know, the stuff he hands off comes very close, but there is interpretation that happens. When we get the real copy in there, when things shift around, there is all this sort of translation has to happen, and there’s conversation that has to go back and forth. The way you hand it off really makes a huge difference.

Greg: And the problem is earlier in the work flow that the issue, if you will, is created the more it’s going to snowball even down to the point of certain experiences where Steph handed the code off, and then only to find out that the CSM was not even capable of handling the code that she handed off.

And so, it was one of those things had that been clarified early on in the process, completely different approaches could have been taken.

And so I think, you know, if you really boil it down, in a lot of projects the design is that initial piece. So if we can catch that early on and the designer is creating that integrity early on that is going to, you know, allow itself to be maintained throughout the entire flow process, flow through the tearing it apart, putting it back together in code, and then dumping it into a server or CMS.

If the design integrity is good initially, then it’s going to help avoid all those problems or potential problems downstream.

Stephanie: And one thing that I do when I work with designers and I’m building a site is I look at their beautiful designs and then as I’m breaking an element down to build their component of it, I think, OK, what happens if, let’s say, there’s a name across the top of the little address box.

Well, what happens if that’s a hyphenated really long name, or what happens when this heading wraps to two lines?

I go back to them and I say, what would you expect to happen? What would you expect to see if this happened? Many times their answer is, oh, I didn’t think of that.

Jared: Right.

Stephanie: Well, I hope you could do this because there are so many different ways we can build things. There’s no one true way. So, this is one thing designers need to think about as they’re building their comps is push themselves to put extra text in one box over the other one, put a longer heading somewhere and think through, now what would I like to happen.

The quicker they can transfer that knowledge to the person, the front end developer building, the more solid their design will be in the end because they’re going to have to hand off.

Let’s say they’re building a flexible design, and there’s an image or here’s the one I love. I see this all the time, the pattern of design where you have an image and next to it, and it’s in a box, and next to it in the same box is some text which is the same height as the image. This is a very common design pattern. What happens when there is much more text?

Greg: Or much less.

Stephanie: Right. Much less is a little less of a problem because the image will hold that box open. The bigger problem comes when there’s more text. And now, either the text is going to run out of the box or the text is going to push the box open taller. Now, your image is sitting there looking all cut off hanging in mid-air.

One of the little tricks that designers can do is don’t crop your image the exact size of that box. Give me an image that’s maybe twice the size of the box with the portion that you wish to be shown the height that you show, say, it’s the top portion or it’s the bottom portion.

Maybe, it’s the bottom portion, but you can give me a bunch of sky, you know, extra sky so that if the box grows, the sky shows a little more, or maybe it’s the center of that image, but it can grow on the top and bottom.

I, as a developer, can then situate that image in the box, either centered or the top or the bottom, but there is something more to show so that your design doesn’t break apart. Little tricks like that are super important, especially with imagery for designers to hand us not just cropped exactly what they wish to be seen.

Jared: Right. That makes perfect sense. So, it sounds to me that if I’m a designer and I get my head around how the development process works, what you guys are doing, taking the designs that I’m putting together and translating that, knowing what the capabilities are like CSS3 and HTML5 so that you can take advantage of those capabilities. But also understanding where the design needs to have that sort of flexibility.

Then, that gives me the advantage of making sure my intention is there. It might buy me a little bit more design time because the development time will be cut shorter, and it will just also improve the overall quality of the results, especially in those weird edge conditions.

Stephanie: Right. Absolutely.

Jared: Cool. Well, this has been really fun. I’m really looking forward to the workshop. For those of you who are thinking of coming to Stephanie and Greg’s workshop, it’s going to be November 7th through 9th in Boston at the User Interface 16 Conference.

And you can get more information on that at uiconf.com which is a site that has a lot of great resources on it, and we are very excited about the conference that’s coming up.

This is your first time speaking at the UI16 Conference. We’re really happy that you will be part of it this year.

Greg: You did assure us that Boston will be warm in November, right?

Jared: Oh, it’s going to be awesome. [laughter] You know, this climate change thing has some advantages.

Stephanie: Well, we live in Phoenix, so we’ll be expecting something really lovely.

Jared: Yes, it’s going to be a dry cold. [laughter]

Stephanie: Exactly.

Jared: Oh, November, it’s usually not too bad. Last year we had a bit of rain, but most of the time… The snow doesn’t start until later, so we probably won’t have any snow but you might want to bring your skiing jacket, I’m just thinking.

Stephanie: Excellent.

Greg: I’m glad you didn’t say winter clothes because that just would have been jeans for us.

Jared: That’s probably not it. It’s going to be great to have you. Thank you so much for taking this time to talk to me today about all this.

Stephanie: Thanks for having us, Jared.

Greg: Thank you, Jared.

Jared: I want to thank our audience for listening and, of course, I want to thank them for encouraging our behavior. So, until next time SpoolCast, take care. Thank you.

So much of a project’s success is determined at its start. If the team comes together and sets the stage properly, everything works out smoothly. People end up with a great vision and solid understanding of how the design should turn out.

Yet, a project that doesn’t get off to the right start will often struggle. The team will find themselves in conflict, important requirements often emerge too late, and good ideas get left on the cutting room floor. Unfortunately, in my work, I see too many projects that have gone down this road and find themselves trying hard to get back on track.

A few years back, I was lucky enough to see Kevin Hoffman present his workshop technique for kicking off projects. It was a completely different approach than any I’d seen before. He showed us how interactive exercises, brainstorming games, and collaborative sketching techniques surfaced important details about the project, while elliciting innovative ideas from everyone on the team.

Since then, he’s had the opportunity to refine his methods in his projects at Happy Cog, a leading web design firm. Happy Cog’s clients have been so impressed, they’ve asked him to teach them his techniques so they can kickoff their other projects successfully.

I’m really pleased that we can have Kevin as part of the User Interface 16 Conference program. As we’ve been working on the plans for his full-day workshop, I’ve gotten a glimpse of just how much fun this day will be. Kevin knows his stuff and has packed the day full of both solid theory and practical exercises. It’s almost criminal that something this fun is a critical work skill.

See the other UI16 Spotlights:

You can catch the sneak preview of UI16 at uiconf.com. (And there’s still a few of the sneak preview $1,349 registrations left. Snag one while they are still available.)

Not every job will require that a designer know how to code. However, there are three reasons why learning to code makes you a better designer:

1. You’ll better understand the medium you’re working in. If you know what database queries will be faster than others, you can make the right response time tradeoffs. If you know what’s easy to code and what’s difficult to code, you can get your ideas implemented faster (and more of them, since development time is a limited resource.) Understanding what your medium does well and where isn’t as effective makes for more informed design decisions.
2. Knowing how to code helps you produce better prototypes. The best way to communicate a design idea to your teammates and clients is through an interactive prototype. Producing your own quick prototypes brings your ideas to life sooner, releasing that inner brilliance you’re carrying around and helping everyone see what your designs are really about.
3. Knowing how to code helps you identify bugs and flaws in the production code. As your team’s designs start to come to life, you can play an essential role of helping the developers isolate interaction problems, which means your end product will be the best it can be.

There’s been a lot of debate as to what languages designers should learn to code in. Based on these three reasons, I think it needs to be the languages used by the rest of the team, whatever they may be.

It’s clear from our research that designers who can code bring more to the team and, in the long run, see more of their brilliant work making it through the development process, to the user.

Interestingly, it isn’t the designers who get to decide if coding is a valuable skill. It’s the hiring managers. And right now, based on today’s jobs market, it’s pretty clear where they stand. Many want to hire super designers—designers who can also code.

While hiring super designers has always been floating around, the real demand has come recently out of Silicon Valley startups. With a couple of high-profile design successes, like Apple and Mint.com, the investors and entrepreneurs in the Valley now have a new appreciation for the work of designers.

Startups, however, try to run as lean as possible, so they look for talent with a broad set of skills. The thinking among the Valley folk is, if they can get someone who does both, they can get their product from concept to ship with an ideal set of resources. Otherwise they’d have to hire two people. Or do without one.

We’ve proven for years that you can ship a product without a designer. Many companies have done that, and while it doesn’t make for a great result, it does ship. However, it’s much harder to ship a software product without a coder, if not near impossible.

That’s why, right now, there are dozens of startups looking to pay big bucks to find the coding super designer. The demand is high and those designers who have proven, practiced coding skills can demand a higher salary than those who don’t.

What about the non-startup portion of the hiring world? Right now, the established organizations find it easier to have larger teams with separate developers and designers.

Yet, that doesn’t make the designer that can code any less valuable to them. A team with two coding designers is more flexible and capable than a team with one non-coding designer and a non-designing developer. The flexible team can produce well-designed results better and faster.

Coding and designing are collections of skills. What we’ve learned is teams with a better distribution of skills, not segmented by roles, produce better results. Having a team filled with individuals who can both code and design will be more effective in the long run than a team where the skills are divided up.

If you’re a designer, you don’t have to learn to code. But if you do, and you get good at it, you’ll find more opportunities as time goes on.

Whether it’s on the design side or development side there are tricks and techniques you can benefit from. Often, these tips can save you time and frustration. You may not even be aware of them unless someone actually shows them to you. Being able to see someone else’s approach reveals knowledge that you can’t find anywhere else. And who better to learn from than experts?

The Sidebar Creative collective: Dan Rubin, Bryan Veloso, Jonathan Snook, and Steve Smith, build and design some of the best websites and applications out there. They have over 50 years of combined experience they want to share with you. This year, the guys at Sidebar Creative are conducting three separate, intensive one-day, hands-on workshops to fine tune your skills as a web designer. Those workshops are called the Web Design Masterclass.

In this podcast, Jonathan Snook and Steve Smith join Jared Spool to discuss some of their best tips and techniques they learned from each other.

Here’s an excerpt from the podcast.

“… the most difficult thing to figure out is not ‘What do I need to change?’ but ‘How do I go about targeting the individual things?’, ‘How do I get CSS that is only for these particular browsers, or these particular platforms, or this particular screen size?’ And there are lots of little tips and tricks out there to be able to handle those things.

It’s important to note, some people start to think about this again and think, ‘Oh, you’re doing browser detection, and you’re just testing for various browsers and you’re giving them specific things again, and that sounds really dirty and nasty.’ But I think the distinction here is that what we’re moving towards is not browser detection. It’s not asking, ‘Well, am I using mobile Safari?’ What we’re leaning towards now are things like feature detection, where we’re looking and saying, ‘Well, does this browser handle CSS transitions properly?’ And if so, then we can provide them with those adequately enough.

Oftentimes, for things like transitions, we don’t even need to detect for them. Sometimes we can just put them in our CSS, and if they happen, they happen; and if they don’t, they don’t. It’s fine, and it doesn’t even matter. But when you start talking about things like responsive web design, media queries, and basing your style sheet based off the browser space that’s there, these are things that are actually really simple and easy to implement. In minutes. To just change various things about your layout depending on the real estate that’s available to the user. So they oftentimes can be very, very simple…”

Tune in to the podcast to hear Jonathan and Steve address many points, including:

• Are there any downsides to HTML5 and CSS3?
• Are users on older browsers being left in the dust?
• How much more work do you create for yourself when designing for multiple platforms?
• How do you tweak things rather than doing a complete redesign using tools currently available?
• Do you have any tips when it comes to accessibility?

Jonathan, Steve, and the rest of Sidebar Creative will be teaching their tricks and techniques at the Web Design Masterclass in Austin, Philadelphia, and Los Angeles. For more information including dates, prices, and program, visit the Web Design Masterclass site.

Recorded: March, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
[ Transcript Available ] ]]> http://www.uie.com/brainsparks/2011/03/18/jonathan-snook-and-steve-smith-learning-experiences-with-sidebar-creative/feed/ 0 Whether it's on the design side or development side there are tricks and techniques you can benefit from. Often, these tips can save you time and frustration. You may not even be aware of them unless someone actually shows them to you. Whether it's on the design side or development side there are tricks and techniques you can benefit from. Often, these tips can save you time and frustration. You may not even be aware of them unless someone actually shows them to you. Being able to see someone else's approach reveals knowledge that you can't find anywhere else. In this podcast, Jonathan Snook and Steve Smith join Jared Spool to discuss some of their best tips and techniques they learned from each other. Jared M. Spool and User Interface Engineering (UIE) no 34:39 http://www.uie.com/brainsparks/2011/02/18/spoolcast-designing-for-mice-and-men-ui-across-platforms-qa-with-bill-scott/ http://www.uie.com/brainsparks/2011/02/18/spoolcast-designing-for-mice-and-men-ui-across-platforms-qa-with-bill-scott/#comments Fri, 18 Feb 2011 17:49:05 +0000 Sean Carmichael http://www.uie.com/brainsparks/?p=3422 Duration: 31m | 16 MB
Recorded: January, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
[ Transcript Available ]

The number of places that you can access the web grows every day. People can see your content on TVs, tablets and mobile phones as well as the more traditional desktop and laptop. But are you designing for it? How do your users see it? And more importantly, how are they interacting with it?

Bill Scott is the Director of UI Engineering at Netflix. He is responsible for making sure that the Netflix service looks as it should and works properly no matter how you access it. In this podcast, Bill joins Jared Spool and discusses the challenges and a few of the surprises that come with designing for multiple platforms.

Here’s an excerpt from the podcast.

“…Luke Wroblewski, as you know, and others have started the “design for mobile first” which is really “design for constraints first”. You take a more-constrained view of what you can do in the application, either through input or screen size, maybe you’re on the go, and it forces you to think of the main things first. What are the most important items, tasks or goals that the user has, and design for those.

With the living room, with the left-right-up-down [of a remote control], something’s always focused. And you’re always moving from one item to the other. But then, when you move to a pointer-based [system], nothing necessarily has focus. You have random access to things on the screen; you can get to something quicker. With left-right-up-down, your keyboard is usually virtual, on the screen, and those still need a lot of work. We’re doing some A/B testing in April on some different on-screen keyboards to see what’s the right layout.

And then when you move to mobile and tablet, your input becomes more of the finger, thumbs and, swiping gestures. And then when you get back to the laptop, of course, you have the mouse and the keyboard. Mouse really is both a blessing and a curse, because it’s an indirect method. You can move it around just on either the trackpad or on your mouse pad. But you’ve got scrollbars, and scrollbars are really an indirect way to scroll. They’re not as direct, as physical as flicking your finger.

All this leads to that end of the screen. If I’m sitting across the living room, say 10-15 feet away from a television, what kind of text can I read on it? You have to think about how you design the text. Then the mobile, the screen’s small but it’s right there in front of you. And then the laptop, which you’ve got real high resolution. So you’ve got this output, the screen changes a lot.

And even the navigation. When I’m sitting in a living room, and I’m especially browsing for media content, I tend to be in a little bit lazier mode. I want things to kind of show up for me. I don’t want to have to work real hard to find something. If I’m on a desktop and I’m doing some research or something, I’m may be willing to click a lot, maybe type a lot. So, then your whole posture changes.

I think of input, screen navigation, and the posture of the person, not just the physical posture but their mental posture, as they start to use the application in those different scenarios…”

Tune in to the podcast as Bill addresses these additional points:

• How has the changing landscape affected the way you think about design?
• What are the things that you immediately have to take into account when going from a desktop experience to a mobile experience?
• Is there a way to know what types of content need to be on which devices?
• How have you been using Hack Days and how successful have they been?
• What are the advantages of allowing users to do things like, sign up, directly from their devices?

Bill is also one of the Masters that will be joining us for the 2011 Web App Masters Tour. We’re coming to Philadelphia in March, Seattle in May, and Minneapolis in June. For more details such as dates, pricing, and agenda, visit UIEtour.com.

Register with the promotion code WAMT by February 23, 2011 for any of the Tour cities and get $100 off.

Subscribe to our podcast via

Nathan Curtis

If your site has more than one page, chances are you have repeated elements: Repeated interface elements, repeated design patterns, repeated code snippets. When you multiply your responsibilities over a large site and involve many designers, developers, and stakeholders, how do you make sure you’re not wasting your time building many widgets that already exist? That’s where a standardization process comes into play.

Nathan Curtis and the crew at EightShapes are the leaders in standards, reuse, consistency, and libraries. In this podcast, Jared Spool speaks with Nathan in anticipation of his workshop on this topic at the 2010 User Interface Conference.

(Side note: in this context “standards” are different than “web standards”, though completely compatible.)

When do you know if you need a component library? Nathan says the idea often surfaces when designers and developers start chatting about their collaborations. When many people are touching the design, the idea to reuse components comes up quickly. Standardizing on certain page components, for example, helps in many ways. It prevents double work and keeps the experience across sites (especially large sites) consistent. Certain items, say a calendar picker on a travel site, are especially useful to reuse.

While the creation of a library is useful and efficient in many ways, storing the components isn’t free. It requires a manpower commitment and possible software purchases or provisioning. Nathan says to do it right, you should treat it as if it were another project on your team’s plate. But once committed, you can focus on the quality of the components. If you have 18 different video players across your site, someone can take the time to discover which ones work best and then improve the experience across the site.

Beware of how you maintain your library, Nathan warns. If you let it get too out of date, it’ll lose its credibility and people will begin to stray. If you can’t ensure the library will be faithfully maintained, make sure only your critical items are in the library. Prioritize for the components that have the most effect on the User Experience.

Nathan shares many more tips for libraries in the podcast. But he’ll have even more when he teaches a full-day workshop on the topic at this year’s User Interface Conference.

Explore Nathan’s workshop and the full conference program. Register for UI15 by September 22 with promotion code BLOGPOST and get $400 off.

Are you reusing your components? Are you curating them in a library? Share your experiences with the community in the comments.

Prototyping is an iterative process. You discover what works, what needs improving, and opportunities for new ideas. The earlier you learn about a design change, the easier it is to implement, and the less costly that change will be. Prototyping allows your team to explore ideas before you invest in them.

In this seminar, Todd Zaki Warfel, a recognized leader in the design-research and usability fields, will explore his Eight Guiding Principles for prototyping. These principles are the foundation for more effective prototyping, and will improve your design process whether you’re a seasoned prototyper or just getting your feet wet.

Register before March 24 to get your free personal PDF copy of Todd’s book, Prototyping, A Practitioners Guide, and lifetime access to Fred Beecher’s seminar, The Whys, Whats, and Hows of Prototyping.

Tell us how prototyping fits into your design process. Do you have an example where something in the design was caught early and saved a bunch of money? Or one where something was identified late and cost money? What is your experience with prototyping, and how do you sell it to the rest of the team? Or your stakeholders? Share your thoughts and experiences below. We’d love to hear them!

On January 7 Peter Morville will discuss Search Design Patterns, and in the same session, Mark Burrell will tell you how to then use them.

Later in the month, on January 28, Steve Portigal will present to you his thoughts on studying your users in their own context, Ethnography.

During last year’s UIE Roadshow, our audiences couldn’t get enough on the topic of personas. So, on February 18, we’ve asked Tamara Adlin to talk about The Power of Ad-hoc Personas. Personas can be your ticket to lasting organizational clarity… and it doesn’t take a ton of costly research.

With his book, Prototyping: A Practitioner’s Guide just hitting the bookstore shelves, Todd Zaki Warfel will help you flesh out your design ideas, test your assumptions, and gather real-time feedback from users on March 29.

In the Spring, look for Kristina Halvorson to help you with your content strategy and Louis Rosenfeld to dive deep on Search Analytics. And there is much more in the works.

Until December 3, you can still sign your team up for the UIE Virtual Seminar Subscription programs . Not only is it a tremendous savings, but you get the benefit of lifetime access to each recording and the ease of registering and paying just one time.

We also plan to unveil our plan for our User Experience Training Library. Believe it or not, there is a method to our madness.

Have you ever attended a UIE Virtual Seminar? What do you like best about them? How has your team maximized what it gets out of these learning events? Share your thoughts and experiences below.

Subscribe to our podcast via

A few weeks back we held a UIE Virtual Seminar with Pete Bell and Daniel Tunkelang of Endeca. These guys are the experts we go to when talking about designing for facets.  As always, we had a number of excellent questions from the live audience that we couldn’t attend to during the seminar, so I got together with Pete and Daniel to record this podcast and cover a number of those remaining questions.

If you didn’t attend the live seminar, and are interested in how to make the jump from a standard on-site search to faceted search, then you’ll still enjoy this podcast. If you find yourself wanting more afterward, don’t forget you can still purchase a recording of the session for another 90 minutes of Faceted Search.

During the podcast, Adam asked Pete and Daniel to dig into these questions:

• Should we show counts for each facet? What about when using multiple selection?
• Can you elaborate on the mixing and matching of precision and recall results to construct facets?
• Is there a best practice for deselecting facets?
• Most search interfaces assume a flat list of results. What happens when you mix up different types of results, and how would you distribute them across a page?

Tune in to hear more about designing for facets. Still have questions? Start the discussion in our comments, below.

Subscribe to our podcast via

A couple of weeks ago we held a UIE Virtual Seminar with Ethan Marcotte from Happy Cog West, a designer of beautiful websites. As always, we had a number of excellent questions from the live audience that we couldn’t attend to during the seminar, so Adam Churchill got together with Ethan to record this podcast and cover a number of those remaining questions.

If you didn’t attend the live seminar, and are interested lessons learned from case studies on collaboration between designers and developers, then you’ll still enjoy this podcast. If you find yourself wanting more afterwards, don’t forget you can still purchase a recording of the session for another 90 minutes of “couples therapy.”

During the podcast, Adam asked Ethan to dig into these questions:

• When using a typographic grid on fluid sites, can you talk about what happens when the browser window is pulled in narrower than the “ideal” width or min width?
• At what point do you folks check the accessibility and cross-browser compatibility?
• Is the transition any different between front-end developer and the back-end developer?
• Have you ever encountered a problem between the designer and a back end coder? If so, what was the problem? How did you overcome it?

Tune in to hear more about Comps vs. Code. Still have questions? Start the discussion in our comments, below.

In this popular presentation, Ethan Marcotte teaches about the collaborative process through four detailed case studies. The case studies demonstrate important before and after detail of the lesson to be learned. They also happen to be major sites you know of and can visit today: The Today Show, The 2008 Sundance Film Festival, W3C, and New York Magazine.

If you’re a designer, a developer, or manage a team, you’ll want to see this presentation. Ethan will show you ways to be successful in critical project transitions. There’s no better person to see both sides of the designer/developer relationship than Ethan Marcotte. Many in our industry greatly respect him and consider him to be someone who does groundbreaking work. Ethan has worked with New York Magazine, Harvard University, Disney, and State Street Bank, just to name a few.

UIE Virtual Seminar
Comps vs. Code: Case Studies on Collaboration Between Site Designers & Developers
with Ethan Marcotte
Thursday July 30, 2009, 1:30pm ET
90-minute online presentation

Read more about Comps vs. Code, or see the 3-minute preview Ethan put together, to help you understand what to expect out of this seminar.

Users arrive at your web site with the simple goal to find something that’s important to them. If they find it, whether they search or not, they’ll be happy. When they don’t find it, frustration follows.

Teams often turn to a sophisticated built-in Search capability to help their users find what they seek. However our research has shown that technological magic isn’t going to make the users successful. Instead, it’s a simple understanding of what the users are seeking and how they look at it. We’ve put together the next UIE Virtual Seminar to address this Search issue.

Be prepared to see how Search fits into your site in an entirely new way. Not only will you come away with solid insights from the most up-to-date research, you’ll be chomping at the bit to start making improvements right away. And you’ll be on your way to the world of User Happiness.

UIE Virtual Seminar
Search, Scent, and the Happiness of Pursuit
with Jared M. Spool
Thursday July 9, 2009, 1:30pm ET
90-minute online presentation

Read more about the Search, Scent, and the Happiness of Pursuit, or see the great preview Jared put together, to help you understand what to expect out of this seminar.

In advance of the presentation, we’d love to hear from you. What does your team struggle with when designing for Search? What type of feedback do you get from your users on how well they accomplish their goals on your site? What does a successful visit mean? We’d love to hear your thoughts, questions, and concerns. Please share your thoughts below.

To help you understand what you can expect out of this seminar, Hagan has put together a preview for you:

Don’t miss this presentation! Register with the promotion code STPADDY and get both our lowest rate of $99, and lifetime access to the recording of this talk at no additional cost. Share it with others in your organization to watch whenever they want, as often as they want.

In advance of the presentation, we’d love to hear from you. What challenges do you face with your web application’s navigation system? What advice can you pass along to others? Are you planning to be at the Web App Summit in Newport Beach this April? Share your thoughts below.

In this presentation, Jeff Patton will discuss the essentials of Agile Development, the distinct culture and value system that Agile brings, and the common Agile process you’re likely to see. You’ll hear about the myths of Agile and common pitfalls organizations tend to encounter. Armed with the foundations, you’ll explore some emerging UX practices and how to thrive within an agile process.

As an added incentive to attend, use the Promotion Code MYARCHIVE to receive free lifetime access to the recorded presentation. You or anyone in your organization can watch it whenever you want, as often as you want!

In advance of the presentation, we’d love to hear from you.  What are the scary stories you’ve heard about Agile?  Do you have success stories to tell about iterative development?  What hurdles would you face bringing such a discipline into the culture of your organization? Share your thoughts below.

One of the challenges of being part of a bigger solution is the need to scale the development process. And in that, we’ve seen changes in two directions: moving towards the micro level with component libraries and moving towards the macro level with frameworks.

A few weeks ago, we published an article by Nathan Curtis on the differences between patterns and components. Nathan asserted (and we agree) that patterns describe cross-application behaviors, while components are the place within an application where the behaviors and the implementation meet.

Today, we’re taking a look in the other direction. Robert Hoekman talks about the differences between patterns and frameworks. He describes how a framework is a systemic view of a specific portion of the system. To contrast with Nathan’s components, frameworks are the place where behaviors meet enterprise-wide thinking.

If you’re involved in making web-based applications a key development platform, then you’ll want to understand how frameworks will make large-scale projects that much easier. Today’s article, Web Anatomy: Introducing Interaction Design Frameworks, is a good introduction as to why that is.

Of course, this is just the tip of the iceberg. If you want to know more about frameworks, you’ll want to attend Robert’s full-day seminar, Web App Anatomy: Effective Interaction Design with Frameworks, at the UIE Web App Summit in April. And you’ll love combining it with Nathan Curtis’s seminar on patterns and components. More details on both at http://webappsummit.com

Have you started to put together frameworks? Is this something you’re exploring? Share your thoughts and comments below.

Dealing with real-life web app production isn’t as glamorous as some aspects of design in the digital realm, but it is full of challenges and can honestly make or break a project. There are ways of truly optimizing certain aspects of the production so that you can create a product with consistent quality at a faster pace. To find out how, I turned to Nathan Curtis.

Nathan Curtis is a principal and co-founder of Eight Shapes in Washington, D.C., where he is spearheading research into design patterns and component libraries. Eight Shapes turns out great work in the UX and IA realms, with some impressive clients.

In our discussion, Nathan and I first defined design pattern libraries and component libraries. A pattern library is a repository for ideas and solutions to design interaction problems. Component libraries are comprised of actual functioning parts with real code. An example would be a log-in process. Your pattern would define the experience of logging into your application, from the interaction, and often visual standpoint. Your component would be the chunk of code that represents the set of fields and controls that can be replicated across your organization’s web properties, so that you can easily create a consistent experience for your users, no matter where they may enter your system.

You can see just from this one example that if you’re designing even a moderately large site, having repositories like these can save you tremendous production time. You can multiply those savings if you have multiple teams working on different portions of the same property. Each team doesn’t need to invent their own wheels and engineer them from scratch.

We go into more detail in the podcast and also compare these to style guides, which were the first step toward this idea—one that is too often broken, over restrictive, and simply ignored. Tune in to hear how pattern and component libraries can help you avoid these traps.

Nathan will teach us much more about how to build out your own library of reusable patterns and components in a full-day seminar at our Web App Summit, coming April 2009 to Newport Beach, California. You won’t want to miss it.

Have you employed a pattern or component library in your projects? What experiences can you share? Please let us know in the comments.

During his session, Jason walked us through his thought process for several interesting design elements. He talked about the initial approaches, the problems they were trying to solve, and the path his thinking took to get to the final result. It was clear, from listening to him, that the design of these products isn’t accidental. It’s very deliberate and considered, relying on Jason’s (and the rest of his team’s) expertise and experience.

Jason admits they do very little user testing or field research. They don’t create personas to help validate their idea. Instead, they rely on the information they already have and their detail-oriented
approach to making the thousands of design decisions that go into every project.

Does this mean that every team could succeed without the traditional research techniques, relying on their own expertise and experience? That’s a question we’ve been researching for a few years now and finally have an answer: It depends.

In today’s UIEtips, “5 Design Decision Styles. What’s Yours?” I’ll walk you through the five different styles we’ve found teams use to make design decisions. I’ve outlined what each style is, the effort it takes, and how to decide when that style will work for your team.

Understanding how your team makes design decisions is critical. That’s why we’ve included it as just one piece of our new full-day Roadshow, Secrets Behind Designing Great User Experiences. This event brings together more than ten years of research into great design management. If you found today’s article interesting, you certainly want to attend one of the Roadshow workshops.

What design decision styles does your team employ? How do you decide which ones to use for any given project? Let us know your experiences below.

This week, our long time friend, Molly Holzschlag, joins us to discuss the cutting edge of web standards as they apply to web application development. Molly is the unsinkable author of a metric ton of web development books, is a noted teacher, and an in-demand consultant in the field. There’s likely no one better to ask about web standards than Molly.

There are a number of new standards that have come out recently, HTML 5 being perhaps the most notable for web applications, because it was brought forth with applications in mind. New features, like canvas, are designed to improve dynamic interactions between the presentation layer and the behavior layer, for example, with things like ECMAScript, more commonly known as JavaScript. JavaScript’s usage has really matured and become nearly indispensable as developers have really begun to exploit its full capabilities. JavaScript’s importance to front-end developers continues to grow.

In this podcast, Molly and I discussed the impact these and other advancements are having on web application design and development, along with the tremendous benefits building with standards (or even a subset of them) brings to the lifecycle of a product.

(During the episode, Molly and I touched upon the critical security exploit that effects all versions of Microsoft’s Internet Explorer for Windows. Please be careful out there, folks.)

If you found this podcast interesting, you’ll be happy to know that Molly will conduct a full-day workshop for web application developers on harnessing the power of web standards in their work at our Web App Summit in April 2009. Please join us and take your work to the next level!

We’re curious to see if any of our audience is venturing into the HTML 5 waters, or using other newish standards in their work. Won’t you let us hear your story in the comments?

Determine if this seminar is right for you and your team by reviewing  Jared’s preview, just press the green “play” arrow.

As an added incentive to attend, use the Promotion Code MYARCHIVE to receive free lifetime access to the recorded presentation. You or anyone in your organization can watch it whenever you want, as often as you want!

Register Today!

In advance of the presentation, we’d love to hear from you. How does your team currently come to consensus, and how can you be sure the right decision has been made?  What criteria is used for your decision making?  How do you get everyone on board, and how do you overcome objections?  Share your thoughts below.

What I think makes these questions magical is their diagnostic quality. From their answer, the team often know what they have to do next. So, the questions not only help us tell whether we’ll succeed or not, they help us understand where we can improve.

What are these magical questions? They deal with three important factors: vision, feedback, and culture. For a more detailed description, you’ll need to read today’s UIEtips article. There you can discover first hand whether their magic can work for you.

Read the article – The 3 Qs for Great Experience Design

How is your team dealing with the vision, feedback, and culture factors? We’d love to hear!

Because titles often don’t communicate what’s in the article, the implementation gives users a chance to see more by providing a summary as a tooltip-style pop-up.

However, it seems someone has been slacking off, because in today’s list, articles come up with the text “(no summary)”.

Three things about this jump out at me:

1. I don’t typically think of the Wall Street Journal as an organization that slacks off, so the missing summaries feel wrong to me. (Maybe this is all part of Murdock’s plan—first, eliminate the summaries, then eliminate the meaningful content? Worked for the Post. Bring on the Page 6 girl!)
2. On the development side, someone wrote a piece of code that says, in essence, “if there is no summary in the content management system, substitute the phrase ‘(no summary)’ in the tooltip.” That took more effort than just leaving it blank.
3. Similarly, on the development side, it looks like nobody put in an error message when the article is published that said, “You haven’t included a summary and that’s going to make us look silly. Want to rethink that?”

Of course, it’s unlikely that the person pressing the publish button ever goes and sees what pops up in that tooltip. (Ironically, if they’d actually published it as a synopsis that appears with the title, instead of putting it in a mouseover action, they’d see the problem right away and fix it.)

This is one of those little things that reduces the overall quality of the experience. And it’s also a great example of what happens when you spread the design contribution across different roles: developer, visual designer, and editor in this case. All three have to execute perfectly to succeed, with no checks & balances to ensure that’s actually happening.

Seems like we need to learn something from this…

Where would you send a client looking for an article on designing for different browsers and conducting browser-compatibility testing?

One of the downsides of being a researcher and never actually doing the hard work is that you don’t know the answers to the important questions. However, I know people who do. Here are the responses I got back:

Andrew Smith (@somenice):

@jmspool I would recommend http://www.quirksmode.org/dom/compatibility.html and http://browsershots.org/

@rustyspiedel

@jmspool http://www.netmechanic.com/products/Browser-Tutorial.shtml and http://www.justskins.com/design/browser-compatibility/137

Peter-Paul Koch (@ppk):

@jmspool: My quirksmode.org is one of the best resources, even though it doesn’t contain an article about the basics, just lots of facts.
This article looks promising, too: http://anthonyshort.com.au/blog/comments/how-to-get-cross-browser-compatibility-everytime/. Is only about CSS, though.

Amy Stewart (@astewart):

@jmspool check out Browsershots: http://browsershots.org/ and Position is Everything http://www.positioniseverything.net/

Thanks everyone!