Practice Kaizen

Kaizen was first mentioned way back in Chapter 2 when I talked about how to write use cases, and again when I discussed wireframes, but kaizen can continue to be applied long after an application is built and released.

Although kaizen was originally developed as a management approach aimed at improving quality and reducing defects in manufacturing, the underlying philosophy is central to my approach to application design. Kaizen is about doing the work of improving things constantly, in little tiny ways that add up to gigantic results.

Kaizen can be applied to the way you write code in the programming language of your choice, design task flows, or refine the visual design of an interface.

One of the major benefits of kaizen is that it keeps you from worrying about making things perfect on the first try. To the contrary, it enables you to focus only on getting something done so you can start improving it incrementally. You can start with a grayscale HTML page if you like. As long as you keep improving things as you go, you're in good shape.

Abe Fettig, one of the developers for JotSpot Live, recently told me:

During development, we tried to keep the feature set of JotSpot Live very small and focused. There were a lot of interesting things we could have done, but our number one goal was to get the product released and in the hands of users. Our CEO Joe Kraus is fond of the saying "perfect is the enemy of the good." If you have a product that is good in its current state, something that works and provides a useful service to people, and you hold back from releasing it because there are more features you want to add, you're not doing yourself or your users a favor. At that point, your desire for perfection is getting in the way of something good. So, as we developed JotSpot Live, we concentrated on building a good 1.0 version, without trying to add every feature necessary to create the "perfect" version. And in retrospect, this simpler version is better than a more complex version would have been.

Personally, I make it a habit to find something to improve at least once a week. Of course, my job is focused entirely on making things better, so this is pretty easy to do, but within that construct, I look for ways to improve my process, improve an interface I haven't looked at in a while, make meetings more productive, keep phone calls shorter, make wireframe elements reusable as templates, and anything else I can think of. Beyond that, I constantly refine interfaces and interactions in an effort to improve them in even the tiniest ways by making them more readable, more understandable, and less complicated.

Kaizen means iteration

Another major benefit of kaizen is that it enables us to get products in the hands of testers more quickly. The sooner a user starts using real screens to deal with real interactions and complete real tasks, the better. Wireframes, use cases, and mockups are great for planning a design and getting the ideas worked out, but things inevitably change once our designs go from paper to screen. It's at this point that we see how an application really works. Putting our designs in front of beta testers is what allows the truth about our work to come out into the light.

Abe Fettig told me:

From there we developed JotSpot Live by doing a lot of fast iterations. I wrote the code, and Joseph Wain did the CSS and graphic design. We'd push an updated version up to our testing server every day or two. We had a group of test users that started out mostly internal and grew to include a lot of people outside the company as JotSpot Live grew more mature and we got closer to release.

There's always a way to improve an application (and no, I don't mean by adding things to it). And every time you make a small improvement to an interface, doors open up for improving the new version. But none of the changes cause any major disruption in your work, because tiny changes take almost no time at all, so you can keep plugging away at the activity of building sites and software without becoming buried in documentation and conversation about all the improvements you've made.

Kaizen means iteration. To genuinely improve our applications in the long run, we need to repeatedly go over them, see where things can be improved, make changes, and put new versions in the hands of real users to prove the changes are better. Wash, rinse, repeat.

The 5S approach

5S is another Japanese improvement process originally developed for the manufacturing industry. And just like kaizen, 5S translates well to interface design and application-development processes.

In fact, this book has discussed every aspect of 5S without ever mentioning it specifically (until now, anyway). But while the whole concept of designing the obvious can be wrapped up by these five points, it's most appropriate to describe 5S in context of the topics of reduction and refinement, because each point of the 5S system contributes directly to both topics.

The rest of this section is a summary of each piece of the 5S system and how it relates to designing the obvious.

Seiri (Sort)

Seiri is about sorting through tools and other materials to determine what must be retained and what can be thrown out or stored. In manufacturing, seiri produces a safer environment by keeping unnecessary items out of the way of workers, so they can be more steadily productive.

In Web terms, seiri can be thought of as sorting through features, interface elements, and screens to minimize an applicationor a single screento its most essential parts.

To sort through these things properly, you have to Know What To Build, which includes knowing what not to build. Even after a product is developed, however, we can go through an application repeatedly in an ongoing effort clean it up and get unnecessary elements out of it.

Seiton (Straighten)

Seiton refers to arranging things into their most efficient and accessible arrangements. In other words, order should be maintained relentlessly so resources are easy to access.

In Web applications, this is about designing for uniformity so that users can derive meaning from a page's content based on how it is laid out.

Seiso (Shine)

Seiso is about keeping clean, tidy workplaces. Cleaning should be a frequent activity and should always be aimed at polishing up anything losing its shine.

On the Web, seiso can relate to improving or updating the look of graphical elements, devoting attention to more perfect alignment and distribution among page elements, and devising color palettes that contribute to the overall mood and personality of the application.

Seiketsu (Standardize)

Seiketsu is about leveraging standards to enable consistency. Online, adhering to standards means using proper semantic markup in Web pages and keeping the code used for presentation and content clearly separated.

HTML is designed to identify the structure of content. Headings are marked as headings, paragraphs as paragraphs, and so on. CSS, on the other hand, is used strictly for the presentation of the marked-up content. The standard use of these two technologies together improves the accessibility, maintainability, changeability, and sustainability of Web content. But seiketsu goes far beyond markup.

Seiketsu also means establishing a set style for an application to which all screens can conform, so each screen enables a user to maintain her mental model, and makes it easier for her to learn and orient herself to new screens.

Standardization can go a long way. Many companies maintain style guidelines that detail when and how radio buttons, checkboxes, and other elements should be used and how they should look and work. This can even be extended into a design pattern library, as discussed in Chapter 7. In this case, the library as a whole can be refined one pattern at a time and applied to multiple applications successively, so that a suite of tools can all be improved based on a single standard.

Shitsuke (Sustain)

Shitsuke is about sustaining the work of each of the elements in the 5S system for the long haul.

Improvement (kaizen) should not come in small waves and then fade away. It should be kept up on a permanent basis. The repeated process of reduction to retain only what's needed in a screen or application (seiri), the arrangement of elements into their most effective forms (seiton), the polishing of what's left (seiso), and the standardization of screens and interactions throughout multiple applications (seiketsu) are all processes that should be maintained.

The long-term effort to refine the applications we construct is how we create solutions that are effective and desirable, both now and later.