- Proposition: What is it we're offering the user? Is it to buy a new pre-specified car or to customise their car and then buy that?
- Concept: What is the idea behind it? Is it that you can define the attributes of your car?
- Structure: How is the task structured? How many steps are there in the process?
- Information: Is all the information available when the user needs it? Are we throwing up an error message because the user hasn't chosen the colour of the seats when we're only allowing them to do that on a later page?
- Interaction: Do all interaction elements (buttons, links etc) do their jobs? Is there a link to the terms and conditions on the page where we ask the user to confirm them?
- Appearance: Do layout and design enhance the process? Do different page layouts confuse the user?
Generally speaking, problems should be solved at the highest possible level of abstraction. This is also why jumping to solution mode when faced with a usability problem is detrimental to the final usability of the product. When we go straight from problem to solution without the benefit of analysis, we tend to solve the problem at a low level of abstraction -- changing the colour of a button instead of making sure the user's goal can be solved by the application. It is also one of the distinguishing skills of a good usability person that they can see which level (or combination of levels) a problem should be solved on.