In the next UIE Virtual Seminar, Rich Rutter gets you started with JQuery—assuming no prior knowledge—and shows you lots of examples, hints, and tricks. Just 5 minutes into this seminar, you’ll see JQuery in action and have something you can use in your own wireframes.

Employ Simple Show and Hide Techniques

The essence of JQuery is to find something and do something to it. This technique easily shows different page states so your team and test participants can “do things” to your design.

• See, step-by-step, how to put this simple, yet useful example of JQuery in action
• Use modules and plug-ins to make your design to do simple things, without worrying about the performance of production code

Toggle Wireframe Annotations

Add notes to your interactive design.

• Turn your comments on or off depending on who’s viewing your design
• Add lists, comments, or direction for developers and others who need to work with your design

Fake Simple Ajax Interactions

Without creating production level code, get your design to quickly and easily do its thing—click something and change occurs—for your developer or client.

• Replicate what happens when you click something like a “favorite button”
• Fill in all the steps of an Ajax interaction such as a slight delay or adding different page states on a single page

Get Started with JQuery UI Widgets

Rich will introduce a library with options and widgets that you can easily put in place. In many cases you’ll see how to simulate what the full interaction could be.

• Explore modal dialogues, an intrusive piece of interaction and a good example of something you want to test: Do I really need a modal, or is a link better?
• Get more examples: Prototyping calendars, lightboxes, and more.

Rich will show you the power of combining discreet interactions together with a complex interaction.

Regardless of your JavaScript experience, this seminar will be a great way to start using JQuery and take your interactive skills to the next level. JQuery gives us a clean, interactive feel, and can be the difference between a slick design and something annoying or disruptive. It brings rich interactivity to your HTML and CSS3.

Rich will incorporate complex interaction examples along with providing excellent sources of documentation and tutorials for your toolbox. The seminar will keep theory to the bare minimum and focus on getting you started with practical takeaways you can use straight away.

The real power in what you’ll learn is getting very close to a final look and feel of your intended design with just a bit of effort and without having to build the whole application. Get over the initial hurdle of the JQuery learning curve and gain momentum in your design process. Join us for JQuery for UX Designers.

Nathan Curtis of EightShapes uses HTML prototypes in his team’s design process. Using HTML, they test functionality and interactions in ways that are impossible while using static PDFs. During his virtual seminar, From PDFs to HTML Prototypes, Nathan discusses how his team uses dynamic documentation and design thinking. This has improved communication among the team and enhanced their process. Nathan wasn’t able to answer all the questions during the seminar. He joins Adam Churchill to address those remaining for this podcast.

Here’s an excerpt from the podcast.

“…There’s clearly start-up costs for creating an HTML prototype that are heavier than creating a wireframe PDF document. Honestly, we’ve been working with InDesign for years. As a company, we’ve got out system down for how we churn out good ideas quickly, via wireframe PDFs. And so for us to open up InDesign, open up a template, open a couple libraries, through all those things onto a screen, produce a PDF, you know, you could have a wireframe in five minutes. From just the start of a project.

But with an HTML prototype, you’ve got to set up all your folders. You’ve got to copy all of your libraries. And then you have to start marking up the semantics of your HTML to describe what the structure of your idea is. And then start layering on that CSS. And then start getting into some of the JavaScript to make those interactions happen. Suddenly, that’s not a five minute process. There’s certainly a start-up cost such that it’s almost like you’re a diesel engine.

You’re going to get out of that starting gate a little bit slower. But I’ve also sensed that, once that start-up cost has been paid, whether it’s a day of prototyping or even a four hour chunk here, a six hour chunk there. Then things start to really move quickly. That’s in part because our ability to re-use and re-factor different things becomes a lot easier. As opposed to, “Well, you want to make the header twice as large.” In HTML we just change the height from 50 pixels to 100 pixels.

But in wireframe, suddenly we’re caught going into 16 different files, having to move everything else on the page down, and all of those seemingly subtle changes end up costing a lot, too. In wireframe PDFs. So my instinct is that, yes, there is definitely a start-up cost that’s greater for HTML wireframing. But the overall cost once you start getting your engine running, and you start gaining the momentum of where the design’s going, it actually nets out…”

Listen to the podcast to hear Nathan answer these additional questions:

• Are your prototypes HTML, Flash or image maps?
• How can prototypes be successful with distributed teams?
• Do you start your designs with sketches?
• Have you ever tried to merge HTML and wireframes?
• If a designer can produce production-level code, are they more of a developer at that point?
• Do you produce production-level code in your prototypes?

Do you have experience integrating HTML into prototyping? Share your thoughts or experiences with us in our comments section.

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

Subscribe to our podcast via

Prototyping is an iterative process. You generate design concepts. You test them. You discover what works, what needs improving, and opportunities for new ideas. Then repeat. Prototyping your design will get your team and your stakeholders to talk about it. They’ll use it, touch it, walk through it at a point in time when you can make changes inexpensively.

Last year, Todd Zaki Warfel, a recognized leader in the design-research and usability fields, joined us for a UIE Virtual Seminar: A Practitioner’s Guide to Prototyping. In it, Todd explores his Eight Guiding Principles for prototyping. These principles are the foundation for more effective prototyping, regardless of the method and tool your team uses. Also, Todd’s principles are sure to test and improve your design whether you’re a seasoned prototyper or just getting your feet wet.

Todd is a Pied Piper in the user experience design world. We’ve seen it! At conferences, everyone wants to catch up with him to see what he’s doing and what he’s thinking about. He’s loaded with charisma! Oh, and he’s a pretty good designer, too. He thinks about this technique a lot, so we’re thrilled to have Todd’s UIE Virtual Seminar as part of our UIE User Experience Training Library.

Here’s an excerpt from the podcast.

“…For us, we actually use the prototypes as our specification, for the most part. Now, there are some things that you’re not going to see or that maybe won’t be self-evident in the prototypes. Some of the business rules or back-end functionality may not really be clear in the prototype.

What we found, and this is actually one of the reasons why we turned to prototyping and away from an older, traditional method of wire frames with written specification documents. What we found is that, since the prototype, basically, is show and tell and allows you to see the story as well as tell the story and actually play around with the systems, it’s much more tangible. When we do prototyping, we find that actually, any specifications that have to be written are dramatically reduced.

So, for example, in my book there is a case study from a gentleman over in the UK and their old, traditional system was: do some wire frames, write a 200-page specification document and deliver it out to the development team. And they shifted over to using more of a prototyping model. And for similar systems that they used to have to write a 200-page spec document, they found themselves delivering the designs, with specifications, about three times as fast and that the specifications went down to 20 pages instead of 200.

And so they’re essentially using the prototype as the bulk of the specification and then writing some supplemental documentation to describe things that aren’t self-evident, like back-end business rules and maybe some technology-type stuff. And we’ve done a very similar approach.

So, a lot of times, what we’ll do is prototype out maybe a core flow, plus maybe some error sessions and maybe some success screens and that type of a thing. But, we won’t typically prototype out every single scenario. We’ll kind of do the 80-20 rule. So, here’s 80 percent of it prototyped out. You can pretty much see how it works. And then any additional, supplemental information that may not be self-evident in the prototype, we’ll either write some documentation, or in a lot of cases actually, our clients just take the prototype and then their internal team basically writes that spec…”

If you thought that was interesting, you’ll also hear Todd address these questions:

• If you’re prototyping only some of the functionality, how do you talk about the rest of the functionality that isn’t in the prototype such that the team knows how to fill in the gaps?
• How are you able to do usability testing when the prototypes are not refined, or they’re missing pieces?
• We often talk about how prototyping lets you reduce risks, but does it give you an opportunity to actually take risks?
• Do the prototypes have to be made with the same technology that you’re going to use in your production system, or are there actually advantages to doing them in something completely different?

If you have any questions or thoughts on prototyping, please feel free to share them in the comments section below.

Subscribe to our podcast via

Kim Goodwin

Scenarios are comprehensive stories that describe how a persona interacts with your product or service. They are a powerful design tool that allows you to make intelligent design decisions based on your user research.

If there is a grand dutchess of personas, scenarios, and design processes, it’s Kim Goodwin. That’s why we asked Kim to do a workshop on turning user research into action at UI15. In this podcast, Jared Spool spoke with her about that workshop and some common myths surrounding scenarios.

Jared suggests that scenarios have grown out of necessity. Requirement documentation simply doesn’t cut it when starting the design process. Beyond what’s “needed”, you need user research. Kim says that requirements are flawed without user input.

“Let’s all start from a shared understanding of our users.”

Two common misunderstandings about scenarios involve their relationship to Agile processes. It’s easy to believe that Agile and scenarios are not compatible. If you have your designers and developers sitting down together on day one, you can’t have part of the work done ahead, right? Kim asks, why not? Placing research and scenarios in front of your designers and developers gives them a great starting point.

Some people confuse Agile’s user stories with scenarios. They are not the same, but they are compatible. Scenarios are all encompassing. One of their strengths is that they can span your company’s silos. A customer doesn’t see you as a series of departments, they see you as one brand. Within an Agile environment, your web team will not likely be designing both a web feature and a physical retail procedure simultaneously. Therefore, you can carve out the relevant bits of the scenario to create your user story for your current sprint.

“How hard is it for a three-year-old to make up a story? Storytelling is such a natural human tool… it’s really very easy.”

One complaint about scenarios is that they take too long to create. But Kim reports she uses them on even the smallest projects with tight schedules. Even if it’s just one afternoon with a few key stakeholders, she puts a lot of value in building shared assumptions about who the users are.

There is more ground covered in the interview. Listen to the podcast or read the transcript for more scenario mythbusting. Kim, who is a masterful teacher, also describes what she has in store for her full-day scenario workshop at User Interface 15, “Designing with Scenarios: Putting Personas to Work”

Explore Kim’s workshop and the full conference program. Register for UI15 by October 19 with promotion code BLOGPOST and get $400 off.

As we were talking, I had suggested that a UX Design Library was a snapshot of what the team felt the future of the design would be like. “Oh, no,” Nathan exclaimed! “I strongly disagree with that idea.” He went on to say that the library really was a snapshot of the past, not the future. A great library represents the best and most promising pieces of the design, so that future work could take advantage of what can be done.

Creating a library that works for the team isn’t technically challenging. However, there are important considerations and steps that the team needs to make sure it’s a success.

In today’s UIEtips, Nathan walks us through the process of creating a library. He’s broken it down into four doable steps (and even has a fabulous poster-grade visualization of the process). You’re really going to enjoy his article.

Read Nathan’s article, How to Create a UX Design Library.

One of the best things about my job is that I get to talk with Nathan on a regular basis. Every conversation we have is eye opening and amazing. You can have that same opportunity when you sign up for the UI15 conference. Nathan will deliver his fabulous full-day workshop, Standards, Reuse, Consistency, & Libraries, where you’ll learn how to capture the best of your work for the future. Read more about the workshops.

Have you put together your own library? How did it go? We’d love to hear about your experiences below.

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

It’s no surprise why. After all, content is the substance that draws and keeps the users at the site. It’s what sells our products, describes our services, and provides our support. And it’s what teams struggle with the most.

When you break it down, the elements behind content strategy, such as information architecture, copywriting, search engine optimization, and content management, are not new. But they’ve never been combined into a strategy before, where teams can plan and execute the necessary activities to keeping great content up-to-date and working for the user.

In today’s UIEtips, you can read a great article Kristina wrote on just this topic, The Discipline of Content Strategy. It’s a fabulous introduction to what content strategy is and how you can start to make it work for you. I know you’ll enjoy it.

Read the article, The Discipline of Content Strategy.

We’re thrilled to have Kristina tell us all about Content Strategy in her upcoming June 3 UIE Virtual Seminar, Content Strategy: Maximizing a Business Asset. I can tell you, from first-hand experience, you’ll be just as inspired as everyone else to employ a sound strategy and get your content under control. Kristina will show you how.

Are you struggling with keeping your content under control? What have you tried? Share your content strategy experiences below.

Luke Wroblewski did a great job capturing the essence of Jason’s presentation, Backstage at 37signals. In addition to Jason’s session, he also blogged many of the other Masters’ presentations in Minneapolis. You can read these posts on his site, LukeW.com.

Now, on to Luke’s post.

At the UIE Web App Masters Tour in Minneapolis MN, 37signals founder, Jason Fried described how 37signals solves design problems and collaborates by showing four days worth of chat transcripts about an ongoing redesign project at the company.

• The overview screen in the 37signals application Basecamp has been around for four years. 37signals tried to redesign it once and got a lot of pushback from their users, so they pulled back. That was quite uncharacteristic for them, so Jason hopes they never need to do that again.
• Before deciding to redesign the Basecamp overview screen, 37signals gathered feedback from a survey over a couple months. In the survey, people said they do not have a good feel for what is going on in their projects. When looking at customer surveys, 37signals does not implement product ideas from users but instead tries to get an understanding of the problems people are having.
• The current Basecamp overview page is a listing of what happened on a project per day. Everything is organized by day: to-dos, comments, files upload, etc. It’s all useful data but it is hard to get a sense of what happened in a summary view. Things are grouped by time and not type. This was the impetus for the redesign and all the direction the team was given to get started.

Insights from the 37signals Process

• 37signals does not use documentation, schematics, or traditional user testing. They try to design the real thing right away and iterate until they get what they want.
• It’s important for a manager or creative director to know what is important at any given time. Up front, you need to provide feedback on the big picture not on the details. Once you are going in the right direction, then it is time to focus on the details.
• It’s very easy to get stuck on things that don’t matter. Don’t do it. Try to get the big picture ideas in place first then work through the rest.
• Instead of talking too much about feedback, one of the best ways to respond to a design is with another design. This response could just be a simple sketch. Working back and forth with pictures helps to remove misinterpretation. If you spend too much time talking about something, you need an image to ground the conversation.
• When you redesign something, you don’t have to change everything. What is the least amount you can change in a design to have the biggest effective difference? Look for small but impactful changes.
• Typically, 37signals does not try to change 15-20 things at once. They make one change and upload a new screen shot to discuss. This allows them to control everything but the one thing they are changing. When you make multiple changes at a time, it is hard to see what worked and what didn’t. Better to go one thing at a time. When people go away for a week and work on stuff that does not matter, that’s time lost.
• Don’t base the design on something you can’t do. If you can’t build something now –remove it from the design.
• Always try to use real information in your designs. Use real numbers, data, and names so you can think through the way a design will support actual content. A variety of data can help work through potential issues.
• At first you are in the excited phase with a new design. But then you get used to it and start to look at it critically again. This is ok –it helps bring up additional issues.
  If you build things for other people, you are judging everything by proxy. “will other people like this?”. Solving your own problems allows you to effectively judge them. Design for yourself if you can.
• 37signals prefers to kick off projects with loose requirements because they are not smart enough to know exactly how things will go. Allowing the project to evolve yields more insights as things progress.
• 37signals currently has 3 teams: 2 programmers, 1 designer. Each team breaks up and reforms every two months. They always divide work into two week increments. Even big initiatives can be broken down into smaller tasks.

Jason Fried is just one of the Masters at the upcoming Web App Masters Tour in Philadelphia and Seattle. Learn more about the Tour program and dates at www.UIETour.com.

Until May 11, register for Philadelphia or Seattle and get $100 off when you use the promotion code TOURBLOG. Learn more about the tour at www.UIETour.com

Subscribe to our podcast via

Bill Scott

If you’re using advanced, or “rich” interactions in your web applications, then it’s likely you have Bill Scott and Theresa Neil’s Designing Web Interfaces on your desk, if not your bedstand. Published in 2009, it is perhaps the definitive tome on rich interactive design patterns for the web. Bill has dedicated a significant portion of his career to dissecting such interactions, creating the Rico JavaScript library, curating the Yahoo! Pattern Library and now overseeing UI engineering at Netflix—one of the first companies you think of when you think of Ajax-y web interfaces.

It’s hard for us to picture talking about web apps without talking about Bill and his research into design patterns. His new book is full of examples where he slows down time to explore each micro-stage of an interaction. Our Jared Spool got together with Bill to discuss his ideas about the nuances of Interesting Moments.

Jared and Bill discussed,

• Bill’s experience of aggregating successful interactions in the Rico JavaScript and Yahoo Patterns Libraries
• How his challenges at work lead to him writing Designing Web Interfaces
• How his interface research lead to better ways to capture interactions for documents and prototypes.
• Dancing Hamsters
• …and more

Bill speaks about both patterns—successful interaction models for common interactions—and anti-patterns. By showing what not to do, anti-patterns often provide insight on the right way to do something.

A good example [of an anti-pattern is from] the old Yahoo Photos site[…] dragging several photos into an album, there’s no indication that the photos actually dropped into the album folder, and there’s no feedback that says, “Oh, there was three, but now there’s six items in the folder.”

The designers had dropped in two extra “idiot boxes”, which is a great anti-pattern. The first idiot box says, “Do you really want me to drop these items into the folder that you so carefully managed to use your mouse dexterity to get to?” Not quite that message, but that’s gist of it.

Then there’s another pop-up that says, “Hey! Guess what? We did what we said we would do. We actually put those items in the folder.” It’s sort of, as Alan Cooper calls it, “stopping the proceedings with idiocy.” The missed moments were just those little, subtle feedbacks that could have been done, instead of the hammer approach, by having those boxes pop up and interrupt the user.

The take away for our work is that this interaction was backwards. It gave no indication that you were doing something successfully while you were doing it, and then penalized your time after completion with dialog boxes to confirm your success: “You did it!” After dismissing the dialog, you were left with an interface that didn’t reflect any of your changes.

By adding clues that the move was happening during the action, and then reflecting the changes with interface cues afterwards, we can make the experience smoother while avoiding “idiot boxes” altogether. (This interaction is detailed in chapter 5, “Overlays” of Designing Web Interfaces)

There are many more pearls of Bill’s wisdom available in the podcast, please tune in!

Don’t miss Bill’s full presentation, “Designing for Interesting Moments“, at our Web App Masters Tour. He’ll be with us in San Diego, Minneapolis, Philadelphia and Seattle.

Let us hear your questions about interesting moments in the comments below…

We discovered a variety of ways to create personas — each valuable in their own right. With our clients, we’ve been using a field-research-based technique. This method creates robust, data-based persona characters and scenarios.

Tamara Adlin has a fabulous workshop technique, one she calls Ad-Hoc Personas, which builds the characters out of information that the organization already knows.

Steve Mulder has some great techniques for using analytics and market research to gather and validate persona characteristics.

From our research, we’ve found all of these are useful methods and, when done well, deliver value.

When we analyzed the results, the initial findings show teams that approach personas the right way get great benefits from them. Unfortunately, many teams don’t realize what makes a persona project successful. They focus on the wrong aspects, dooming their project
to failure.

In this issue of UIEtips, I share the essence of successful persona projects — the key factors teams should understand. It turns out that once you know the right way to approach the project, it’s straightforward to make it successful.

Read the article, The Essence of a Successful Persona Project.

In the article, I talk about how impressed we are with Tamara Adlin’s Ad-Hoc Personas technique. We think this is an essential tool for getting everyone in the organization on the same page. Don’t miss the UIE Virtual Seminar on Thursday, February18, where Tamara walks us through the method. Read all about it.

Have you been successful at creating and using personas in your design work? Which factors do you think helped the most? Share your thoughts below.

Subscribe to our podcast via

Our audience clearly embraced Fred Beecher’s recent Virtual Seminar on prototyping, The Whys, Whats and Hows of Prototyping, because we were nearly buried under all the thoughtful questions we received. It’s clear people are looking for more effective and efficient ways of working through their design ideas. Our Adam Churchill got together with Fred after the seminar to go through the pile and deliver more answers for you.

During the podcast, Adam asked Fred to explore these questions, and more:

• Can you tell us how design differs from prototyping, and where
  elements like visual design and wireframing fit in?
• Does prototyping require organizational change? Anything you
  recommend when working with others in the organization that aren’t
  members of the design team?
• What are the best methods and tools for online testing?
• What recommendations do you have for collaboration when working with
  people in different locations, and possibly at different skill levels?
• Which prototyping tools do you recommend, and how do they differ, from low fidelity to high fidelity?

I know you’re going to enjoy this episode because I couldn’t get through editing the audio without pausing to look up some of the resources Fred suggests.

Do you still have prototyping questions? Ask them in the comments below.

Subscribe to our podcast via

Todd Zaki Warfel has just finished two years of research into the tools and processes used in prototyping web sites. His findings will be published in a book due out this fall and we’ve asked him to give a full-day workshop on the topic at UI14. Did you know some people are actually building prototypes in Microsoft Excel? It’s true. “People are using what they have at their disposal and what they are comfortable with,” Todd tells me.

In the podcast, we discussed a number of the more popular tools that are being used today, from Adobe Fireworks, to Axure RP, to good old PowerPoint. Todd doesn’t think your choice of tool is important if you are able to communicate your ideas effectively to your audience. He thinks it is worth knowing the capabilities of a few other tools in the event you need to do something in the future that your current tool can’t handle.

I got Todd to reveal the process his own shop, Messagefirst, is using to prototype. It may surprise you that they start with rough, black and white sketches which they share with their clients both early and often. Whereas some design shops may work hard on a prototype for three months before first showing it to their client, Todd thinks that’s a bad idea. There’s nothing worse than diving deep into a design direction only to have it unilaterally shot down in the first review.

Instead, you need to get your client to give you lots of feedback very early in the process, starting with basic and rough sketches. It will save both sides a lot of time, effort and frustration. Once the design direction is solidified, Todd and his team move their prototypes into color and interactivity. The Messagefirst crew is now often jumping straight to HTML, CSS and JavaScript for the higher fidelity mockups.

Todd tells us that someone with basic HTML skills can (and have) learned to create high fidelity prototypes in just a couple weeks of effort. The secret is the availability modular tools, for example, CSS frameworks like the 960 Grid System and JavaScript libraries like jQuery. This move to code earlier in the process is becoming more and more popular around the web.

Todd and I talked more about his two years’ worth of findings and he gave us a preview of his UI14 full-day workshop. Tune in to the show for more on prototyping.

We’d love to know what process and tools you’re using in your own designs. Have you incorporated feedback early into your process? Let us know in the comments!

Take that two-way communication out of your process, and the design that emerges from the development process doesn’t work the way we thought it would.  You increase your development costs, and deliver a product that’s lost all of it’s interactive goodness.

Unless you’re doing your own implementation, practically impossible for a serious production application, you need to find a way to succinctly communicate what’s important and how it should all work. In this week’s issue of UIEtips, I bring back an article, Getting the Most from Design Deliverables, that discusses how the best design teams go about successfully communicating their ideas to the development team. I think you’ll really enjoy it.

Also, we think this article ties in nicely with our upcoming UIE Virtual Seminar: Comps vs. Code: Case Studies on Collaboration Between Site Designers & Developers with Ethan Marcotte.  On July 30, Ethan will use four case studies to teach some insightful lessons about the collaboration between designer and developer. See a preview.

How do you hand off projects at the transition phases in your organization? What types of reviews do you build into the transitions?  Join the discussion 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.

In part 2, we have new topics to muse over. Are you building out a web 2.0 strategy? Having trouble communicating and documenting the design process? How do you tie the visions of company culture and customer experience together?

We answer these burning questions and others with four more podcasts in the final part of this series. Here I focus on the following experts:

• Steve Mulder and Riccardo LaRosa on Web 2.0 Strategy and Design 
• Dan Brown on Documenting Design
• Brian Kalma on melding Zappos’ company culture with their customer experience
• Robert Hoekman on introducing design frameworks

So lets get started with this week’s podcasts.

Web 2.0 Strategy and Design with Steve Mulder and Riccardo LaRosa

When creating a web 2.0 strategy, you start thinking about what features to build, how to tell if the features are working as expected, and how results change over time. We brought these considersations to two of our favorite people when it comes to Web2.0 Strategy; Steve Mulder and Riccardo LaRosa

In this podcast, Steve and Riccardo focus on these issues and bring some great case study examples from Reebok and HumanaOne to life. We also talk about how starting small and iterating is most successful,but not an easy sell in many situations. You’ll want to listen to how they overcame this challenge and other Web 2.0 adventures they had.

Read more detail on Steve and Riccardo’s interview.

Documenting Design with Dan Brown

In this interview, Dan and I explore the documents that help make large design projects go smoothly. We discuss how these important docs can become living documents (ones that evolve when necessary) and how Dan believes there’s value in seeing them as actual team members. This may sound odd, but Dan nicely clarifies what he means in the podcast.  

During the podcast, we spent some time with two types of documents: concept models and flow charts. These particular documents are intriguing because they don’t cover concrete ideas (which are easier to document), but instead cover the higher-level abstract ideas that often power the site invisibly.

Read more detail on Dan’s interview.  

Company Culture Meets Customer Experience with Brian Kalma

Looking for ways to tie your company culture and customer experience together? Then you definitely want to hear this interview with Brian Kalma of Zappos. I reached out to Brian to find out how Zappos, a company that conducted over a billion dollars in online sales last year, brings together their web site, call center, and social media outreach, to create a unique customer experience.

Brian discusses Zappos’ four-week training program that everyone must go through within the company; how the entire company (over 1300 is part of his design team; and how Twitter and Facebook has empowered their employees to communicate with customers.

Read more detail on Brian’s interview. 

Introducing Interaction Design with Frameworks, with Robert Hoekman

So what are design frameworks anyway? Drawn loosely from the idea of coding frameworks that software developers use to more efficiently build software, design frameworks are an aid to assembling a design.

In this podcast, Robert Hoekman joins us to discuss design frameworks. You can compare frameworks to design patterns, although patterns tend to be smaller, more specific solutions. Frameworks, when built out, can contain design patterns. 

Frameworks help create consistency in interface elements to help solidify the UX. Robert uses frameworks on all his current projects. He starts out with a check list of all the main elements what will help a person accomplish a goal.

Read more detail on Robert’s interview.  

Podcast Library

The Web App Expert podcast interview series is just a small taste of the podcasts we offer. Look for our ongoing podcast show - Userability, where folks like you call in with their UX issues of the day. And we have many other podcasts on a smattering of topics from various experts.

Creating a Great User Experience at Your Organization

Brian Kalma’s podcast is all about creating a great user experience at Zappos. It’s exactly what we’re going to talk about at the UIE Roadshow: Secrets Behind Designing Great User Experiences, except we’ll be focusing on how to create a great user experience at YOUR organization. We’ll be in Seattle, Denver and Washington, DC at the end of June. Explore the program and be sure to use the promotion code SHOW09 when you register for a $75 discount off the individual price.

Enjoy the podcasts.

But, at some point, we need to check to see if we’re going in the right direction. Are we creating what we are striving for? Is what we want actually buildable?

Our research shows that teams that don’t take time to ask and answer these questions get themselves into trouble downstream. They come to the end of the project with something that isn’t fitting together and not meeting the users or businesses’ needs.

In today’s UIEtips, I talk about a simple trick we discovered when we were out researching in the field. It’s called hunkering and it provides designers a check-and-balance system for ensuring the design they’re creating turns out great. I think you’ll find the article, Hunkering: Putting Disorientation into the Design Process, interesting.

In just a few weeks, the UIE Web App Summit will start, showcasing some of today’s most effective techniques for designing web-based applications. You’ll want to catch great full-day workshops, such as Dan Brown’s Communicating Design: Essential Deliverables for Highly Effective Design Teams or James Box and Richard Rutter’s Wireframing and Prototyping for Highly Interactive Web Apps. Read about all the amazing sessions.

Do you have your own hunkering tricks? Do you have other techniques for staying in touch with your design ideas? Share your methods below.

Unfortunately, we can’t always communicate our design ideas that way. We’re not always in the same room, in front of the design. Sometimes we have to communicate through documents. Sometimes, we need our thoughts to last beyond the ephemeral moment of speech.

That’s where annotations come in. Annotations are critically important to our design process, since they help us augment the work product to communicate things that aren’t readily apparent in the diagram itself.

Yet we almost never talk about them. Is there a right way to do them? Are there ways to do them better?

For today’s UIEtips, I had a chance to sit down with Dan Brown, co-Founder and co-Principal of EightShapes. Dan wrote the fabulous book, Communicating Design, and he’s given a ton of thought to the best ways we can get our design ideas out to the team, so they have them when they’re making important decisions. Read Dan’s interview.

It’s no surprise that Dan’s full-day workshop, Communicating Design: Essential Deliverables for Highly Effective Teams, is one of the most popular at the upcoming UIE Web App Summit. More than ever, teams need every tool they can get to be effective and Dan’s toolbox is the envy of us all. Find out more about his workshop and other great sessions.

Have you developed your own techniques for annotating your work deliverables? Let us know your tips and tricks below.

Subscribe to our podcast via

Without planning, web apps have no where to go. Planning documents for web app projects are often overlooked, despite their importance in the success of the product. As a designer, no matter how great your research is, or how amazing your programmers are, if your planning documents do not develop well, your project will fail.

One of the great user experience success stories in the U.K. is the Brighton-based agency Clearleft. They’ve developed successful, sophisticated methods of planning for their projects. I was able to get a hold of two of their talented crew to discuss those methods in this episode of the SpoolCast.

James Box (UX) and Richard Rutter (Co-founder and Production Director) have been working on ways to plan highly interactive web apps that make the process more efficient. And that’s exactly what we spoke about during the podcast.

James and Richard first told me that they hold back from traditional deliverables, and show clients what they call ‘design tools.’ Some clients prefer tidy deliverables, but many clients like these rougher documents. The advantage to these is that they stress design as a process, rather than set in stone. Sometimes overly polished documents can make a solution appear complete, without the client being able to change its course.

This method aids the flow of dialog between the designers and the client. Rough prototypes help your client stay focused on the core issues you’re demonstrating, like interactions, while avoiding getting caught up on visual elements that aren’t important at this very moment. As an example, when possible, they leave color out altogether.

A key element to the success of their design tools is that prototypes are interactive. They make many prototypes with HTML and enough jQuery to demonstrate the interaction. They don’t feel this process takes any longer than using relatively static tools like Visio or OmniGraffle, and offers more utility. They’re always looking for ways to improve the process with reusable pattern and code libraries.

There were more quality nuggets in the conversation too, so please tune in for more on peer reviewing, prioritizing usability testing and real code production.

James and Richard will be joining us in California this April for our Web App Summit, where they will be conducting a full-day workshop on “Wireframing and Prototyping for Highly Interactive Web Apps.” If you enjoyed this conversation, please join us to learn how their techniques can help in your organization.

Have you moved to interactive prototyping for expressing complex situations? Let us know in the comments.

When we think of a team that communicates, the first things that comes to mind are hallway conversations, meetings, and emails. But, as our research continues to show, are only a part of the communication puzzle.

It turns out that one of the differences between the successful teams and the struggling teams is their use of diagrams and maps. Struggling teams almost always try to communicate important design ideas through talking or word-based documents, while the successful teams put a heavy emphasis on diagrams.

Often times, these diagrams become living documents — things the team revisits and updates frequently. And it’s the process of discussing and modifying that makes the inherent design concepts clear.

In today’s article, In Which a Concept Model Makes Me Giddy, Dan Brown shares with us one of his favorite diagramming tools: The Concept Map. Dan, who wrote the now classic book, Communicating Design: Developing Web Site Documentation for Design and Planning, recommends concept maps to help team members visualize the relationships between a design’s components and the people who use it. Whether you are new to concept maps or have been using them in your work for a while, I think you’ll find Dan’s thinking behind them as fascinating as I do.

I’m really excited about Dan’s full-day seminar at the UIE Web App Summit. His session, Communicating Design: Essential Deliverables for Highly Effective Design Teams, is sure to be one of the audience favorites. You don’t want to miss this hit session.

Have you tried concept maps for your team? Have you discovered ways to communicate through diagrams? Share your experiences with us below.

Growing documents

Brown begins by suggesting that designers start documents with a basic nucleus of necessary information then adding detail in layers. He also put forward the idea that ideal documentation should be able to give a bird’s eye view and address the road-level details that developers and quality analysts need.

It seems to me that multiple documents become the best approach to meeting this ideal of providing the bird’s eye view and road level detail. In past work I’ve tended to use site maps or high level flow diagrams to give the high level information then use wireframes or lo-fi prototypes to get into the road level detail. (There is also need for technical documentation of both bird’s eye and road level detail but these tend to fall to the Front End and Back End team leads.)

Read Brian’s thoughts on the interview.

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.

Fast forward three years and today we get a comment from Tessie asking:

I am currently designing a pattern library for my company. Can you recommend any pattern library systems which we can purchase which is easy to update and features a commenting system?

I didn’t know the answer, so I pinged Nathan Curtis, who is our go-to-guy on building pattern libraries these days. Here’s what he wrote back:

Good question. In my experience, I’ve not come across a pre-fab application for documenting patterns, components, or other libraries of reusable design assets that have the types of attributes (e.g., Use When) and other specific features. Instead, I’ve seen that teams have gone one of four routes to publish library documentation:

1. Home-grown systems: This is expensive and time-consuming, but ultimately the most advanced and tailored solution for an organization. Yahoo has written (on boxesandarrows.com) and subsequently spoken extensively about the challenges and roadmap they’ve traversed. Sun Microsystems has also use a custom website as the cornerstone of their efforts; lucky for us, they expose it to the community too at sun.com/webdesign/.
2. Collaboration tools: One team effectively used Jive Software’s Clearspace tool that includes a well suited three-prong feature set: wiki (articles per pattern & component, including editing permissions for team & individual, commenting and ratings), discussion boards (new requests, general discussions), and blog (publish ongoing notifications and articles about the overall library).
3. Basic tools: Other teams have set up a wiki or tried to transform a basic collaborative tool to publish patterns. This may be a good short term fix, but isn’t really a tenable long term solution unless you can really start to customize it.
4. Documents: For better or worse, some teams don’t have access to web-based solutions for publishing a library, and this really hamstrings their efforts. That said, they’ve gone to great lengths to compose documents (like a “Component Guide”, “User Experience Guide”, or “Pattern Library”) that become a versioned document managed over time. Additionally, with a modular documentation system, they can architect their guides in such a way that pages can be linked to project-specific documents as appendices or even key pages to scale changes or overlay annotations.

Hope this helps!

I think it does! What do you think?

[You may have heard: Nathan will be presenting his full-day workshop, Achieving Reuse with Patterns and Libraries at the UIE Web App Summit. Check it out!]

Over at Semantic Foundry, designer extraordinaire, Will Evans, has a wonderful essay explaining how he uses wireframing as both a problem setting and a problem solving approach.

I pick my primary audience and the one activity which allows them to solve one goal quickly, effortlessly, elegantly. In this case, the primary audience wants to easily find the best cruise, at the right time, for the right price. I don’t even look at the requirements document or competitive analysis until after I have sketched a couple of ideas either on paper or using Omnigraffle, which explores the primary goal. I’m not looking for solutions at this point because the first round of wireframes provide a space to engage in a dialogue with other designers, stakeholders, and the wireframes themselves.

It’s a great description of how Will tackles a design and he’s provided his work products for you to download.

Read Will’s essay: Shades of Gray: Wireframes as Thinking Device