Designing for Behavior Change

Chapter 11. Turning the Designs into Code

Put the Interface Design in Front of Users

When the interface designs are ready, the product team should test them in the field—before committing engineering resources to a full implementation. Ideally, that should be done with low-cost clickable prototypes—to increase the realism of the experience for users. But the team can gather rough and dirty feedback from graphic designs, aka comps, too. This process should iterate as many times as needed until the designs are solid and successful in the field.

Besides all of the excellent reasons one normally hears for user testing—to look for usability problems, to get gut reactions on aesthetics, to identify missing functionality—there’s an additional reason in the case of designing for behavior change: you can never be certain the package will “work,” behaviorally, until it does.

As I discussed in Chapter 1, behavioral social science, and with it, the process of designing for behavior change, is still developing rapidly. There aren’t any simple formulas for behavior change. The previous chapters in this book have provided guidelines on leveraging the excellent research that’s available, but field testing and refinement are still absolutely essential to the process.

As you gather user feedback, surprises will occur. The application may be quite engaging for some users, but completely uninteresting to others (or worse, it could be patently offensive). There are two issues in particular to consider as ...