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.)

These experts will dive deep and get to the nitty-gritty details that make any designer a UX pro. Look at the intensive full-day workshops we’re putting together for you.

• Brandon Schauer: Immerse your team in an innovative design process that produces refined design ideas in record time.
• Kevin Hoffman: Facilitate productive and insightful kickoff workshops to start your projects with everything you need.
• Hagan Rivers: Employ best practices to simplify your most complex applications with state-of-the-art UI techniques.
• Steve Portigal: Drive your design with effective field research to deliver innovative results.
• Bill Scott: Discover the latest rich interaction techniques for engaging user experiences.
• Kim Goodwin: Compose compelling stories that drive a realistic design process from start to finish.
• Stephanie Sullivan Rewis and Greg Rewis: Enhance your designs with HTML5 and CSS3 without sacrificing your design goals.
• Luke Wroblewski: Integrate mobile design’s best practices and techniques into your process.

Get more information on the workshop topics and speakers at UICONF.com.

Details on the Sneak Preview Site

In the next few weeks, more details about the agenda and workshop will emerge. However, you can get a view into our special sneak preview site now.

And because the site is in the sneak preview mode, we’re offering a sneak preview price – our lowest price, of $1,349.

On Wednesday, July 27 at 1:00 pm, registration will open.

There are 100 spots available at the special low price of $1,349. Once they are gone, they are gone and you’ll have to buy one of the more expensive spots.

There is a way to get a jump start on registration, and learn about exclusive offers and the latest UI16 news. Add your email to the UI16 list at UICONF.com and you’ll automatically get added to the priority group.

Now go see the 8 different design workshops we have in store for you at UICONF.com.

“Hi. I’m a designer at [a big deal company] and I’m considering leaving. The problem I have is my employer has made it very clear I can’t use anything I’ve done here in my portfolio. What should I do?”

The work product lockdown is something many designers face, as they grow their careers and try out new opportunities. It’s natural that prospective future employers will want to see what you’ve done. It’s hard to show them when your designs, sketches, and deliverables are locked up behind a corporate non-disclosure agreement.

In future posts, I’m planning on talking about what people can show in their portfolio if they don’t have work products available (or even if they do), and what the best hiring managers look for when reviewing a portfolio.

However, today I want to talk about this from a different angle: Making it part of the hiring agreement.

I think every designer (especially every experienced, senior designer) considering a job at a new organization should ask explicitly about the hiring organization’s policy on including the work in future portfolios. Their answer should be on the table and negotiated, just like salary and benefits.

When should you ask?

In any hiring process, there’s two stages: The first stage is when you, as the candidate, get the hiring manager and company to fall in love with you. It’s all about showing what you can do and how you’ll help them achieve their goals for the position. You’re goal in this stage is to get the company to think you’re the most awesome person ever for their position and they should jump through every hoop to get you on board.

The second stage is when the company gets you to fall in love with them. Their goal in this stage is to prove to you that they are the best place ever.

It’s in the second stage that we can talk about the portfolio, between when they fall in love with you and when you are deciding the job is the right next step. It’s quite within the rules to say, “What’s your policy on employees including screen shots, sketches, and other work deliverables in their portfolio?”

The hiring manager may not know. It may be something they’ll have to ask HR or even the legal office about. At small companies, they have never even considered the question because you’re the first to ask.

However, it’s a really fair question. And, frankly, any answer is a fair answer.

They might say they want to protect their designs from getting in the hands of the competitors. Therefore their policy is to refuse permission to publish work (especially unreleased design work).

Public companies, who have trouble when future plans are leaked, thereby creating a possibility of “insider information” getting out, are very likely to refuse this without including a Safe Harbor statement. (A safe harbor statement basically says that investors shouldn’t use the information as any indication that the company intends to do anything with it.)

Or they might say they have no problem with you putting the documents into your portfolio, but they’d prefer that you don’t put it in a publicly accessible place, like a web site that anyone can get to. They might like you to only show it to people on an as needed basis, asking those individuals to not share it beyond their own team.

Ideally, they come back and say it’s perfectly fine. There’s not reason you can’t take your work with you as you grown your career. (After all, they benefited from your previous employer’s generosity in this matter. Pay it forward.)

Any of these answers are ok. The point isn’t that you badger them into heading in a direction that they aren’t comfortable with. The point is they tell you, up front, before you take the job.

Once you know, you can decide if this is a deal breaker or not. The fact that you asked tells the hiring manager that it’s an important detail to you. That you’re thinking about your long-term career.

(Of course, one argument is that it sends a message that you’re thinking about leaving the company even before you got the job. Personally, I think that’s ok. In this day and age, we don’t expect life time employees. Any company in denial of that fact may not be the kind of place we want to work. It’s good for an employer to realize that each employee has a choice to stay or go.)

As a discipline, our goal is to bring awareness to the hiring companies. To let them know that this issue is an important one for many professionals.

We’ll know we’ve succeeded when hiring companies start putting their openness to including work products in portfolios into their recruiting ads. When they cite unlocked work products as a benefit of choosing them to work there, we’ve arrived.

Then, someday, this will disappear as an issue, as it becomes part of the standard way we all do business.

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.

Our deliverables need good design. They perform a function, just like the work they’re describing. They either do their job well, or they miss the boat. Nobody wants to have their great ideas submerged into obscurity because the deliverables didn’t do their job.

In this week’s UIEtips, our good friend Dan Brown shares some wisdom about well-designed deliverables: they have to tell a story. Theme, journey, conflict, and characters — pieces that keep us riveted to that page turner — are all essential in great deliverables. I’m sure you’ll find several great ideas on how to make your own deliverables that much better.

Read the article, What Makes a Good Deliverable.

By the way, did you know we’ve teamed up with Dan’s company, EightShapes, to bring you a fabulous series of virtual seminars this winter. The first one, 5 Simple Principles to Improve Your Information Architecture, is next week and I’m really looking forward to it. Dan’s packed some great wisdom into it — stuff you shouldn’t miss. Read all the details.

How have you integrated story elements into your deliverables? We’d love to hear what’s worked and what hasn’t. Leave your thoughts 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

How can we design systems that encourage the behaviors we want?

One of the bleeding edge ideas we’ll be talking about at the UIE Web App Masters Tour is adding motivation to web applications. How do you encourage user behavior through the design of your web app? It may initially sound a bit far-fetched, but there’s an industry that’s been shaping its customers’ behavior since the beginning: the gaming industry.

Stephen Anderson

Stephen Anderson is a consultant and a thought leader on the idea of motivating user behavior through design. He and Jared Spool sat down sat down for a discussion as part of our series of interviews with the Web App Masters.

Stephen’s developing a deck of cards to aid designers in brainstorming their designs, with consideration to behavioral cues. He calls them Mental Notes Stephen says,

“We focus on things like visual design, usability, or the information architecture and we forget about, ‘Oh yeah, there was that thing about gifting or curiosity or the peak-end rule.’ This is really a way to apply intention, or a way to intentionally remind people to use some of these, or try to leverage these.

These are ideas about human behavior and how humans respond to different ideas or different stimulus. So my idea is why aren’t we applying these to web design? We’re applying them to marketing, to retail, to interpersonal relationships, and to dating.

A lot of these ideas are nothing new, but I think we’re just now reaching the point where we’re thinking more consciously about how can I apply something like recognition over recall to web design?”

Stephen also gets into how we can use these persuasive or seductive ideas into shaping the initial engagement a web app has with its user.

“Attention is so scarce today that people spend 30 seconds on something, and they might not see the value or see why it could be useful to them in those 30 seconds. So my focus started shifting from the product itself to that initial engagement, that initial interaction, and how do we make that first experience a lot more seductive, so people stick around long enough to see that you really do have something worthwhile here?

Going back to real world analogies, think about if you were doing those not with a system online, but with a human. The human could be very straightforward, very to-the-point, in asking the questions, or that human could be very personable, and maybe crack a joke, or ask you how you are doing, do these things to be more personable. …why can’t these systems adopt some of those similar ideas?”

Stephen mentioned an internal corporate knowledge-sharing web app that he was involved with. The company used a lot of game-type incentives to encourage employee participation, but many of the most successful attributes are some of the most counter-intuitive. For example, to add content to some pages, employees had to “pay”. And this encouraged participation. They paid with points they accumulated doing other tasks within the system, like answering co-workers’ questions. Employees would attempt to answer the questions first so they could gain points before someone else beat them to it.

“…they described, in very qualitative ways, how you earn karma (“points” in this example) and how you get better at this game or this system. But they were not explicit with what activities you do and how many points you get for each. And I think that was very smart.”

We appear to be at the very cusp of adding psychology and a touch of gaming into web apps. From the friendly copy tone on Flickr to the full-on game strategy employed in Stephen’s example, it’s clear there’s a lot of potential here. You’ll want to listen to the entire interview and of course, you’re not going to want to miss Stephen present his talk, The Art & Science of Seductive Interactions, at our UIE Web App Masters Tour. It’s going to be impressive.

Stephen Anderson is just one of the incredible speakers we’ll be hosting during the Web App Masters Tour. Learn more about our locations dates and speakers at UIETour.com.

Are you building your web apps with an eye towards motivating specific behaviors? Let us know in the comments!

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!

Subscribe to our podcast via

I had the pleasure of chatting with Leah Buley recently, in advance of her appearance at our User Interface Conference. She’ll be speaking about getting to a Good Design Faster with new techniques to getting at your creative ideas. She’s done some wonderful research on early-project design stages that you really need to hear. There’s a ton of great content in this podcast, and I can only share so much with you here, so please tune in for more of her insights.

When Leah told me that wireframes are really holding back the design process, she grabbed my attention. Designers sit down with some rough ideas and start trying to fit them into one or two pages. Next they start sliding design elements around until things feel good, and then they show it to someone for feedback. That someone or group then sees a design that’s pretty far along, and looks pretty concrete. If some of the ideas in the wireframe are not developed as much as they should be, it’s difficult to stop the forward momentum and reassess.

How can we explore a range of solutions before diving into a single solution? Wireframes are very useful to the process, but instead, we should consider delaying them. Before wireframes, Leah suggests a very open, cross-team exploratory stage. Invite people from across your organization and even collaborate with those who might not normally be within the core design group.

Leah suggests a week-long ‘design sprint’ that begins with a group brainstorming meeting in the morning with lots of people… and everyone’s opinions count. Then that afternoon, the group sketches out a large number of low-fidelity sketches further exploring the experience they’re looking to design, based on the morning’s activities. Sketching many iterations based on different perspectives like, ‘how would we optimize this for a first-time user?’ ‘how about for a power-user?’ ‘how about for this demographic?’

Then the week-long process continues. Grouping the different approaches together, sort the best from the bunch, mixing and matching the best ideas and build upon them (Leah calls this ‘sketch-boarding’). Next, take the sketches and flows with the most potential, and make those the first round of wireframes, which you present to a group critique. At the end of the week, take the feedback from the group critique to improve the wireframes.

The end result is a wireframe that has a tremendous amount of collaborative thought behind it. Instead of surprising many stakeholders at this point, their good ideas are already baked inside. You can now share these fire-tested ideas with the next groups that need to see them. This is clearly different from the way many groups and designers are using wireframes today, and I think it’s a really powerful proposition.

Leah and I also talked about ways to become an effective sketcher, how to run productive group critique sessions and much more. You really need to listen in, this could really help your teams process. After our conversation, I’m even more excited to see her full-day workshop on this topic this November at UI14 in Boston. I hope to see you there, as well.

Till then, what are your experiences with the early rounds of design? What are you doing in advance of your wireframing? Can you see implementing this process in your organization? Let us know in the comments!

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.

Subscribe to our podcast via

Userability is back with another episode. Have a serious UX question? Send it in and Jared Spool and Robert Hoekman, Jr. will answer it with a healthy dose of levity. Please send your deep, vexing questions to us at userability@uie.com. We’d love you to feature you on the show!

This week, we spoke to Miles Dowsett from Cambridge, UK who is straddling the worlds of desktop and web-based applications. He wanted to know,

What do you think is the most important or significant UX deliverable/activity in a web project, and why?

Tune in to hear Jared and Robert lock horns on their different approaches on must-have UX techniques… and leave your suggestions here, in the comments!

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.

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.

Determine if this seminar is right for you and your team by reviewing Ginny’s ’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!

In advance of the presentation, we’d love to hear from you. Have you ever struggled with writing something for your site? How do you know you got it right? What rules do you follow for creating effective copy? And what are your thought on how to handle those “marketing moments”? Share your thoughts below.

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