Category: Practical Matters

Related to earlier posting about too many systems. Process is nothing bad or evil in itself; it’s just the risk of process becoming a burden that sucks out the “life” (ie, nimbleness, fluidity, momentum, passion) of a team and project overall. Also other things related to that, at a psycho/perceptual level: a feeling of “on-demand” or “on-call”, that the work just becomes tedious administrative tasks, a sense of “another thing I gotta do”, the pressure of “gotta please the manager”, etc. Rather than spending the actual hours/effort getting the real design work done, that speed along the necessary progress of getting a good product out the door.

One of the biggest challenges when designing a new product (or significant revision to existing product) is to get everyone else in the company behind you and the project. A sure way to do that is to build out (in prototype form) the most visible, core functional areas that are ever-present in the product, like the main navigation and branded panels (ie, the chrome) to make it really seem like it’s coming alive. PM’s, VP’s, Directors, Leads from other departments can connect to that easily. Else it’s just pretty pictures all disconnected from separate prototype pages/components that lack coherence, too random, not congealing…gotta make it “real” as THE THING TO BE for all to look upon and point to.

As a team evolves its own internal user experience competency within the overall corporate machine, a hi-risk danger arises when the “informal” becomes the “formal” , with the introduction of processes, systems, protocols for everyone to follow. The team gains more people, more tasks to do, the workload increases and schedules shorten. Tempting to clamp down and insert some ways to regulate and control, but need to remember the balance/moderation ideal. And don’t kill the great momentum from the earlier informal days when the team first started…

One of and perhaps the hardest aspect of re-designing a product with a new visual treatment is selling the design both internally and externally. As a former manager told me, “design is pretty easy; it’s influence that’s the hard part.” This has to do with a savvy awareness of the internal political and power structure, as well as the cultural norms, and taking advantage of whatever chains of communication that are readily available, in an effective manner.

As for external selling to customers, massive validation plans and formalized processes that are heavy/burdensome in either time or money are not effective. Instead, it’s best to tap into a small alpha tester pool, informing them of the new design direction and soliciting input via emails, rather than a focus group. The email questions should be targeted for specific concerns if there are any; else you’ll get feedback like “that’s nice” that vaguely suggest but not concretely advise.

As the spec writing process starts to gather steam, routine check-ins and reviews need to occur to ensure accuracy, and more importantly, capture any missed issues or conflicts/confusions with other members of cross-disciplinary team, particuarly QA or Development.

The reviews are not a time to go through word by word every single line or what’s written, nor is it a time for “committee writing”–simply unproductive! Instead, the weekly reviews should be a time to identify major issues that cropped up during the writing, gaps/deltas, and potential conflicts with what’s been prototyped vs. developed or tested. High level issues should be surfaced and debated, not tactical tweaks.

Before the weekly reviews, the spec writer should be in constant touch with the designers and QA, having a tight feedback loop on getting inputs, making sure changes to the design are communicated, etc.