No, I’m not the “decider” (especially as a consultant, where I primarily “recommend” :-) But in the course of product development whereby the design of the UI colors the overall user experience (initially expressed as the prototype), decisions about “which widget goes where” are critical. Such decisions must be regarded seriously in terms of consequences upon the page layout, user interactions, system responses, technical abilities, etc. A few things to keep in mind about these vital decisions:
1. Make sure all the relevant parties (engineering, marketing, QA, doc) who can/will be affected by the UI decision are in the room together to hash it out in real-time.
2. Once a decision has been made (achieved via consensus or collaborative weighing of pros/cons), record it, commit to it and give it a deadline. A common problem is lack of follow-up or accountability for a design decision, or simply lost in a flurry of other decisions.
3. Designers love to make all kinds of artifacts/deliverables, but due to constrained time/resources/dependencies, the designer should ask herself “Does this artifact move us towards better design decisions?” or is it something simply to “help the client feel good” or for internal bureaucracy/political goals? (ie, furthering the machine of bureaucracy for the sake of Process)
Designers should create (and send onward) only those artifacts that are meaningful towards helping the client make a decision about the UI. For example, a designer may rapidly sketch out with his pen several possible solutions or a quick concept map of system objects to help him think through the problem, as a natural part of his process. But should he take the time to scan in those sketches and send them to the client? Should he spend the effort to rebuild them in Visio or Illustrator as a formal document? Only if the result will help the team make decisions about the problem and solution…and of course move everyone closer to the prototype!