These days it’s expected to be able to narrow search results with filters, e.g., on the left side of the results page. Called faceted navigation, this is a way to improve overall findability of information, particularly on sites with large collections of products or documents. Remember: people can’t buy what they can’t find, and filters help them get there.

The design of real-world faceted navigation systems, however, proves to be more intricate than people first assume. There are many hidden challenges, such as displaying large amounts of metadata and creating simple interactions average users understand. The truth is, once you dig into it there are many details to be aware of.

What’s more, faceted navigation doesn’t stop with search filtering: it can be applied to the design of navigation across the site. People can browse by facets before even searching, for instance. With this in mind, faceted navigation improves the discoverability of your content dramatically throughout the entire user experience.

I’ve developed a course on faceted navigation that I’ve been giving for nearly 8 years now. Many students ask for further resources and information. So I’ve compiled this list of references:

Marcia Bates, “The Design of Browsing and Berrypicking Techniques for the Online Search Interface” (1989)

William Denton, “How to Make a Faceted Classification and Put It On the Web” (2003)

Karl Fast, Fred Leise, Mike Steckel, “All About Facets and Controlled VocabulariesBoxes and Arrows (2002)

——— “1. What Is a Controlled Vocabulary?Boxes and Arrows (2002)

——— “2. Creating a Controlled VocabularyBoxes and Arrows (2003)

——— “3. Synonym Rings and Authority FilesBoxes and Arrows (2003)

——— “4. Controlled Vocabularies: A Glosso-ThesaurusBoxes and Arrows (2003)

——— “Facets and Controlled Vocabularies: An Annotated BibliographyBoxes and Arrows (2003)

Instone, Keith “”Faceted Browsing – How User Interfaces Represent and Benefit from a Faceted Classification System“, SOASIST meeting, Dayton, Ohio

Jim Kalbach, Designing Web Navigation, Chapter 11 (2007)

——— “Faceted Navigation: Showing More Values

——— “Faceted Navigation: Layout and Display of Facets” (2010)

——— “Faceted Navigation: Grouping – An Untapped Potential” (2010)

——— “Faceted Navigation: SEO and Facets” (2010)

——— “Faceted Navigation: Typical Structures for Values” (2010)

——— “ROI of faceted navigation” (2011)

——— “Faceted Navigation: Displaying and Forecasting Magnitude“ 2011)

Kwasnick, Barbara H, “The Role of Classification in Knowledge Representation and Discovery” Library Trends (1999)

Fred Leise, Sarah A. Rice, Amy WarnerDeveloping a Faceted Classification” 

This slideshow could not be started. Try refreshing the page or viewing it in another browser.

Louie, Aaron J., Eric L. Maddox, and William Washington “Using Faceted Classification to Provide Structure for Information Architecture” Information Architecture Summit, Portland, OR (2003)

Peter Morville, “The Speed of Information Architecture“ (2001)

Jakob Nielsen, “Converting Search into Navigation” (2013)

Greg Nudelman, “Faceted Finding with Super-Powered Breadcrumbs” (2009)

Greg Nudelman, “Numeric Filters: Issues and Best PracticesUX Matters 

Priss, Uta, and Elin Jacob, “Utilizing Faceted Structures for Information Systems Design,” in ASIS ’99: Proceedings of the 62nd ASIS Annual Meeting (1999?)

Ranganathan, S.RElements of Library Classification. 3rd ed. New York: Asia Publishing House (1962)

Andrea Resmini and Luca Rosati, Pervasive Information Architecture (2011)

Tony Russell-Rose and Tyler Tate, Designing the Search Experience: the Information Architecture of Discovery (2012)

Donna Spencer, Card Sorting (2009)

Louise Spiteri,”A Simplified Model for Facet Analysis: Ranganathan 101” Canadian Journal of Information and Library Science (1998)

Jared Spool, “Users Continue After Category Links” (2001)

Steckel, Mike, “Ranganathan for IAs” Boxes and Arrows (2002)

Daniel Tunkelang, Faceted Search (2009)

Peter Van Dijck, “Introduction to XFML” (2003)

——— “XFML Core – eXchangeable Faceted Metadata Language” (2003)



Elastic Lists



Freebase Parallax 


OptimalSort from Optimal Workshop for card sorting

Relation Browser

Scatter / Gather UI 

Trivago TV advertisement (shows the value of facets in a commercial setting)



UX Strategy Blueprint

12 August 2014

How do we consistently create UX strategy? Tough question.

Part of the problem is in the fuzziness of the term “strategy” itself. Many people blur it with detailed planning. Others consider strategy to be in-depth investigation, such as market research or competitor comparisons. Or, it gets conflated with vision or ambition.

None of these is strategy.

Strategy is about uncovering the key challenges in a situation and devising a way of coordinating effort to overcome them for a desired outcome. It’s an interlocking set of choices that aligns activity and shows causality: if we do this, then we expect to see that.

Analysis and planning, while necessary inputs and outputs in the strategy creation process, are not the core of strategy. You can’t analyze your way to strategy: the answers don’t magically emerge from data. And detailed roadmaps don’t provide the rationale for the activity they organize. Strategy does. It connects analysis and planning with an intentional logic that guides decision making.

The UX Strategy Blueprint is a simple tool to help you define a UX strategy. Try it out:

Download the UX Strategy Blueprint

UX strategy blueprint

Keep in mind that strategy is hierarchical. It cascades from the top down. Effective UX strategy aligns upwards.

Regardless of level – corporate, product, team or personal strategy – the crux of strategy work relies on the same set of elements, outlined below. Using this schema allows you to not only articulate a UX strategy consistently, but also map it back to superordinate strategies.

Elements of UX Strategy

The elements in the UX Strategy Blueprint are based on existing research in the field of strategy. First, it borrows from Henry Mintzberg’s five Ps of strategy from his landmark book Strategy Safari. These are combined with Roger Martin and A.G. Lafley’s five questions of strategy in their recent book Playing To Win. (Both books are highly recommended).

The intersection of these two frameworks yields six common facets. Each is given a box in the Blueprint, formulated specifically for generating UX strategy. Below each of the six headers are guiding questions, as well as examples of the types of information required.

Here’s how to interpret each element in the UX Strategy Blueprint:

  • CHALLENGES.  Strategy implies the need for change, a desire to move from point A to point B. What are the hurdles to doing so? What opposing forces must you overcome to be able to reach the desired outcome? For instance, in user experience design you may face challenges around coherency if, say, you’re trying to integrate several web properties after an acquisition.  Or, you may be fighting severe usability issues or a deteriorating image. Ultimately, strategy is about problem solving. What problems are you solving for? Focus on customers and users, but you may also have internal challenges you want to list here too.
  • ASPIRATIONS. What experience do you ultimately want to deliver? Go beyond the generic goals like “be consistent.” Instead, strive for something more aspirational. For example, you may want to differentiate your service through a specific type of user experience, which would drive adoption. More importantly, consider how you will impact your customers’ work and daily lives. How does your solution transform what they capable of doing and who they ultimately are? Your aspirations should inspire your teammates.
  • FOCUS AREAS.  Strategy is about trade-offs. Indicating your focus areas helps concentrate effort on the things that matter most. Note this doesn’t necessarily mean you’ll be ignoring everything else not listed, just that the elements listed here are of higher priority. Indicate your primary focus for these five topics in a straightforward, factual manner:
    • USERS – Who will use your solution? If you have personas, list the ones that are most relevant to the success of this strategy.
    • REGIONS – What are the countries, languages, and cultures that are in play?
    • SERVICES – What products, services, platforms, and technologies are included in the strategy? Scope out the ones that aren’t.
    • USE CASES – Indicate the key scenarios of use at a high level. For instance, in ecommerce settings will you focus on finding products, the purchase process, or both?
    • AREAS OF UX – What areas of UX will make the most difference? Highlight aspects such as information architecture, interaction design, visual design, content strategy or branding, as well as attributes of usability such as control, learnability, or discoverability, among others.
  • GUIDING PRINCIPLES.  This is perhaps the trickiest but most important part. In business strategy, the guiding principle indicates how you’ll win against competitors. For UX strategy, the guiding principles are the approaches you’ll take to overcome the challenges and solve the problems you’re facing. This can include a particular sequence of activities, like “mobile first.” But strive to be even more specific. What rules of thumb must be in place to reach your aspiration? What mantras would you give design teams to consistently execute towards the same goal? Remember: strategy provides consistency in behavior. How will you get everyone paddling in the same direction?
  • ACTIVITIES. What types of UX activities are needed to implement the strategy and achieve your aspirations? This includes such things as user research, concept development, sketching, screen design, prototyping, and testing, as well as creating patterns or guidelines. Team development and skill development can also be recorded here. Note that this section shouldn’t read like project plan, rather it’s an inventory of the types of activities required to reach your aspirations. Keep in mind you may need new capabilities to execute your strategy. That’s OK: strategy isn’t a re-configuration of existing skills and resources, rather how you’ll maximize chances for success.
  • MEASUREMENTS.  How will you know your strategy is on track? How can you show progress and success? Often benchmarking and comparison is needed. This means you’ll likely have to measure aspects of your user experience (e.g., satisfaction) before and after work begins. Ultimately, your measurements should support the business goals. Try to find metrics that show the positive impact UX has on business. Be specific with goals like “increase sales by 5% by streamlining checkout” or “reduce calls to the support center by 15% by providing better self-help online.”
    You’ll probably find overlap with the information you provide for these six elements. That’s a Good Thing: strategy is an interlocking set of choices you make to overcome adversity and reach a desired position. Still, try to avoid direct repetition in wording. The overall logic should make a coherent storyline.

How To Use the UX Strategy Blueprint

Building UX strategy is a creative endeavor. Explore different options, asking “what if?” and “what would need to be true?” With the UX Strategy Blueprint, there is initially no risk in trying out alternatives: cross things off, move sticky notes around, rework ideas, crumple it up and start over again. Strategy is designed.

It’s best to start with the challenges and aspirations. After that you may find yourself bouncing around between the boxes. That’s fine. The Blueprint exposes the dependencies in strategic choice, letting you see all of the elements at once.

There are several situations in which you can use the UX Strategy Blueprint:

  • BRIEFINGS.  Bring a print-out of it to briefings. The Blueprint serves as a great checklist of questions to ask. Your notes will also be concise and captured in a single overview.
  • WORKSHOPS.  Hang a poster-size version of the Blueprint in kick-off meetings or strategy sessions. Use sticky notes to fill it out as a team. This guides the discussion and keeps the exercise focused, as well as builds consensus.
  • REFERENCE.  Post the completed Blueprint in the office for ready reference. This keeps your strategy in sight at all times.

The UX Strategy Blueprint can also be used online. There is a version of it, below, with open input fields, so you can capture the elements digitally as well. Or, try uploading an image of it as a background within an online collaboration board (e.g.,, and apply virtual stickies as you go.

UX Strategy Blueprint (with input fields)

Once all of the elements have been agreed on, consolidate the strategy. A good, succinct strategy should only be about two pages long. Give it multiple forms to illustrate your intent to different audiences. Create a presentation, document and a graphic, as needed.

Share the strategy as often as possible. It’s hard to over communicate: print it out, hang it up, start every meeting with your strategy slide, use it as dummy text in wireframes instead of lorum ipsum. Reiterate.

Developing strategy is a craft, one that involves exploration and choice but also systematic thinking. The UX Strategy Blueprint helps you see all the moving parts in a single overview. In doing so, it simplifies strategy, making an abstract concept more tangible for all involved.

In financial terms, “debt“ is money borrowed by one party from another. The borrower can spend money they currently don’t have with an obligation to pay it back later, usually with interest. So, the borrower is willing to trade off added cost (interest) for immediacy (spending money now).

Debt allows us to buy things we couldn’t otherwise afford with cash, like a house or a car. It lets us invest our future, for example by funding an education or a business start-up. When the equity of our investments exceeds our debts, we come out ahead in the long run. Score!

But too much debt is a Bad Thing. If not repaid in a timely manner, the interest can surpass the debt. This leads to economic ruin. So it’s the management of debt that’s key, not avoiding it entirely.


Technical debt” is a term programmers have been using for over a decade. The metaphor is simple: in software development, there are quicker ways to implement technology that are often messier and cut corners. There is a trade-off of immediacy over comprehensive system development.

But if left unchecked, these trade-offs ruin the overall technical system. Here’s why: with each future effort, programmers stumble over shortcuts in the system made previously for the sake of speed. This increasingly slows them down, which is like paying interest on a loan. Eventually, new development is unprofitable and not worth it all.

Ward Cunningham first used the metaphor “technical debt” to explain the refactoring work programmers strive to do. See his web page “Ward Explains Debt Metaphor for more. Be sure to watch the video.


I’d like to encourage the use “UX debt” as a way to reflect the accumulation of learnings about improvements to the design of a product or service that go unaddressed over time.* UX debt is the difference between the desired user experience and the delivered product or service. Left unchecked, a backlog of UX debt can lead to a downward spiral of negative experiences.

I’ve been using the phrase “UX debt” in my past and present work, and it seems to resonate with people, making the notion of trade-off clear. And the language we use makes a difference. For instance, during a recent product UI review with my ex-colleague, Uday Gajendar, now UX design director at CloudPhysics, we were able to effectively characterize the build-up of neglected improvements as “UX debt.”

Debt – financial, technical, UX or otherwise – is inherently invisible. This makes describing it and quantifying it difficult. The banking industry has very clear means of doing showing how much you owe. The UX field should work on similar mechanisms to make visible the consequences of cutting corners over the long run.

Usability tests and heuristic evaluations catalog issues explicitly. This helps. Other measures include satisfaction surveys, such as SUS (system usability scale) and even feedback from NPS (net promoter scores). While useful (and even necessarily) in some organizations, these activities are “heavy” and time consuming. Alternatively, Lean UX methods seek to more rapidly come up with solutions that apply learnings from users.

The key is acknowledging UX debt and managing it actively. Note that this doesn’t necessarily mean getting everything right the first time, but implies getting UX fixes refactored and prioritized quickly thereafter. Paying down the UX debt is the real challenge, not tracking it, particularly in large organizations.

Keep in mind, the user’s experience is not in a closed system. UX debt is influenced by external forces in the market. Regardless of your industry, your website is one click away from someone’s favorite; your app sits right next to other popular apps (including games) on a smartphone or tablet. From a user’s point of view, their experience with your product competes with all other experiences they have. So, UX debt can shift quickly with user expectations: a great idea two years ago may seem outdated today.

“Just add another tab” or “Let’s squeeze a button on the UI” are signs that you’re incurring UX debt. Such short-term tactics may be OK initially. But at some point the overall design system or information architecture breaks. UX design cannot be continuously thought of like dressing up Mr Potato Head without going back and refactoring the UI.

mr potato head

UX debt accumulates almost instantly. Design must be iterative: it’s about ongoing optimization. And your processes must account for that. Very often Scrum and Kanban approaches are blind to UX debt. So also be cautious of we’ll-get-to-it-later promises. Jeff Gothelf sums it up well in the first sentence of his best-selling book, Lean UXThe biggest lie in software is Phase II.

One tactic is to plan a sprint or cycle in the middle of development reserved just for refactoring. Engineers can iron out their system issues during this time, but keep some resources available to fix known UX problems. Precede this sprint with a usability test, and you’ll have direct input on potential problems and fixes. This is commonly referred to as a design spike. In addition, plan time and resources to re-apply learnings back into the product design after launching. “Build > measure > learn” is a loop the implies starting again with “rebuild.”

With UX debt, the currency that’s borrowed is user efficiency and user frustration – things they own, not us. The cost we’re OK paying is reflected in sentiments like: “Sure, we know how to make our product easier to use and better for our customers, but we’re not going to do it.” It shouldn’t be an “or”: we need to manage technical debt and UX debt. It’s worth mentioning that the two may have overlap. For instance, slow load times may be the result of technical debt that also incur UX debt.

Ultimately, addressing UX debt must be a commitment from the organization. For UX designers, the language we use can help gain support. The metaphor “UX debt” illustrates the impact of short-term decisions on the user experience. Remember: if your user experience goes bankrupt, your company just might too.

* see more from Will Evans, “On UX Debt” ; Ben Melbourne, “UX Design Debt” ; Glen Lipka, “The UX of Technical Debt” ; Andrew Wright, “User Experience Debt

Below is a list of resources I reference in my workshop on UX strategy. Because UX strategy must ultimately align with business strategy, understanding the business side of things is imperative. Consequently many items below represent some of my favorite sources on business strategy and strategy in general.

This list is by no means comprehensive. You will find additional materials on many of the books cited below, e.g., Roger Martin has many articles and talks based on his book Playing To Win; or there is an entire site dedicated to blue ocean strategy including further references and tools.

You can download the slides from my IA Summit 2014 workshop on UX Strategy here, as well as a PDF template of my “UX Strategy Canvas” – a tool to help dissect and capture the key elements of your strategy.


I just gave a talk for World IA Day at U Mich in lovely Ann Arbor entitled “Undiscovered Public Knowledge and IA.” Below are the slides, followed by links to the resources I mentioned in the talk. (Apologies for comical looking fonts: they seem to have gotten messed up when uploading to SlideShare.)


Since the appearance of The Lean Startup by Eric Reis, “lean” approaches have taken off like wildfire. As the name implies, “lean” is about reducing waste.

In the case of Lean Startup it’s specifically about reducing waste in business innovation. It’s an entrepreneurial method that seeks to ensure the right market-offering fit. Lean Startup is a new approach to continuous re-invention and how to deal with the inherent uncertainty involved.

But “Lean” has a long history and can mean different things in different contexts. And just saying you’re “lean” doesn’t ensure you’re following the Lean Startup approach.

There are many misconceptions about Lean Startup in software development.

#1 Lean Startup is an engineering process. (No, it isn’t)

Lean Startup does not mean getting code out faster. Instead, it’s what happens before you build anything for commercialization. Look to agile and extreme programming for faster development, not to Lean Startup.

The cause of this misconception stems from how progress is measured, namely with learning. Ries writes in The Lean Startup :

Lean Startup asks people to start measuring their productivity differently. Because startups often accidentally build something nobody wants, it doesn’t matter much if they do it on time and on budget. The goal of a startup is to figure out the right thing to build–the thing customers want and will pay for—as quickly as possible. In other words, the Lean Startup is a new way of looking at the development of innovative new products that emphasizes fast iteration and customer insight, a huge vision, and great ambition, all at the same time.

Lean Startup often feels uncomfortable to production teams. Ries warns:

I predict that you pretty quickly will get feedback from your teams that the new process is reducing their productivity. They will ask to go back to the old way of working, in which they had the opportunity to “stay efficient” by working in larger batches and passing work between departments.

…When I worked as a programmer, that meant eight straight hours of programming without interruption. That was a good day. In contrast, if I was interrupted with questions, process, or—heaven forbid—meeting, I felt bad. What did I really accomplish that day? Code and product features were tangible to me; I could see them, understand them, and show them off. Learning, by contrast, is frustratingly intangible.

So remember: Lean Startup is all about getting the right value proposition, not cranking stuff out.

#2 Lean Startup means “just do it.” (Wrong!)

Many people think Lean Startup implies a lack of structure and rigor. Ready, fire, aim! On the contrary, Lean Startup requires discipline – a lot of it. But don’t conflate this type of discipline with traditional management techniques, which are often the cause of innovation failure in other contexts.

In The Lean Startup, Ries explicitly warns against the just-do-it attitude and reacting negatively to this new kind of discipline:

Entrepreneurs have been trying to fit the square peg of their unique problems into the round hole of general management for decades. As a result, many entrepreneurs take a “just do it” attitude, avoiding all forms of management, process, and discipline. Unfortunately, this approach leads to chaos more often that it does success.

What’s more, just moving quickly doesn’t ensure that you are following Lean Startup. You have to go through all the motions: What is your vision? What are your riskiest hypotheses? How will you test and measure your assumptions? When do you pivot? And so forth. That takes time, attention, and some elbow grease.

Lean Startup is a highly focused, team effort, not building whatever can get done fastest.

#3 An MVP is a lightweight version of a full functioning product. (Usually not)

The “P” in MVP (minimum viable product) is misleading. Keep in mind that customers don’t know what enables your product or service behind the scenes. From their perspective the product is what they see and experience. And that can often be faked.

Remember, your goal at first is not to build something but to learn. So an MVP should be the smallest thing you can do to validate or disprove hypotheses.

Ries writes in a blog post on MVPs:

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

Some caveats right off the bat. MVP, despite the name, is not about creating minimal products. If your goal is simply to scratch a clear itch or build something for a quick flip, you really don’t need the MVP. In fact, MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.

You need to get the right MVP to test. Recounting a real-life consulting situation, Steve Blank – a father of the lean movement – describes it well in his post “An MVP is not a Cheaper Product, It’s about Smart Learning.” Instead of building hardware and software to test an idea, Blank recommended the team rent the hardware and crunch the numbers by hand. Then give the results to the end consumer and see if they find it useful. No development needed at all, and the turn-around time for learning is days, not weeks or months.

Broadening your definition of MVP to “the shortest path to validated learning,” as lean expert Anders Ramsey defines it, will reduce a lot of waste upfront.

#4 User testing will just slow you down (Er, um…that’s the validation part)

With Lean Startup, progress is measured by learning, not meeting deadlines or budgets. And you will not learn by sitting around a table rationalizing your decisions.  As much as you’re convinced your product is amazingly awesome, you are not your customer. And you can’t will your enthusiasm on them.

Instead, you need to “get out of the building”, as Steve Blank has famously said. Reis proclaims in The Lean Startup:

Startups need extensive contact with potential customers to understand them, so get out of your chair and get to know them.

But the goal isn’t to get direct answers to your questions: they won’t be able to give a thumbs up or thumbs down on your vision or value proposition like voting. Instead, you must empathize with customers and see the world through their eyes. What’s their mental model of the world? Reis recommends employing techniques from the design canon:

There are many techniques for building an accurate customer archetype that have been developed over long years of practice in the design community. Traditional approaches such as interaction design or design thinking are enormously helpful.

And of course testing your MVP – even if it is a completely fake product – is an essential part of the Lean Startup process. So user testing should ultimately been seen as something that speeds you up because that’s when you learn. If anyone tells you otherwise, they’re not doing Lean Startup.

Usability testing has become standard fare for most serious web and software development efforts over the last decade or two. The overall intent of testing is to reduce the risk of finding usability errors after product is launched. The typical “over-the-shoulder” method has served this purpose well. With this, stakeholders get a well-prepared report with a prioritized list of issues and a wealth of recommendations. All good  and fine.

An alternative approach is Rapid Iterative Testing and Evaluation (RITE). This is also a lab-based method, but with an important difference to typical tests: the prototype is iteratively evaluated and updated between session. So, you not only identify problems but also test the proposed solutions.

This method was formalized about a decade ago by researchers at Microsoft, most notably Dennis Wixon. In their original paper on the approach, the researchers focus on the key benefit of improving product design:

The goals of the RITE method are to identify and fix as many issues as possible and to verify the effectiveness of these fixes in the shortest possible time.  These goals support the business reason for usability testing, i.e. improving the final product as quickly and efficiently as possible.  The results presented here suggest that at least in the context of its use for the Age of Empires II tutorial, the RITE method was successful in achieving its goals.

What’s more, RITE is fast: the method compresses testing, problem identification and design fixes into a short period. This is good argument to make on any project. Topics such as “Agile Design“ and “Lean UX“ are all the rage these days. With these approaches, designers seek to prototype, test and revise their designs quickly and with little documentation. RITE fits into this canon.

But there’s an additional key benefit that’s not so immediately noticeable: team engagement. RITE tests bring team members and stakeholders together. They then collectively solve design-related problems in real time — right in the observation room. This does NOT mean “design-by-committee,” where designers can easily get out-voted. On the contrary: putting designers, product managers and business stakeholders in the same room with the same stimuli gives designers a stronger voice in shaping the solution.

There are several advantages to this type of heightened team engagement:

  1. Common language: Collaboration during RITE tests gives rise to a common language for describing design problems and their solutions. Whether speaking about a element or overall flow, teams develop a way of describing things, which brings a certain efficiency to subsequent discussions.
  2. Shared references for decision-making: Witnessing users struggle using a product provides a shared reference. When updating the design, this common experience provides a center of gravity for decision making. This shared reference is typically more immediate and longer lasting than typical usability reports, for instance.
  3. User-centered: Perhaps most important, the users are the center of attention during the whole process. Stakeholders and other team members, who may not have regular contact with users, get a chance to view users first hand. This builds empathy for users throughout the team.

In my experience improving the UI design quickly is only half of the benefit of RITE. Equally important is the type of engagement we get from RITE. And ultimately, this is next frontier of UX design: getting the right decision-making processes in an organization that favor the user experience. RITE can help with that.

Inviting different types of stakeholders is important. We strive to include everyone from developers to marketing to project sponsors. Although this makes raises the potential of a “design by committee” effect – which you should guard against – I’ve found it lowers the chance of design decisions being overturned later.

So, consider RITE for projects where it’s appropriate. See the presentation Carola Weller and I gave at Euro IA in Rome 2012 for more:

See also these resources on RITE.


[1] Medlock, M.C., Wixon, D., Terrano, M., Romero, R., and Fulton, B. (2002). Using the RITE method to improve products: A definition and a case study. Presented at the Usability Professionsals Association 2002, Orlando Florida.


Get every new post delivered to your Inbox.

Join 75 other followers