The presentation of the submitted paper by Michael Bechinie, Manfred Tscheligi and Markus Murtinger at the international UXPA conference in Toronto, Canada 2017.
Verified Trusted Call Girls Adugodi💘 9352852248 Good Looking standard Profil...
User Interface Design Style Guides are not dead, the just smell funny
1. 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
5. • 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
7. • 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
9. • 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
10. • 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
#UIDSG 10Source: Pexels
11. 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
14. • 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
15. Let’s focus on User Interface
Design Style Guides – UIDSGs
#UIDSG 15
16. • 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
17. • 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
18. • 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
19. 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
20. 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
21. In which ways can an UIDSG
be implemented?
#UIDSG 21
22. • 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
23. 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
24. • 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
25. 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
26. Is there a process the helps to
develop and manage an UIDSG ?
#UIDSG 26
27. 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
28. 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
Governance, Promotors, Awareness activities etc.
29. 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
Governance, Promotors, Awareness activities etc.
30. 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
Governance, Promotors, Awareness activities etc.
31. 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
Governance, Promotors, Awareness activities etc.
32. 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
Governance, Promotors, Awareness activities etc.
33. 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
Governance, Promotors, Awareness activities etc.
34. 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
Governance, Promotors, Awareness activities etc.
Cheat Sheet: Basic UIDSG development process
35. 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.
36. Why SGs fail, how to resolve 2/4
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.
37. Why SGs fail, how to resolve 3/4
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.
38. Why SGs fail, how to resolve 4/4
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
39. • 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
#UIDSG 39Source: Bechinie
40. • 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
#UIDSG 40Source: Bechinie
41. 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
42. 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
45. • 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)
#UIDSG 45Source: Bechinie
46. • 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
#UIDSG 46Source: Bechinie
47. • 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
#UIDSG 47Source: Pexels
48. • 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
49. 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
51. #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
53. #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
54. • 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?
#UIDSG 54Source: Pexels
55. • 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
#UIDSG 55Source: Bechinie
56. • 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
#UIDSG 56Source: Bechinie
57. • 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 57Source: Bechinie
58. • 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
#UIDSG 58Source: Pexels
60. 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
#UIDSG 60Source: Bechinie