Last week at Midwest UX, Uday Gajendar gave a talk called The Wicked Craft of Enterprise UX in which he noted several ways he has used UX design artifacts (diagrams, wireframes, etc.) with non-designers in order to facilitate communication.

This talk wasn’t really anything new to me, but it was validating, because I’ve been doing that for a long time and I thought I was just making something up, or misusing the tools. Talking to other people afterward, it seems like a lot of us do, and we all thought we were alone doing it.

There’s a perception among us that there’s a right way to use diagrams, models, flow charts, wireframes; that there’s a right time to use them in the project, and that they’re just for designers, or at most that you present them to clients as background justification for a final design that you’re unveiling–but this is fundamentally the wrong way to think about them.

Design artifacts are not just deliverables, they are communication and collaboration tools, and communication and collaboration is core to every designer’s job. You can use whatever tools you have in your toolbox however and whenever you need to in order to make that communication and collaboration happen. Mix and match, make up new tools, there is no pure process and every project is different.

So in the interest of spreading that mindset, here are a couple of examples of using the tools in perhaps unconventional ways. Both of these examples use wireframing tools, but really it could be anything.

Managing client requests

This was a bad project for a number of reasons, but one of them was that we had somehow gotten to the point where development was basically at the mercy of the client’s every whim. Every couple of weeks the client would have a new genius idea, and that would be the most important thing until the next idea came along. The project manager did his best, but the client would not commit to any long-term priorities.

In one meeting where the client had just brought up something new, I brought up a wireframing tool (the meetings were remote, no whiteboard sketching here) and started sketching out what the client was describing and asking questions. Actually showing the client what it would be like to try to use what they were asking for and how it would interact with the existing system showed that maybe this wasn’t such a good idea, or at least that it would be far more complex than expected, and having the finished wireframe at the end of the meeting that the client agreed reflected the idea accurately was enough progress on that idea that we were able to get other things done instead of being jerked around by new things all the time.

Wireframing became a go-to technique in many future meetings with that client.

Getting requirements out of people’s heads

On another project, I basically needed to design a CMS that included a huge amount of metadata for each item. I was working directly with several of the people who would be entering the data, and they had a general idea what would be needed but I was having trouble getting them to express it concretely or consistently.

I broke out a wireframing tool in this case also, which helped them move from “what might it possibly be” to “what will it be like to enter this information”, which helped draw out concrete statements about what each thing could or could not be. The tool helped them think about the information more directly, and we were able to try out the sketches we created together against some of the real data to validate them.