Once the product is defined, the development team designs and codes the software. This is called the build phase of Customer-Driven Quality. In this phase, the development team can use practices like A/B testing to test alternate designs.
Testing Alternate Designs
Making design choices often face the same issues as in the product definition phase; the choice is often influenced heavily based on the opinion of the most authoritative, or influential, person in the decision. Instead of relying on one person’s opinion, customers can vote with their behavior using A/B testing.
In an A/B test, two designs (or more) are presented to customers and a tracking metric is used to test which design better helps the customer succeed with the desired behavior. For example, Google famously tested 41 different shades of the color blue on web links to find the best color. In this case, the best color was chosen by how frequently customers clicked on an advertisement link.
We have several methods for developers to interact directly with customers during the implementation phase. These boil down to putting a name, face, and engagement with actual customers to build the right product in the right way for our customers.
The Adopt a Customer approach has a developer choosing a small group of customers. The developers then build the feature collaborating directly with the customers. The developers have access to customers to ask questions, give frequent informal demonstrations, and brainstorm ideas. This process provides focused problem solving, rather than guessing intent from the requirements (or asking HIPPOs).
We maintain a list of customers willing to provide frequent interactions, through the Inner Circle program. Customers opt in to this program, and are available for consultations.
Behavioral economics, and web analytics, have shown that when customers are presented a choice, they quite often choose the default selection. This behavior should be considered when making design decisions. For example, a user interface design where the customer should choose from multiple options (State, for example), should not pre-select a default, especially if the list if alphabetical. I’ve seen customer data where Alaska has an unusual high number of customers. This is because, I believe, Alaska is the default selection for customers who just click through that screen.
Reviewing the default options is a specific line item in the design review checklist.
Build with Customer’s Platform
Many self-inflicted errors come from cross platform development. To the degree possible, this should be avoided. The product should be built on the platform used by customers.
In the current state of web application development, most developers prefer to develop with Chrome, because of the superior development and debugging plug-ins. These plug-ins were developed by developers, for developers (talk about Customer-Driven Quality). However, most customers use Internet Explorer as their browsers. Ideally, the web UI should be developed with Internet Explorer, or at least tested by the developers before they check in.