“Feature Blindness”
Scott Jenson defines ‘feature blindness’ as users being blinded by a feature list. He identifies the bottom-up approach of creating a user persona and a task scenario as more efficient than the top-down approach, in terms of organizing a commonsensical hierarchy of a product’s features. The ideal visualization would be to ‘tame’ the feature list and prioritize features in accordance to a set of usage requirements and subsequent usage frequency.
UnFeatures: There’s More Than Meets The Eye
In considering the context of use, designing a product requires considerable knowledge of the end-user’s lifestyle. In this sense, the product will have to fit a type of skilled-user. UnFeatures, as Jenson explains, “is a broad set of problems that needs to grow over time.” (p.75) For instance, what would be the setup requirements of a product? Does it allow for direct usage, or are there instructions to follow prior to a full-use interface? With broad markets there is a need for easy and simple step-instructions. A product strategy is planned to account for errors and facilitate error-correction. Jenson suggests an example of a ‘search button’ that does the work for users to avoid rejection and enhance user forgiveness and product acceptance. UnFeatures should be included in the product strategy plan at the very beginning of the design process. For instance laying down the products features (functions offered by the product) and the unfeatures (concerns such as recovering from errors and user feedback) can help create a hierarchy of relevance.
The Priority Trick
Having features and unfeatures is great, but when it becomes very confusing for users when too many options are available. Jenson notes that creating a persona/scenario helps shape the hierarchy of your features. Quantitative data is usually handy here: frequency of use, and a preference ranking are some of Jenson’s examples of how to decide on what’s important to users.
Make the Easy, Easy and the Hard, Hard
If we carefully follow Jenson’s method, with a persona/scenario determined and a un/features list prioritized, at this point the skeleton of the product can be build and secondary features can be worked out through sub-menus for example and elaborate layering. Keeping it simple, as the title of his book suggests, seems to be Jenson’s motto. One trick here would be to calibrate the flexibility of a product while considering the complexity and simplicity factor. If more flexibility creates ambiguity, then limited depth insures a higher usability level.
Another trick is to consider both expert and emerging users, and in doing so, expert features will be hidden in the depth of the interface. This way, emerging users will not be overwhelmed by a multitude of features that may not have compatible relevance. So features addressing specific sub-category users (expert users for instance) demand more timely investment in digging out the features, which allows the broader audience to have access to minimal and immediate core functions.
If we look at a “feature list as a source of design confusion” (p.89), we can begin to break them down into categories and organizing their hierarchical importance in terms of the end-user/persona characteristics.
“Innovation Blindness“
Scott Jenson defines ‘innovative blindness’ as members in a team that hold “attitudes that discourage innovative thinking.” (p.113) He critiques corporations that follow previously established guidelines for designing rather than thinking outside the box and looking for new ways of designing meaningful products for meaningful experiences. In his opinion, it is important to question the design in context and its underlying rules.
Where innovation occurs is when you get design dreamers and pragmatic programmers working together to get brilliant design implemented with as little work as possible.” (p.114)
See the Water
The water becomes hard to see when designing new products is made in terms of how previous products work. Here the author gives two of the more commonly employed: the digital watch and critical elements of desktop appliances such as the scroll-bar. He emphasizes conventions and template designs a great hindrance to innovative breakthroughs. Scroll-bar do not need to be included everywhere for the sake that they are useful on the web. New products need new conceptions to create new meaning and new ways of navigating space.
Embrace the impossible
One way to go about encouraging change and innovation in a team is to create a synergistic environment for both pragmatic programmers and dreamer designers to talk, negotiate, collaborate and agree on a compromise that meets both of their concerns and goals. Jenson suggests trying new ideas and failing in the process. This type of approach however is only made possible in a team that promotes a positive attitude to iterative design. Design that does not fail is mostly a design that is done safely and that more often than not will be quite similar its predecessors. Questioning design templates helps designers engage in innovative attempts and “See the Water.” One factor to consider here would be user expectations and how deviating too far from them may obstruct a product’s usability. Zeroing in again on scenarios and personas helps achieve a balance between pragmatism and innovation and hence provides a meaningful ground for designers and programmers to articulate their respective needs and generate collective design solutions. Jenson calls this a “win/win situation.” (p.122)
Fail fast
By Fail fast, the author suggests starting with an idea or concept that may be frail, putting in on paper, working out the ‘works’ and ‘don’t works’ of it and proceeding in a frequent iterative fashion. He offers three typical methods used for innovating and evaluating concepts: Sketching (web sketch, increasing fidelity); Interactive Demos; User Testing.
Innovation doesn’t flow fully formed through your fingers on to the paper. It only comes in fits and starts, and, sometimes, you have to work your way through dozens of designs to find your way to the one that pulls it all together.” (p.132)