Using Design Artifacts with Stakeholders

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.

Notes from Midwest UX 2015 Day 2

These are my notes from day 2 of Midwest UX, held October 2-3, 2015 in Pittsburgh, PA.

Table of Contents:

Read More

Notes from Midwest UX 2015 Day 1

These are my notes from day 1 of Midwest UX, held October 2-3, 2015 in Pittsburgh, PA.

Table of Contents:

Read More

Experimenting with Pattern Libraries

I’ve been experimenting with pattern libraries lately. They’re useful to have so developers can put things together quickly without reinventing the wheel (I once provided a pattern library for a team that had reimplemented some of their basic design patterns at least 6 different ways before I helped them unify everything) and they help the design team think about things consistently and meaningfully (having to add another pattern to the library makes you start questioning why this particular region needs a different style). But they can be awkward to put together and difficult to make sure all of the design changes continue to be added over time–and once they’re out of date, they’re worse than useless.

I’ve recently discovered Pattern Lab, which produces a pretty nice basic pattern library off of a bunch of templates, and that solves the first problem, but the problem of maintaining it over time remains. In fact, the problem could even be worse–with something entirely custom, you might be able to build it off of the same template system that’s used in the real site, so there only needs to be a change in one place, but with the generator you’re almost certainly using a separate code base, so all changes need to be made twice.

So I’ve been playing with making a conversion script that takes the patterns from Pattern Lab and converts it for a couple of different content management systems I use. So far I have it working for Django, Jekyll, and Statamic; I have tried but failed to get it working in Perch and Drupal because some of the things that need to be done in those environments is difficult to automate based on the Mustache templates that Pattern Lab uses.

The code for the script is on Github, and I’d be delighted if you used it on your own projects, forked it, modified it, added more output CMSs, etc. if it is a thing you would find useful. I hope it’s well enough documented to get started, but if you have questions, please ask :)

Notes from Web Design Day 2015

These are my notes from Web Design Day, held on June 12 2015 in Pittsburgh, PA.

Table of Contents:

Read More

Notes from IA Summit 2015 Day 3

These are my notes from day 3 of the Information Architecture Summit, held from April 22-26 2015 in Minneapolis.

Table of Contents:

Read More

Notes from IA Summit 2015 Day 2

These are my notes from day 2 of the Information Architecture Summit, held from April 22-26 2015 in Minneapolis.

Table of Contents:

Read More

Notes from IA Summit 2015 Day 1

These are my notes from day 1 of the Information Architecture Summit, held from April 22-26 2015 in Minneapolis.

Table of Contents:

Read More

Reading List 2

I've been migrating my blog from Wordpress to Jekyll, and in the process I've been going over some of my old half-written drafts. This one is from 2011, and all it had in it were two links. I have no idea what I originally intended to say about them, but they're both interesting, and they're both roughly about finding failures early to get to a better outcome. This is something I try to do in my own design process: embrace the possibility that I am wrong, try alternatives, and maybe I'll find something better.

Pixar's Motto: Going From Suck to Nonsuck

Pixar's film development process involves many iterations of storyboards before they even get to a script, and even then they still iterate and critique and may still be working out problems in the story shortly before release. The idea is to "be wrong as fast as we can," and every piece of the film will be picked apart repeatedly before they finally get to something good.

Visual vs Action Oriented Design

This article is about game design, and in particular about how often games start out with a general idea of how it looks and feels, which are easier to sell, but neglect the basic mechanics, which are ultimately what make a game fun. Focusing on the mechanics can allow game designers to iterate faster to get to something fun, like Pixar's storyboards. However, the prototypes will be ugly and abstract and harder for executives and players to connect with.

What are design docs?

I've talked to several people lately about potentially helping projects they are working on with the design. As a designer coming into a project, it's helpful for me if I can see the design work you've done already so I don't duplicate work, step on toes, or go in a different direction than has already been decided on. A lot of people have no idea what sort of thing I'm looking for though, so here are some things I find helpful (though by no means an exhaustive list!), and several of them can be useful to non-designers, too!

Note that it's absolutely ok if your project doesn't have these. They're good to have, but if you don't, that's good to know, too, and a designer can help you create them!

Project Goals

Basically, what problem are you trying to solve? What are your overall goals, how do you plan to achieve them, how will you know if you're successful in achieving them?

Ideally, a design starts with some problem you're trying to solve, then do research to verify and clarify the problem, come up with a number of possible solutions, and then validate which one will solve the problem best. But to be perfectly honest, the only projects I've worked on like that were in design school. Most projects seem to start with a pretty hazy idea of the project goals, if that, then jump straight to how to implement the solution. That's ok, but you do need to figure out what problem you're solving before you know if your solution is solving it well or not.

I've found these things to be helpful not only to me in designing and validating designs, but also for keeping conversations and features focused. Goals help you decide what work is important, what isn't, and what features outright detract from your purpose.


Any research involved in creating the goals and plans above, or research suggesting changes in your audience over time and how people are actually using your product. This can include contextual research, interviews, usability studies, market research, surveys, statistics and analytics, or really, any other work you've done talking to people about the problems you're solving and how they use your product—it doesn't have to be formal, anything you have is useful.

If you don't have the up front research about your goals—or even if you have, since things can change over time—it might be a good idea to have your new designer do that now with the people who are currently using your project. You may find out that it does poorly on the things you thought you were doing, which can sting if you're really attached to the idea, but that people are using it to solve an entirely different problem, which can be really enlightening. These are good things to know, and you can take them back and revisit your goals and solutions.

Style Guides

These can be visual and granular like what colors to use and how to style buttons, more structural, like what context calls for what sorts of widgets, or verbal, like what tone of voice to use in different parts of the interface. They can also include design assets like logos, photoshop templates, color palettes, etc. Here are some examples of nice ones:

Style guides are useful to maintain consistency across the whole system and help developers put new pages together faster using existing patterns, but to remain useful they have to be kept up to date with new design patterns as they are added.

Other Design Artifacts

  • information architecture (think sitemap, or more generally, what things should be grouped together?)
  • interaction descriptions or diagrams (when this page is displayed, if user clicks this do this...)
  • sketches, wireframes, mockups, and prototypes
  • discussion surrounding all of the above

If you haven't had a designer before, you may not have anything formal, but even just sketches, annotated screenshots, and white board diagrams can be helpful. And in particular, if there's an online record of the discussion on new features, for instance why something was done one way and not another, that can be particularly useful in absence of more formally documented style guides and research.