When you visit DIRECTV, the first thing you do is type in your zip code. A result set immediately appears presenting you with a handful of packages. It’s not a lot, but it’s just enough for a user to work with. That gave Bita and Ena their first clue for how to present their key experience: do not present more than five packages to a bride-to-be. Although each package has the same design and layout, they are differentiated by background color. That gave Bita and Ena a second clue: present wedding packages with an obvious differentiation mechanism. Perhaps they could use different background colors. But an even better idea might be to use a recognizable image or icon that denotes the distinction among the packages. For example, a high-end wedding package might show a limousine that says “Just Married” on the back window, whereas an economy package could show a regular compact car. Clues three and four came when they noticed how DIRECTV displayed packages by price from lowest to highest. As the user scrolls down, the more expensive packages list more benefits and take up twice as much space. You’ll catch clues by looking at all the details and figuring out how to use them for your product. Ideally, you will improve on the concepts, taking them up a notch on the design ladder for your product. But, you’re not trying to design anything just now. Instead, you’re aiming to pluck out the best ideas. After you have them, you’ll mock them up into a storyboard to demonstrate the value innovation. Do Feature Comparisons Before you begin creating mock-ups and storyboards, be sure that you look for more than just one comparison reference. Research and identify multiple (three to five) instances of a similar user feature, and put all those references into one document. This way, you can compare different approaches to a single UX problem. The comparison findings can be useless or inspirational. Still, you are looking for new models, and you want to think beyond the familiar to conceive of better ways to browse, search, filter, share, and reach a user objective. This deconstructed approach is called a feature comparison. You might find it contradictory, especially given that in Chapter 5 I agreed with Steve Blank, who deplores creating a bloated feature requirements list. Nevertheless, now that you are just using tools for discovery without necessarily showing the client, a feature comparison can be very helpful to identify opportunities for value innovation. It takes all the puzzle pieces out of the box and puts them onto the table in plain sight. Then, you can pick out the best pieces and components to