User Interface Design Style Guides are not dead, the just smell funny

Usability User Experience User Interface Design
User Interface Design
Style Guides are Not Dead
THEY JUST SMELL FUNNY
Michael Bechinie | Head of Experience Design | bechinie@usecon.com
#UXPA2017 | uxpa2017.org
#UIDSG

#UIDSG 3Source: Museum Boppard

#UIDSG 4Source: didatticarte.it
Chair No 14

• New technique > bentwood
• One distinct style > variations
• Industrial production process
• Very successful business
• By 1930 Thonet had sold 50 million chairs
A solid construction plan, a style
guide and an effective production
process led to a successful business.
Thonet – a modern design company
#UIDSG 5Source: didatticarte.it

Todays’ IT ecosystem
#UIDSG 6

• Todays' business world consists of omni-channel
applications (web, mobile, POS, appliances, …)
• Especially business applications have mostly
web-frontends
• Many different tools out to document patterns,
based on code (HTML, CSS, JS)
Complex application ecosystem
#UIDSG 7Source: Bechinie

What challenges
do we have to face?
#UIDSG 8

• Often “good” screen and flow based interaction
patterns are not in place > nothing to be
documented
• Corporate and web style guides lack of
elements > not appropriate for applications
• Applications of today are extensive > prone to
inconsistencies
• Distributed projects and teams > communication
gaps
Cope with incomplete and
inconsistent design documentation.
Shortcomings in design management
#UIDSG 9Source: Pexels

• Dependence on UX / Design mindset of the
client > hostile attitude
• Will take a lot of time > (missing) budget?
• Added value is often not seen by the client
• Challenges of developing “modern” applications
within (IT) constraints
 E.g. legacy IT-frameworks > based on classical web-forms,
interactions were designed with (necessary) server
roundtrips in mind
 Mix of legacy system with current frameworks, like JFS (Java
Server Faces)
Style guide (SG) challenges

Benefits of SGs for different groups
Users Developers Business
End Users
More consistency leads to
reduced errors
Less frustration
Increased morale
Improved efficiency
Increased confidence
Reduced resistance to new
technology
#UIDSG 11Source: Gale 1996
Developers
Maintain control over
look and feel
Minimize reinvention
Capitalize on learning
Enable production of
reusable software
Reduce development time
Reduce arbitrary
design decisions
Business
Produce usable systems that
reduce support costs and
increase user satisfaction
Increase market awareness
Increase product awareness
Reduce training costs
Improve staff retention
Increase user acceptance of
new systems

How do we get there?
#UIDSG 12

There are different types of
style guides
#UIDSG 13

• Platform style guide (e.g. mobile, web, GUI,…)
• Corporate style guide (colours, typography, logo,
brand)
• Application family style guide (products within a
certain group of products)
• Application style guide (single application)
• Web style guide (for websites: contend focused,
pixel perfect)
• Development framework style guide (e.g.
bootstrap)
• Service design style guide (processes)
Style guide ≠ Style guide
Each SG type has a different goal
#UIDSG 14

Let’s focus on User Interface
Design Style Guides – UIDSGs
#UIDSG 15

• Preserve consistency within and between
applications
• Promote good design practice
• Get groups working together
• Provide repository for design guidelines and
standards
• Work as training aid for new members of the
product team
• Should be part of knowledge management
A UIDSG is a strategic tool for design
management.
UIDSG goals
#UIDSG 16

• Replace a detailed User Interface Specification
• Substitute step of interaction design
• Ensure usability per se
• Make sure that the application performs the
tasks required either by the end users or the
business
A UIDSG is (just) a piece in the
portfolio of different UX activities to
ensure the quality of a system,
product or service.
What a UIDSG can’t do
#UIDSG 17

• Develop pattern based
• Include also general usability principles
• Think from “Button to Business”
• Develop screen based patterns
 Page types (e.g. start, search, gallery etc.)
 Screen components (e.g. form, table etc.)
 User Interface widgets
• Interaction based
 Flows (e.g. switch from read to write mode, master > details)
 CRUD (C-reate, R-etrieve, U-pdate, D-elete)
 etc.
A clear strategy keeps the
development of an UIDSG on track.
Every UIDSG needs a strategy
#UIDSG 18
Source: Garret 2002

Lists
 info boxes
 figures
 tables
 document changes
How to Work with the UIDSG
Introduction
 goals of the UIDSG
 interface strategy
 intended user groups
 liability
 deviations
 IT framework
General Guidelines
 prioritized usability guidelines / heuristics
 accessibility
User Interface Design Framework
 structure of pages
 page types
 screen patterns
 interaction patterns
UI Widgets
 inactivity of UI widgets
 abbreviations
 text input fields
 link and button classes
 icons
 order of buttons
 list selection
 labels
 scrolling
Visual Design
 icon design
 colours
 sample screens
Default Settings
Online Help and Documentation
 guidelines for developing help content
Reference Documents
Icon List
Glossary
Screen Width Classes
Annex
Index
Every UIDSG needs a standard TOC to
cover important aspects of the
application(s).
UIDSG basic table of contents (TOC)
#UIDSG 19

Feedback
Consistency
Efficiency
Flexibility
Wording in the users’ language
Match between users and real world (mental model)
Clearly marked exits
Task orientation
Control
Minimize memory load - Recognition rather than recall
Transparency
Recovery and forgiveness
Aesthetics and emotional effect
Affordance
Nielsen, Molich Design Heuristics
#UIDSG 20
Source: Nielsen, Molich 1994

In which ways can an UIDSG
be implemented?
#UIDSG 21

• Single document
 E.g. WORD, PDF
 Stored on a server, intranet etc.
• Interactive
 HTML, Wiki: text with screenshots
 Interactive: try out components, code samples, descriptive text,
tables, screenshots
• Production tools
There is neither right / wrong nor a single
tool to develop and manage an UIDSG.
Single document vs. interactive
#UIDSG 22

Practicability of Production Tools
Tool Draw
Wireframes
Annotation
Wireframes
Visual
Design
Write main
UISG Body
Make UISG
Interactive
Export
Content
Word
PPT
Axure
Sketch
Markdown
CSS / HTML
#UIDSG 23
Low
Medium
High
Practicability

• Research project > experiments with tailored content, in
relation to user groups
 Only partly successful: people have the feeling to miss something,
good search wins over showing only tailored content
• Relevance of UIDSG changes over time for specific user
groups to different extent
 Developers > if patterns are developed and implemented in the
framework > no use to look it up in the UIDSG. Also valid for
colours > they are implemented in the CSS framework
 Business analyst (working with architecture tools) > they need
design patterns to write their functional requirements documents
 Tester > they need usability test cases to check the conformity of a
system against the UIDSG
The relevance of an UIDSG for different
groups changes over time.
Different content for different users?
#UIDSG 24

higher
lower
UIDSG
Relevance
Dev.
internal
Once the UIDSG
patterns are in a
dev. framework
Relevance once the UIDSG is in place
Dev.
external
Guidance for the
development of
components
Bus.
Use patterns in
business analysis
Test.
Use guidelines /
test cases to
check the UI
UX.
Develop consistent
patterns
Source: Bechinie

Is there a process the helps to
develop and manage an UIDSG ?
#UIDSG 26

UIDSG
development
(1) Initialize
and Plan
(2)
Understand
and Define
(3) Develop
(4) Evaluate
and Refine
(5) Deploy
and Train
(6) Lessons
learned and
Iterate
27
Accompanying
project activities
Governance, Promotors, Awareness activities etc.
Basic UIDSG development process

UIDSG
development
(1) Initialize
and Plan
(2)
Understand
and Define
(3) Develop
(4) Evaluate
and Refine
(5) Deploy
and Train
(6) Lessons
learned and
Iterate
• Goals
 Get funding
 Define team and UIDSG
owner
 Setup project and roadmap
 Define main goals for the
UIDSG
• Results
 Team in place with clear
responsibilities
 Prioritized goals
28
(1) Initialize and Plan
Accompanying
project activities

UIDSG
development
(1) Initialize
and Plan
(2)
Understand
and Define
(3) Develop
(4) Evaluate
and Refine
(5) Deploy
and Train
(6) Lessons
learned and
Iterate
• Goals
 Analysis of current state of
system / documentation
 Collect insights and feedback
 Define user group(s)
 Inspect tool stack
• Results
 Content strategy
 Results from reviews
 Target audience
 Tool-chain
29
(2) Understand and Define
Accompanying
project activities

UIDSG
development
(1) Initialize
and Plan
(2)
Understand
and Define
(3) Develop
(4) Evaluate
and Refine
(5) Deploy
and Train
(6) Lessons
learned and
Iterate
• Goals
 Define TOC
 Document / define needed
UID and IxD patterns
 Write collateral chapters
 Prepare icon list
 Provide conformity check list
• Results
 Main body of the UIDSG
 Accompanying material
30
(3) Develop
Accompanying
project activities

UIDSG
development
(1) Initialize
and Plan
(2)
Understand
and Define
(3) Develop
(4) Evaluate
and Refine
(5) Deploy
and Train
(6) Lessons
learned and
Iterate
• Goals
 Quality assurance by
different user groups
 Review content
 Test tool stack
 First signed off version
• Results
 Improvements
 Identification of missing
content
 Iterated, confirmed v1.0
31
(4) Evaluate and Refine
Accompanying
project activities

UIDSG
development
(1) Initialize
and Plan
(2)
Understand
and Define
(3) Develop
(4) Evaluate
and Refine
(5) Deploy
and Train
(6) Lessons
learned and
Iterate
• Goals
 Publishing UIDSG at the
target platform (single
document and/or interactive
version)
 Train the user groups
• Results
 In place UIDSG
 Interactive templates
 Conformity-test cases
 Icons and icon-list
 Informed and skilled teams
32
(5) Deploy and Train
Accompanying
project activities

UIDSG
development
(1) Initialize
and Plan
(2)
Understand
and Define
(3) Develop
(4) Evaluate
and Refine
(5) Deploy
and Train
(6) Lessons
learned and
Iterate
• Goals
 Quality assurance of the
process
 Plan and budget next version
• Results
 Improved UIDSG
development process
 Editorial plan
33
(5) Lessons Learned and Iterate
Accompanying
project activities

UIDSG
development
(1) Initialize
and Plan
(2)
Understand
and Define
(3) Develop
(4) Evaluate
and Refine
(5) Deploy
and Train
(6) Lessons
learned and
Iterate
• Goals: Get funding, define team and UIDSG owner,
setup project and roadmap, define main goals for
the UIDSG
• Results: Team in place with clear responsibilities,
prioritized goals
• Goals: Analysis of current state of
system / documentation, collect
insights and feedback, define user
group(s), inspect tool stack
• Results: Content strategy, results
from reviews, target audience, tool-
chain
• Goals: Define TOC, document / define
needed UID and IxD patterns, write
collateral chapters, prepare icon list,
provide conformity check list
• Results: Main body of the UIDSG,
accompanying material
• Goals: Publishing UIDSG at
the target platform (single
document and/or interactive
version), train the user
groups
• Results: In place UIDSG,
interactive templates,
conformity-test cases, icons,
icon-list, informed and
skilled teams
• Goals: Quality assurance of
the process, plan and
budget next version
• Results: Improved UIDSG
development process,
editorial plan
34
• Goals: Quality assurance by different user groups,
review content, test tool stack, first signed off
version
• Results: Improvements, identification of missing
content, iterated, confirmed v1.0
Accompanying
project activities
Cheat Sheet: Basic UIDSG development process

Why SGs fail, how to resolve 1/4
Problem Solution
We will see how the style guide project evolves. Following an "organic flow" in the project is
not efficient; plan at least 3 to 4 months for
the initial version.
#UIDSG 35Source: Wilson 2001, Constantine & Lockwood 1999, Own experience
We do the style guide just with the operational
people to avoid complex discussions.
If key stakeholders and developers in general
have no input to the style guide the
acceptance is threatened.
To save time we give it to someone externally
to write the style guide.
Externals with no connection to the style
guide group are “Aliens”; form a team and
define a style guide owner.
We just follow existing platform style guides. Every project needs specific guideline,
platform guides can be just a part of them.

Problem Solution
The style guide has to be exhaustive. The content itself of a style guide needs a
preceding strategy: what to include and what
will stay in other places (e.g. concrete
requirements / analysis documents of specific
projects)
#UIDSG 36
The style guide is our “universal remedy“. Besides the guide itself it needs also a
standardizing process.
We will include the best and newest interaction
patterns in our style guide.
What goes in the style guide must be cross
checked with existing / planned in-house
development frameworks.
Many users say that our style guide is not
usable.
Iteratively test and inspect the document.

Problem Solution
I have to read so much to get the point. Too much running text is not effective; use
additional info-boxes, annotated screen,
tables, index etc.
#UIDSG 37
It's inconvenient to check whether the systems
conforms to our style guide.
A conformity checklist or usability test cases
are a tool for testers for formal conformity
checks (e.g. during functional tests).
Our tools are all separated; it's so time-
consuming to ensure that I use the right
pattern.
Prevent (too many) media disruptions and
aim for least possible touchpoints.

Problem Solution
The style guide will spread itself, we just send
out a link.
Plan a good communication / training plan for
introducing the style guide; otherwise
misunderstandings are predestined.
#UIDSG 38
The style guide is here, now we are done. The management of the style guide is at least
much important than the initial development.
Provide a method for updating the style guide
and develop reasonable rules on when new
standards must be enacted

• Think in iterations. Start early in an application
project with the development. Initial version of
the UIDSG can be “slim”
• Content development will be always “with your
back pointing into the future”
• “Have the guts” to change existing (bad) UID /
IxD patterns over time, based on feedback
 From usage of the document itself by user groups
 From users of the implemented applications, e.g.
conducted usability test
Tips and tricks 1/2

• Plan review session with the user groups
• Create backlog for topics that rise from different
teams / projects that don't go directly in the
current version of the UIDSG
• Include new topics, only when they are thought
through
• Use the UIDSG also for conformity checks
 E.g. write specific usability test cases, give them to the
software testers for their test routines
 Use your defect tracking system to document the usability
bugs (violations of the UIDSG)
An UIDSG will be at any stage
incomplete and somewhat blurred.
Tips and tricks 2/2

high
low
Level of
Consistency
UIDSG consistency and completeness
high
low
Level of
Completeness
Project A
Project B
Project D
Project …
Project C
Project E
UIDSG development
Contributions by different projects to the UIDSG
Situation: line of gaze
while developing an
UIDSG will always
point into the past.
Source: Bechinie
Initial
System

high
low
Level of
Consistency
Initial
System
UIDSG consistency and completeness
high
low
Level of
Completeness
Project A
Project B
Project D
Project …
Project C
Project E
UIDSG development
Contributions to the UIDSG by different projects
Source: Bechinie
Version 1 Version 2 Version 3

And how does this work
in the wild…?
#UIDSG 43

• eGovernment application range
• Digital Data Management (DDM) for
environment and waste management
 Applications have to ensure legal security
 Cloud system, data warehouse in Austria
 AA level of accessibility
• Laws for the protection of: health, soil, air, water
• Cooperation of different stakeholder:
authorities, companies, experts
• Cross administrative business processes
 Prepare and submit waste balances
 Obligations to report to local authorities and EU
 Management of notifications of permissions
 Expert assessments
Case study: Digital Data Management (DDM)

• 53.5 million tons waste per year in Austria
(approx. 900,000 box wagons)
• Waste has to be: moved, stored, utilized,
deposed
• Ecosystem of complex business applications
 45.000 registered users (companies)
 1.500 public official users (federal, provincial/district level)
 800.000 reports / year are submitted
DDM facts

• Very fragmented application ecosystem
• Different age of each single applications
• Hardly any consistency within / between app.
• Legacy front end framework, form based
• Usability: big room for improvement
• Industry stakeholder very dissatisfied
• New app. projects have already started
• Style document: 10 page, out dated
Wake up call: new DDM technical
director identified need: improve
usability, we need an UIDSG.
Starting point of the UIDSG project

• Client budgeted UX activities,
UIDSG development
• Ownership of UIDSG: technical DDM director
• Usability group was installed
• “A Team” was defined
• Biweekly jour fixe of usability group
 Discussion of current (design, usability) issues from the
projects, provide concrete solutions
 Invite people to join and discuss their questions (e.g.
analysist)
Project setup
#UIDSG 48

Usability Group
#UIDSG 49
Test.
Software testing team
monitors overall app
consistency, based on
UIDSG
UX.
UX team develops
UID and IxD patterns,
writes main body of
UIDSG
Arch.
Internal system archi-
tecture provides IT
framework, develops
components
Auth.
Contracting authority
= Ministry for
Environment
Proj.
Business analysts of the different
projects participate in the
Usability Jour Fixe
Bus.
Biweekly Usability Jour Fixe
IT
Technical Director
has overall DDM
responsibility,
UIDSG owner
Source: Bechinie

UIDSG toolchain and
development workflow
#UIDSG 50

#UIDSG 51
Wireframes
UID patterns,
annotations
UID specification
document
Annotation of
visual design
screens
Main UIDSG
body
Icon list
UX.
UID, IxD pattern
for business
analysis
Usability test
cases
Single UIDSG document
Icons
Website with
interactive examples,
templates, code
CSS framework with
components
Usability bugs
Source: Bechinie

Example documents
#UIDSG 52
Single UIDSG document Icon list

#UIDSG 53
Review of UIDSG
Bus. Dev.
internal Test.
UX.
UX team develops
UID and IxD patterns,
writes main UIDSG body
Single UIDSG
document
UIDSG development workflow
Usability
Group
Iterations, quality
assurance
Source: Bechinie
Auth.
Official sign off for
UIDSG

• Consistency within and between DDM
applications has improved
• Overall DDM usability has improved (checked by
usability tests, SUS-scores)
• General acceptance of DDM application by end
users (companies, authorities) is higher than
4 years ago (feedback from users)
• Value of UIDSG is recognized by: developers,
analysts, testers (feedback within different team
meetings)
• Awareness towards consistency within the
whole organization has been raised (topic is
much more thematised)
What return did we generated?

• Versioning
 Annotations in the UIDSG for parts that have changed to
the last version are helpful, e.g. annotations in the single
Word document
• Interpretation of UIDSG
 It still needs humans to explain the UIDSG to avoid
misinterpretations
 Find balance between too loose (too much room for
interpretation) and too rigid definitions and rules (it’s not
possible to define every case within complex applications)
Lessons learned 1/3

• Content
 Take out content redundancies (writing the same content
at different positions in the single document)
 Enhance cross referencing of content within the single
document
 Improve the clarity of rationality behind (design) decisions
in the UIDSG
• Management
 Improve reaction time of UIDSG group towards questions
from projects
Lessons learned 2/3

• Application
 Findability of topics in the document must be improved
 Testability of code against UIDSG has to be improved by
prioritising and clustering of usability test cases
• Deployment
 Single document has its value but is at its limit with 250
pages > index, table of contents, table of figures,
annotated screens, bad/good examples, icon-list
 Annotations what has changed and the search function of
the word processor helps to find the information needed
 Provide a single document (DOC,PDF) and an interactive
version (HTML) for the UIDSG body
Lessons learned 3/3

• UIDSG development needs its own project
• Install a quality group
• Define a tool chain that fits your general setup
• Start early, think and develop in iterations
• Provide easy and interactive access
• Bring the content to the tasks of the user groups
• Use it as a conversation tool among stakeholders
• Use the UIDSG also for conformity checks
• Conduct trainings
• Do a lessons learned session from time to time
Wrapping up

Is there a take home
mantra?
#UIDSG 59

Doesn't replace human centred design activity
Is part of the design management
Will be always incomplete
Isn't a licence to stop thinking
A solid UIDSG and an effective
management process leads to a
successful application.
A User Interface Design Style Guide…
Michael Bechinie
USECON
Head of Experience Design
bechinie@usecon.com
@beemcog

User Interface Design Style Guides are not dead, the just smell funny

More Related Content

What's hot (20)

Similar to User Interface Design Style Guides are not dead, the just smell funny (20)

More from USECON (20)

Recently uploaded (20)

User Interface Design Style Guides are not dead, the just smell funny