Artifacts that can improve UX

Yesterday at work, we gathered in a conference room to hear from Jay Mathews of Straight Line Media on user experience and software design. 
How can any of us understand a design from a list of requirements or even user stories? How can we hope to communicate with product owners and stakeholders what we propose to build? Mathews suggested these artifacts:

• Low-fidelity sketches (6-8 hours for many) of a proposed GUI are typically created with a whiteboard and can quickly generate and communicate ideas and discussions to try to find a working approach. Drawing out several sketches can allow us to combine vastly different GUI approaches to come up with a better visual design than we can fathom via requirements alone.
• A vision document (2-8 hours) answers the question “what are we building” at a high level. Perhaps it is just an overall definition of the system, four meaningful paragraphs of detail, and/or a visualization of the system we intend to build.
• An experience map (10-15 hours) can describe the end-to-end experience for users
• I discussed personas in earlier blog posts – formalizing our personas help us understand about our users and get on the same page.  It helps get us out of our own experience and bias and reveal what we don’t know about
• Much like a user story map slice or customer journey, a scenario a set of interactions that a persona would interact with the software system.  Scenarios are story-driven, told in human terms, focus on what the user can accomplish with a yet-undeveloped system.  The user’s outcome, overall experience, and emotions are the focus here—not merely what they can do with the system.
• A conceptual architecture diagram (15-20 hours) answers “how is the overall system going to work". It overviews both the concepts and the core structure of the proposed system.
• Detailed site architecture diagram – depicts all unique pages/screens of an application and where each lives in the application’s hierarchy.
• A user flow diagram details the path a user follows to complete a specific task.
• Wireframes (3-6 hours each) communicate fundamental details about the functionality, content, navigation, and interactivity of a screen or a page. This sometimes is the final deliverable of a design.
• Prototypes (8-20 hours) help us to visualize a specific interaction with actually functioning software.

(Mathews mentioned that Agile “user stories” are “more like requirements” and thus differ from scenarios. I’d argue that the distinction between requirements and user stories is very important; indeed, both are different from scenarios.)
I believe that the best software results when we value working software over comprehensive documentation. That doesn’t mean we dismiss creating these artifacts, as some misunderstand Agile to demand. Instead, we create just enough of these artifacts as needed to create good software, and no more. We must constantly be examining ourselves to see if more documents would be useful. These documents can be highly polished or quick-and-dirty, whatever is appropriate for your purpose.
Mathews also encouraged us to do usability testing, and I completely agree. He said, “Small improvements can yield big results.” Testing with even just a few users can reveal flaws that are crucially important to fix. He recommended a formal session with a trained facilitator, but any usability testing is better than none. I’ve seen numerous ways of doing real user testing; one promising service is YouEye, where you can in mere minutes get a usability test going for any public web site.
To Mathews, UX expertise is nothing but the intersection of empathy, analysis, and intuition about our users.  We must visualize our projects—the visualizations don’t have to look pretty, but they do have to communicate what we are going to build.
Mathews recommended Goodwin’s Designing for the Digital Age for more on these topics.