software-development archives

Design requires communication

Cameron linked over to D. “CMYK” Keith’s recent article on Tips for a better design review process, a topic on which I’ve been collecting thoughts to discuss here. The act of presenting, explaining, and defending your designs before stakeholders and customers should be a skill to be mastered by every great designer.

Design is communication. It requires it. Great designers should be excellent communicators, whether that be visual, oral, or written. Designers should dress well and accurately communicate with their personal presentation (which is our answer to Jason Fried’s question about suits). Designers’ homes and offices are often well designed and organized (tho painting kitchens Orange Toffee is questionable, Paul). The language and verbal presentation of a designer should also be refined and should communicate their message in a way that can be understood by that specific audience.

And the ability to stand in front of two or several dozen stakeholders and defend your design is one that is required anywhere design is critical (really anywhere you’re being paid for your design).

I recently experienced this in one of our biweekly prototype reviews, where new designs are presented and approved. Our designers are business analysts, visual designers, interaction designers, user researchers, information architects, and in this case, orators. I presented a section of the web application to a room of 20 or so top-level executives in one of the Church’s departments, and was tasked with explaining my design choices, defending those decisions, and mediating a roomful of helpful and not-so-helpful suggestions (sometimes from managers with little or no experience in that specific field).

Keith outlines good tips to becoming an excellent defender of design, and I’ll apply a couple of them to our work here:

And I’ll add one more to this list:

Design reviews are a must! They will strengthen your design and give you the critical feedback to make your work truly useful and impactful. What’s more is you’ll gain a confidence in your work that is impossible to gain elsewhere. Welcome and embrace these chances to elicit feedback and use them as reasons to make sure every design decision is completely bulletproof.

With these tips in mind, head into your next review prepared to communicate. Your design, your hours of hard work, require it.

posted by jason on Tuesday, Jan 23, 2007

Which is the prototype?

I got a funny request today, one that illustrates how cool our software development process is. The Lead QA on my project (let’s call him Blackbeard) asked me to put a watermark on my prototypes so he can tell at a glance that he’s looking at my prototype and not the actual working software. With multiple tabs open, it’s hard to tell which is which. And that is precisely the point! So I’m adding a watermark.

We’ve also been asked recently to put real data into the prototype to aid in the user feedback loop. My fear is without the tell-tale fake data we put in, our users might run into the same problem!

Our process we’ve developed here at the Church has the Interaction Designer working out all aspects of the user interface and feature set in a high fidelity (XHTML/CSS) prototype before the developers ever see it. This way, stakeholders and users can see what they’re actually going to get, not some bloated bullet list of hard-to-understand functions and use cases.

We then sit and work closely with the developers and QA to make sure what we’ve promised visually is being fulfilled in the working software.

The downside, it seems, is when the actual app is too close to the prototype and everyone gets confused.

posted by jason on Monday, Jan 22, 2007