The Payoff of Planning Persuasive Architecture

• Tweet
• Buffer

I've discussed the Minerva Archectural Process (MAP) steps to arrive at the point where most people begin the development process. These initial steps help get from abstract concepts (uncovery) related to Web site development to the concrete issues (optimization). All phases are critical to delivering a project on time, on budget, and on purpose.

Prototype

Rapidly go through the uncovery, wireframe, and storyboard processes. Cycle through successive iterations to arrive at a finished prototype. The prototype's appearance is identical to the application to avoid that costly project killer, "scope creep."

Complete Scenarios

During development, it's easy to focus on features and checklists. They're minimum requirements to get a site, any site, up and running. Concentrating on features for features' sake results in a bloated feature set (most of dubious utility) and a difficult product for users. Adding a feature to a Web site, regardless of its utility or role in the sales process, is poor persuasion and worse architecture.

Features are not a site's value. Value lies in a customer's ability to complete the tasks described in scenarios they find relevant. If your team recognizes the difference, they'll strive to create a site that enables users to complete actions they (and you) want them to take.

Acceptance Tests and Freeze

Lay out these scenarios, then use them to complete the front end of the development process (no coding yet). No prototype is complete until it accomplishes all client-identified scenarios, and does so in a way the user of each scenario agrees with in an "acceptance test." At the point where both client and development team agree prototyping is complete, freeze the prototype. No other changes can be made (in this version). A final set of acceptance tests are then defined.

How do you know when iterations are done and freeze can occur?

Hal Helms explains: "There's an old story told about a little girl who's asked to spell 'banana.' 'I know how to spell it,' she explains. 'I just don't know when to stop.'" (Keep reading, I'll explain later...) With these techniques, we know when to start writing markup and code (when the prototype is frozen) and (just as important) when to stop (when the prototype runs). Thus, we begin to craft a system that will make both client and developer successful.

What's the danger in writing code? Author and businessman Richard I. Winwood said, "If we do not choose to plan, then we choose to have others plan for us." If you fail to provide every detail, the developer makes choices for you. If the prototype is complete, there's no guesswork. He'll do what he does best: code.

Every hour spent planning a project saves roughly three in coding and development. Programming is expensive -- way more than planning. It doesn't take a rocket scientist to understand the significant savings in keeping a brake on development until planning is complete. If that means spelling the fruit "banananana," so be it.

Optimization

Optimization is where a development project comes full circle. Technically, the site works. That's the point of acceptance test hurdles. Now, test how visitors use the site. By tying in the site's objectives (defined in the uncovery phase) and viewing the persuasive architecture's results in visitor scenarios (created during wireframing), you can determine using Web analytics how close intent is to what actually occurs. Then, follow a disciplined strategy based on measurement, testing, and re-evaluation to get closer to meeting objectives and to improve results of every page not meeting its responsibility.

Keys to Success

Successful methodology requires:

• Being flexible. Methodology must be flexible enough to deal in principles, not absolute rules. It must accomplish the same results regardless of size and scope of a project. There are countless ways to make holes: big and small, holes in dirt and holes in concrete. If the right tools are available, I can reach the objective of making a hole.
  
  
• Focusing on people. For group acceptance of a methodology, understanding cognitive psychology and communications theory is critical. Focus on individual team members' roles. The methodology must initiate with an understanding of the people involved and their goals and objectives. This facilitates meeting both end-user needs and business objectives.
  
  
• Using it. No matter how good the methodology, it's worthless if it's not used. Apply methodology to the smallest projects, even if it's not necessary. It's good practice for projects that will need it.

Bryan will speak at ClickZ Email Strategies in San Francisco, November 18-19.