I was talking with a friend about car configurators, which is a topic I spend a lot of time on.
He was discussing this idea about inline config, having a small window open at specific times and ask the user to add or select an option.
In essence, a very good idea, I have several prototype screens for this sort of thing.
The problem became that the designers were struggling to figure out how the window operated, how it minimized, how the user re-activated it, and so on.
Here’s the root of the problem : They devised a Method that did not support the Object or the Action.
The super-duper Tigerstripe Approach tells us every task-based design problem has three main components. In this case they were The Car (The Object), letting users do partial configs (The Action) and the small floating window (The Method).
When one starts with a method, as many people like to do (“Dude, what if it just popped up there randomly!”), problems usually arrive.
Similar problems arise when a site-based method or set of rules is used inflexibly for all manner of data display or user interaction.
Here’s a tip, go in the right order :
Q: What are we talking about?
A: The Object
Q: What is the user response we want to promote?
A: The Action
Q: What is the best way for the user to interact with the system?
A: The Method
Save yourself some grief, there’s a reason UX is a different discipline that UI.