5 Ways to Improve Your Next Agile Project with the RITE Method

If you have been designing or researching on agile teams, consider using the RITE method to validate your design decisions on your next project. If you have not heard of the RITE method, you are going to be really stoked by this approach. If you are a seasoned RITE designer, continue reading to learn some best practices.

The RITE method was introduced by Michael Medlock and his team from Microsoft, while they were testing a video game. The RITE method differs from traditional usability testing because the project team is encouraged to make design changes during the test. On your next agile product, follow these five tips to improve your upfront design with the RITE method.
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 

Tip #1: Use Low-Fidelity Mockups (or Learn to Love Paper Prototyping)

 
The goal of the RITE method is to validate your design decisions quickly and make changes to the latest versions of your product. Low-fidelity mock-ups, such as JPG files with hot links, work great for many reasons:

• You can quickly change the JPEG files.
• You do not have to rely on a code build for the next session.
• You can send JPG files via email or post to a Wiki easily.
• You do not focus your testing on interaction design.
• You focus on information design, navigation, and workflow with JPG files.

Arguably, the best reason to start with JPG mock-ups is you can start the design process immediately. You do not need code. Your design decisions are informed (and validated) with customers, too. As the developers work on architectural spikes and setup their different environments, you can already have done your RITE testing.

Tip #2: Use Whiteboards to Capture Issues, Take Digital Pictures to Distribute Them

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Use whiteboards to quickly write down the observed issues during the tests.  You can also keep a running catalog of what changes you have made to address the issues, too.  As issues are fixed, you just put a check mark next to resolved ones.  As with any agile project, you want to document smartly.  A whiteboard allows you to focus on the problems and solutions, not the documentation process.

Finally, take a digital picture of your results.  You can distribute the results to the extended team.  You cam post the pictures to a Wiki or blog.  You can show your progress.  Plus, you might just save time in defending your design decisions by sharing the pictures during the process.  And, these pictures can be re-used, if you need to explain to an executive what you did in your RITE study.
 

Tip #3: Be Smart about Scheduling

 
Customer’s time is invaluable, so respect it. And, be smart with scheduling.  You have two primary goals with any RITE study:

1. You want to gain insight from real customers.
2. You want to make design changes based upon the customer feedback.

So, you need to schedule for your customer’s time and the designer’s time. Here are three different methods for scheduling. I am sure you can come up with hundreds.

Daily Distribution for Two Weeks

You may want to even distribute the test sessions throughout each day. I have used 9AM-11AM and 2PM-4PM for several projects. The advantage of this schedule is you give the designers an opportunity to actually work during the day from 11AM-2PM. Plus, they have the evening to make changes, too. You can see how this schedule looks below:
 

 

Test Days & Design Days for Two Weeks

You may want to schedule specific days for testing with customers followed by a design day to work on the problems. The designers will probably start working on issues with the last customer, which only means you can solve more problems. The design days also allows for the team to work on other projects, answer emails, and go to meetings. The test facilitator can take pictures of the whiteboard, post pictures to a Wiki, and so on. You can see how this schedule might look below:
 

 

Front Load Testing for Two Weeks

My cow-workers use a schedule where they front-load testing with users for two days with Wednesday as a design day. They switch to two tests on Thursday and Friday, using the weekend to make significant changes. Then, they front-load testing on the Monday and Tuesday of the following week. My co-worker’s theory is that the most obvious issues will be identified quickly during the first two days. More significant issues will require time to design, so they give the designers time to come up with creative solutions. You can see how this schedule looks below:
 

Tip #4: Keep a Change Log, Do Version Control

 
As you start to make changes, you will need to keep a change log and perform version control to keep things moving in an ordered an efficient manner. The change log is your way of knowing what has changed, what needs to be done, and what needs more time. You can use the change log to measure your velocity, too. In my experience, a spreadsheet works best for the change log. An example is shown below:
 

 

You need to perform version control of the software to make sure you are testing the proper designs. In addition, the version control allows you to show progress with your solutions. In the end, the final prototype is your deliverable to the project team. You version control is critical to telling your story and explaining the reason for your design decisions. With JPG files, we just place them in separate folders in a shared directory. An example appears below:
 

 

Tip #5: Show Your Results Visually

 

When you do your retrospective at the end of your sprint (or iteration), consider showing your results visually. You do not have to create a slideshow for this discussion. If you have saved the different JPG files to a shared directory or Wiki, you can start with your initial prototype and display the final images. The team will see the changes.

You might want to provide some hard copies of the Change Log document. Your project team will be surprised to see the number of changes made to your design. In one of my RITE studies, the design team made 118 significant design changes before any code was written. You will experience similar results using the RITE method on your next agile project.

I hope these tips and tricks were helpful. I have been using the RITE method for about 5 years now.

What tips and tricks do you use with the RITE method?