Software development begins with requirements documentation. This is the time when we get to brainstorm and imagine what you want your new system or site to do in the easiest possible way: we talk about it. As things become more clear, they get written down in a document so we can remember and review what we are going to do. This document will contain several key things about the system or site that is to be built. First, it can contain a statement about the business purpose of the site or system so that everyone is clear about why we are doing all of this work. It will also contain several lists of people who are concerned with the site or system to be built: a list of the stakeholders and what their interests are, the signatories who are the final decision makers for the design, and the different user groups and what their overall functions are in the system. It also contains a data dictionary, which is a list of the kinds of data the organization uses, and a list of functions which means fairly detailed descriptions of what the different users actually need to do. It contains a list of reports that will need to be produced by the site or system for administrative oversight, and a description of the business requirements.
You can see a screen shot of a sample requirements document here: requirements_ss.png.
UX design documentation can take many forms. We make make diagrams with little stick figures and bubbles, called "use case" diagrams. This is very simple - it means we graphically show the different users of the system, along with what they do, and how their work flows and interrelates to one another. There may be flow diagrams, data state diagrams, and all kinds of other pieces of documentation. The thing to remember is that all of this is meant to make it easier for you or for the programmers who are going to build the system to understand how things are supposed to work.
You can see an example of one of these kinds of diagrams here: text_message.pdf
These are very undetailed, almost cartoonish quick drawings of the screens and application flow overviews that show what your system or site is going to look like. These are very useful for quickly creating an easily understood sense of the flow and nature of the new site or system. At this stage of development, it is easy to introduce changes and discuss features, because changes involve a pencil and an eraser and perhaps a new sheet of paper. Storyboards help to establish good communications between potential end users of a system and the designer. and the programmers.
See an example here: storyboards.pdf.
Wireframes are just what they sound like - more detailed black and white screen designs with line drawings of tabs, buttons, fields, and such, which represent more exactly how your site or system will function. Wireframes include very exact descriptions of the behaviors of individual objects and elements.
Wireframes are useful because they are still simple enough to change easily. They also focus the attention on the logic and function of the screens, instead of the color and look. The color and look need attention too, but nice looking graphics without good UX decisions makes for bad software. Wireframes focus like a laser on what really matters to make great digital products.
See an example here: wireframe.pdf
All of this leads to some kind of final design: a web site, a business application, some kind of digital infrastructure. The design documents may include a go-live plan, a data migration plan, user acceptance testing plans and results, and that kind of thing. The design efforts are very heavy up front, but they can continue into the programming and development phase of the project. Soon enough the design will be realized, and the system can be deployed. Everyone can pop a cork and celebrate the deployment of the beautiful new system!
You can see an example of a final design screen here: phv.png