UIEtips article: Getting the Most From Design Deliverables
January 29th, 2008
For today’s application designers, one of the biggest challenges is getting the vision implemented the way we imagined it. In our mind, we can clearly see the design in all of its interactive goodness. Yet, when it emerges from the development process, it doesn’t work the way we thought it would.
Unless you’re doing your own implementation — practically impossible for a serious production application — you need to find a way to succinctly communicate what’s important and how it should all work. Today, in our UIEtips email newsletter, we published my latest article, where I discuss how the best design teams go about successfully communicating their ideas to the development team. I think you’ll really enjoy it.
I also recently had the pleasure of chatting with D. Keith Robinson, Creative Director of Blue Flavor, who has tackled the problem of communicating design ideas to his development team. In our chat, Keith shares some of his experiences developing methods that get the entire development team on the same page. I highly encourage you to listen to our conversation.
How do you communicate great interaction design ideas to your implementation team?
January 29th, 2008 at 1:28 pm
I am pleased to say that I have been a long time convert (thanks to the UIE) to paper-prototyping. In our organization, we use a “more advanced” paper-prototype by preparing Visio(tm) documents that use some of the advanced features of Visio(tm) like hyperlinks. Then we publish those documents to a web server so the stakeholders get an idea of interaction.
To address the edge events, we also hold “what-if” parties (Joint Application Development [JAD] meetings) where we talk about edge events. Most of those events identified can be mitigated with validation and user friendly prompts/exception messages, but it is best to make sure that all stakeholders (or at least a significant majority of stakeholders) participate.
Then as a final opportunity for input, we post the results of any JAD meeting to a private project wiki in a Request For Comment [RFC] type environment where we open the results to comment for an agreed upon period. We keep the development team moving forward during the RFC period but they all know that their work is in a ’soft-state’ until the JAD RFC period is closed.
January 29th, 2008 at 4:19 pm
I’ve found that it’s often about creating the artifacts of conversations (storytelling), and doing it as if you had to pay for your own time.
For a recent internal sales conference, I found that our ‘before’ and ‘after’ shots didn’t really tell the whole story — nor did adding bullets. Instead I animated a story around the screenshots with a conversation — it’s literally about capturing and/or retelling the story.
There should also be no such thing as a ’standard’ approach — more a collection of paintbrushes to choose from. If the destination of the design is SharePoint, a good UX pro can create the production versions of pieces of the design (e.g. link lists), faster than they can draw it up for someone else to do.
We’ve got to get a lot smarter about what we’re doing.
The end goal is always to shorten the distance between the need and the result.
February 2nd, 2008 at 1:09 pm
In the past we have put our designs up on a wall for team walkthroughs, giving people an opportunity to provide feedback.
Moving it away from the confine of the screen and onto a wall can really help communicate the design to a wider team and promote buy in.
February 6th, 2008 at 2:41 pm
We’re in the process of including more deliverables than just providing remote testing video footage, a report and the updated mockup. There also needs to be baseline metrics to summarize the design and its potential. We also have a component to deal with the emotional side of design, considered within its context.