Communicating design is at least as important as creating quality user experiences. Whether a design gets built or not depends a lot on how well that design can be communicated to others. No matter how wonderful an interaction looks in a wireframe or prototype, it needs to be built in order to be of use. If your business partners won’t fund your designs and your development team can’t build them, they are little more than portfolio fodder.

Lately, I’ve been thinking about the design process a lot; this article on Communicating User Experience couldn’t have come at a better time. It hits on many of the points I’ve been talking about at work over the last few weeks. Namely, the importance of involving key partners in the design process. When partners such as the technology team are handed a completed design at the end of the process, they aren’t going to react well. If, however, they are involved earlier in the process, they are going to buy into the design. After all, they helped create that design.

Another key aspect of communicating UX are the deliverables. Yes, yes, I know we’re not supposed to be in the deliverables business. However, if we can’t accurately convey how our design is to function, getting it built the way we want will be difficult. Unless the designer can pair program with the developer, there will need to be some form of documentation. This means we need to consider the user experience of our deliverables no matter what form they take–wireframes, prototypes or otherwise. How do we work towards ensuring good UX in our deliverables? Empathy, which goes a long way here.

We know that putting ourselves in the user’s place can help us create a much better experience. When it comes time to communicate our design, our users are the people that read our documents. Knowing something about how they work, their processes and the constraints they work within are important. If you want to improve your deliverables, spend a little time with your partners. This may include testers, analysts and product managers, depending on your organization. Find out how they use the deliverables you create–and they sort of pain those deliverables inflict. As with any kind of user research, you’re likely to be surprised what you find.

Leave a Reply

Your email address will not be published. Required fields are marked *