UI Checklist for Developers

16 Aug 2005 - 1:49pm
8 years ago
3 replies
1764 reads
Iram Mirza
2005

Hi all:

I have to design a UI checklist that developers can use to ensure the
product UIs are all compliant with the copmany UI standards and guidelines.
Anyone have any suggestions on how best to present the data? I am thinking a
table format with links to annotated screenshots.

TIA.

--
-Iram

Comments

16 Aug 2005 - 3:50pm
Peter Boersma
2003

Iram Mirza said:
> I have to design a UI checklist that developers can use to ensure the
> product UIs are all compliant with the copmany UI standards and
> guidelines. Anyone have any suggestions on how best to present the
> data? I am thinking a table format with links to annotated
> screenshots.

You may want to consider the Patterns solution described in the article
below, depending on how large your collection of UI standards and guidelines
is or will become:

"Implementing a Pattern Library in the Real World: A Yahoo! Case Study"
by Erin Malone, Matt Leacock, Chanel Wheeler
http://tinyurl.com/9cbb5(*)

"We designed and built a repository for interaction design patterns, created
a process for submitting and reviewing the content, and seeded the resulting
library with a set of sample patterns. We organized the content to make it
findable, structured the content so it was predictable, and tested and
iterated the design of the user interface of the tool to make it usable.
[..] The pattern library allowed our small, centralized group to tap into
the broad expertise of the Yahoo! design staff. What would have been
impossible to write (authoritatively) by a small team is now being
contributed to and reviewed by an expert staff."

I have worked on a very similar solution when I was tasked with documenting
design knowledge for Nokia websites in 2001, and can vouch for the approach
described in the article.

(*) Original, long URL:
http://www.boxesandarrows.com/archives/implementing_a_pattern_library_in_the_real_world_a_yahoo_case_study.php
Peter
--
Peter Boersma | Consultant User Experience | www.UserIntelligence.com
Vlaardingenlaan 9 | 1059 GL | Amsterdam | The Netherlands
p:+31(0)204084296 | f:+31(0)204084298 | m:+31(0)615072747
mailto:peter at peterboersma.com | http://www.peterboersma.com/blog/

16 Aug 2005 - 5:47pm
Susan Farrell
2004

Iram Mirza <iram.mirza at gmail.com> said:

>I have to design a UI checklist that developers can use to ensure the
>product UIs are all compliant with the copmany UI standards and guidelines.

I recently made something like this. It was designed to be
lightweight (not much to read, looks simple, fast to use, so people
*would* use it). It was intended to be used by both the content
creators and editors in an iterative process. "Content" in this case
included all visible elements of a web page.

I made a spreadsheet with a list of short guidelines, chunked by
type. It allowed users to type N/A, 0, 1 or .5 into a cell for each
guideline. 0 meant non-compliance with the guideline. .5 was for
partial compliance, and 1 for full compliance. N/A meant the
guideline did not apply in this case./**

Rollover comments provided a paragraph or two of more information
about each guideline or examples. A score and percentage were totaled
at the bottom so that content providers could see if they met the
minimum standard for usability before they sent their content to
editors. The editors were to use the checklist independently, as both
a gating factor for quality and to help suggest ways the author could
improve the content for better compliance.

The purpose of such a checklist should be both to help people
remember what to look for and to help others help them overcome
design obstacles. If a person could design something better, they
would, so often the step of having someone else look at it and make
suggestions for improving the weak places is absolutely necessary. A
checklist with a two-step review (by self and other) and points for
partial compliance makes it easier to have that conversation.

The company I made this checklist for made a web application from the
spreadsheet so that the checklist will be available on the company
intranet. That's a good idea because it allows them to have version
control and to prevent accidental modifications.

In order to get the checklist up and running, we had a workshop with
the main stakeholders, where we all rated some content together and
looked for big discrepancies in our scores. We discussed score
differences and ambiguities for each guideline, and in some cases,
together we changed the wording of the tool to better reflect user
understanding and to make the guideline more objective. This was an
absolutely necessary step for both buy-in and consistency of use. It
took most of one day to test about 75 guidelines against 4 sample
content pages, with about 40 people. We characterized it as a
workshop to test the tool, but it was also a stealth training
exercise.

I can't emphasize buy-in enough. I've worked on a lot of style guide
type projects, and getting people to use them is the biggest obstacle
always. Everyone must understand WHY the standard is better when they
want to do something other than the guideline suggests, especially in
companies where developers have their own foosball tables. In the
case of a checklist, this generally means you need a document with
rationale that everyone can refer to when needed.

Sometimes allowing for some invention within the guidelines is what
it takes to get buy-in. Sometimes incorporating other style guides by
reference is the way to go, so you can stand on the shoulders of
giants and tweak a few things that need it for your company. It saves
money too, when you give people a checklist or company guide but
refer to a large volume of reference material for those who need more
information.

I really like your idea of annotated screenshots, especially if you
have standard dialogs and layouts to show that are in very common use
by developers. The more diverse the UIs and developer tools, the
harder it will be to make all the examples applicable, though, and
that can be the rationale for breaking compliance with the guideline.
In an environment where everyone makes their own dialog boxes, but
there is One Right Way to do it, this would be an excellent way to
go, however.

Pictures are better than words if they are almost always applicable,
but words are better when a philosophy, process, or principle is the
standard rather than a look and feel.

On the downside, people will often simply copy a suboptimal design
rather than potentially making a better design that also conforms to
the guidelines. Or they might copy the obvious but less important
visual design aspects and ruin the interaction design that's less
obvious in a picture. Plus, pictures become obsolete and must be
maintained more often.

Annotations could help guard against these problems, as would
multiple examples that look different but each comply. Animations
might help too. You could also reward best-of-breed designs by
including them in the examples.

Best of luck with your project,

Susan Farrell

16 Aug 2005 - 6:05pm
Adrian Howard
2005

On 16 Aug 2005, at 19:49, Iram Mirza wrote:
[snip]
> I have to design a UI checklist that developers can use to ensure the
> product UIs are all compliant with the copmany UI standards and
> guidelines.
> Anyone have any suggestions on how best to present the data? I am
> thinking a
> table format with links to annotated screenshots.
[snip]

There's some nice advice on producing usable usability standards
documents at <http://www.humanfactors.com/downloads/aug04.asp>.

Cheers,

Adrian

Syndicate content Get the feed