I submit that UI needs a haircut — that we should limit the scope of what falls into the realm of UI. I think look-and-feel might be a better overarching category, but even that is too broad. The underlying flaw is that practical UI is rarely formally tested and less frequently permanently linked to business objectives.
- Business Objectives
- Marketing Objectives
- Functional Requirements
- Development
- Testing
- Usage
Such that any shift in one puts pressure on the others. It is connectivity that provides for not only rapid development, but presents the possibility of instantaneous development. Being able to modify a product this way depends wholly on being able to pick up the thread and see where it tugs. Before this was left to intuitive judgments, which were imprecise and incomplete leading the product into an inevitable “slow drift” away from the original business objectives.Imagine that you wanted to capture a certain “feel” as a marketing objective…
Why? Well, let’s say that you believe “slippery” is the feel that would increase sales for a certain segment (amphibian programmers, say). If you can make that testable connection, even if it proves that there is no correlation, you have created an underlying framework to test your inference.
Even the softest requirements should be “connected” to business goals. If creating such connections seems like too much trouble for the requirement, chances are you’re not dealing with a requirement in the first place.
