Regarding the topic stuck in “P” mode, I forgot I posted a comment on another blog here. Yes, it is an interesting article worth reading. In my experience I’ve worked on several different applications where the “tool” was prioritized over the user. Take my prior job for instance. I recall many meetings with developers instructing customer service support with sentences that begin with “alls yuh haff tuh do is…”
…I hate that sentence! It’s the prefix of an incoherent explanation that defines a complicated program model that falls nowhere in the ballpark of the typical user model. User models tend to be simple. Many of us developers tend to add complexity to these simple models to justify the misdirection of our development practices. A simple user model could be something like, “I need to print customer addresses for shipping labels.” A typical misdirected developer extrapolation would begin with the muddy details of existing (bad) code that prevents access to access to the address for customers outside of the context of an opened order. Rather than focusing on the need of the user focus is placed on adding features to (read poking holes in) the “tool” to support printing shipping addresses. Complication is added through the introduction of a feature that allows an order to be quasi-opened or pretend-opened. The feature complicates other order processing done in the warehouse as people wanting to close orders get locked out due to the pretend-opened order on the other workstation on the other side of the warehouse where a missing shipping label needed to be reprinted. That creates the need for another made up “feature” that allows users to close orders that are opened elsewhere. Now you have “close” and “force-close” options in order processing and a need to explain the difference. The sentence structure you choose will no doubt start with, “alls yuh haff tuh do is…”
**Update**
I wrote this short post many moons ago but it still rings true. To add clarification to the “poking holes in” comment above, developers typically poke holes in a crappy program component that doesn’t follow OCP. These holes are work-arounds to the cancer of bad design that nobody wants to touch for fear of the entire application toppling over. We poke holes to add back-door features then we instruct others with “alls yuh haff to do” then the most arrogant of us will grimace when a consumer of our product is puzzled to our overly complicated design. Don’t act like it’s just me. We all over-engineer I’m just the first to admit it!
Can't see nothing but the source code 
I agree. But don’t you think the problem is the more general purpose nature of the underlying software/tool?
We may have to rethink the interface as a set of How To …. (print labels, close orders or whatever). I thought that is what wizards tried to do.
I personally think user interface is more complex than getting the job done since no two users of your software are at the same.
Exactly! User interface development can and should be more complicated than getting the implementation done. My belief (or religion you could say) is that if you focus on the use case then the implementation becomes simpler. Outside-in development practices start with prioritizing the task that a particular user needs to perform (use case) and breaking it into smaller pieces, each of which are driven by glue-code that supports the original use case. Thinking “how to enter orders…” would lead you down an entirely different path than thinking “how to design an order writing object that I can use in any given UI.”