What I can do
On this page I've outlined what I can do in terms of writing design specification documents and planning design efforts. I've also summarized the benefits to your users, programmers, designers, and business stakeholders.
I Write Design Documents
On most projects, I’m usually responsible for delivering some form of Functional Specifications Document. This document describes the complete behavior of the system from the user’s point of view, and explains the business rationale for the design decisions.
Most spec documents I’ve seen, frankly, suck. They’re often written after development has begun, and don’t clearly and completely describe design ideas and rationale. Programmers hate to read them because they aren’t specific or thorough enough, and everyone else hates to read them because they’re boring.
My spec documents are written before any visual design work starts, and are updated often. They’re thorough but brief (because no one reads 200 page spec documents). They use simple screen illustrations, and explain requirements in plain language, not the legalese you sometimes get from consultants ("It shall be a requirement that...").
I’ve worked hard to learn what programmers, designers, and business stakeholders each need, and how to communicate to them.
I Help Plan Design Efforts
- Is your company systematically identifying and addressing problems with your web sites, search engines, and other systems?
- Is your information provably “findable?”
- How do your systems fare when tested using standard usability testing methods?
- Do you know, today, what your users like and dislike about your current systems, and how they expect things to improve?
If your projects have goals as non-specific as “update the look-and-feel” or “make it easier to use”, you probably won’t be able to measure the improvements or plan well for the next release.
Design goals should always be measured against business needs, such as:
- Reduce help calls and emails by 40% by improving the search system and document labeling.
- Eliminate inconsistent data in similar documents by improving the user interface of the Data Update Tool.
- Reduce the time needed to produce training documents by 30%.
Users Benefit
- Are you confident that you really know what your users need, and how they use the systems you’ve given them?
- Do you know, specifically, what they like and what they don’t?
- What functions do they use well, and which ones can’t they figure out?
- Most importantly, have your design and development efforts really made things easier for users?
- Can you prove it?
I can help figure out what your users and customers want, how to give it to them, and how to specifically measure user acceptance and satisfaction. I use fast, cheap user research and testing methods to help identify problems and opportunities for improvement.
Programmers Benefit
- Are your programmers happy with the specification documents that they get? Do they even get any? (Long emails written late at night don’t count.)
- Are they aware when changes to the specs are made, and why?
- Unlike a lot of interface designers, I actually enjoy talking to programmers about technology. I’ve worked hard to learn how to write specification documents that are helpful and clear to them, and which won’t just sit on their desks unread.
Designers Benefit
- Are your designers designing for your users, or for themselves?
- Do they know what information users need, and the language they need it in?
It’s not enough to tell a design team “make it easier for users to find our technical documents on the intranet.” I cooperate with visual designers from the start, to insure that they know how your users behave and what they really need.
Business Stakeholders Benefit
- Do your design efforts address real business problems, with measurable outcomes?
- Are real business goals represented in the specification documents your group uses?
- Do representatives from the business wonder why they weren’t consulted, or why some crucial piece of information wasn’t included in the new system (and can’t be added now)?
I interview business stakeholders at regular intervals during a project, both for requirements gathering and for design sign-off.