Standards development for industry applications(by yesterday :-)

18 May 2007 - 4:41pm

Last reply:
7 years ago

1 reply

730 reads

Pawson, Mark

2007

I'll second Dmitry on this.

I am a one man UI team in an international company with Web and Thick
Desktop apps. Ghosts of UI teams past had written hundred page spec docs
for just the desktop app which I know few developers have read. In
response to this I and my mgmt agreed that it would not be good value
for me to repeat the mistakes of the past. Instead I wrote a highlevel
guide [16 pages - I was trying to keep it to five ;)] that referenced
the Windows Vista Guidelines for those who want details. Jeff's reply
gives you some more that could be used.
A lot of my document presented principles of usability from a
literature search. I used links to design patterns sites such as
Designing Interfaces by Jenifer Tidwel to provide examples of these
principles. There is also the beginnings of a company specific section
which I put together from past UI team style guides and from my own
expert reviews of some of our company applications. As we finish
projects, lessons learned and good design will go in this section.
Eventually tying this all into a central UI library either built in
house or purchased would be ideal. Some commercial products we looked at
that offer this arehttp://humanfactors.com/products/usability-products.asp andhttp://www.guiguide.com/

So my document is really a high level shell that represents the start of
an internal style guide. But it has immediate use for developers who
were looking for context, ideas for their applications, a place to start
or just as fodder for me to refer to why I make the design decisions I
do :).
Finally, as Dmitry says communication is key. However, make sure you
have an executive champion who supports your work, otherwise you'll
continue to write docs that no one reads.

Mark Pawson

Comments

One addition to the kind of documents Mark mentioned that I've found
to be particularly effective are one page persona summaries for the
products being developed. I've seen these end up living on the wall
in the developers team room alongside the project tracking info -
acting as continual reminders about the product is for.

I'll also second the recommendation of Jenifer Tidwel's book. In
addition to being an excellent book - it also has the advantage of
coming from a company primarily known for technical development
books. Makes it a much easier sell to developers.

Even more effective than documentation and book recommendations is,
of course, sitting down with the developers while they're designing
and building the product. Find the time to do this if at all possible
- it'll help everybody involved :-)