Post on 21-Jan-2018
transcript
Usability User Experience User Interface Design
User Interface DesignStyle Guides are Not DeadTHEY JUST SMELL FUNNY
Michael Bechinie | Head of Experience Design | bechinie@usecon.com#UXPA2017 | uxpa2017.org#UIDSG
Design style…
#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 challengesdo 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 ofelements > 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
#UIDSG 10Source: Pexels
Benefits of SGs for different groupsUsers Developers Business
End Users
More consistency leads to reduced errors
Less frustration
Increased morale
Improved efficiency
Increased confidence
Reduced resistance to newtechnology
#UIDSG 11Source: Gale 1996
Developers
Maintain control overlook and feel
Minimize reinvention
Capitalize on learning
Enable production ofreusable software
Reduce development time
Reduce arbitrarydesign 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 ofstyle 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 InterfaceDesign 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 18Source: Garret 2002
Lists info boxes
figures
tables
document changes
How to Work with the UIDSGIntroduction 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 SettingsOnline Help and Documentation guidelines for developing help content
Reference DocumentsIcon ListGlossaryScreen Width ClassesAnnexIndex
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 20Source: Nielsen, Molich 1994
In which ways can an UIDSGbe 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 DrawWireframes
AnnotationWireframes
VisualDesign
Write mainUISG Body
Make UISGInteractive
ExportContent
Word
PPT
Axure
Sketch
Markdown
CSS / HTML
#UIDSG 23
LowMediumHigh
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 forcolours > 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
UIDSGRelevance
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 tocheck the UI
UX.Develop consistent
patterns
Source: Bechinie
Is there a process the helps to develop and manage an UIDSG ?
#UIDSG 26
UIDSGdevelopment
(1) Initialize and Plan
(2) Understand and Define
(3) Develop
(4) Evaluate and Refine
(5) Deploy and Train
(6) Lessons learned and
Iterate
27
Accompanyingproject activities
Governance, Promotors, Awareness activities etc.
Basic UIDSG development process
UIDSGdevelopment
(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
Accompanyingproject activities
Governance, Promotors, Awareness activities etc.
UIDSGdevelopment
(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
Accompanyingproject activities
Governance, Promotors, Awareness activities etc.
UIDSGdevelopment
(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
Accompanyingproject activities
Governance, Promotors, Awareness activities etc.
UIDSGdevelopment
(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
Accompanyingproject activities
Governance, Promotors, Awareness activities etc.
UIDSGdevelopment
(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
Accompanyingproject activities
Governance, Promotors, Awareness activities etc.
UIDSGdevelopment
(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
Accompanyingproject activities
Governance, Promotors, Awareness activities etc.
UIDSGdevelopment
(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
Accompanyingproject activities
Governance, Promotors, Awareness activities etc.
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.
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.
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.
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
• 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
• 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
high
low
Level ofConsistency
UIDSG consistency and completeness
high
low
Level ofCompleteness
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 ofConsistency
Initial System
UIDSG consistency and completeness
high
low
Level ofCompleteness
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 workin the wild…?
#UIDSG 43
A case study
#UIDSG 44
• 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
• 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
• 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
• 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
ITTechnical Directorhas overall DDM
responsibility,UIDSG owner
Source: Bechinie
UIDSG toolchain anddevelopment workflow
#UIDSG 50
#UIDSG 51
WireframesUID 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
UsabilityGroupIterations, 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 than4 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
• 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
• 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
• 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
• 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
Is there a take homemantra?
#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
#UIDSG 60Source: Bechinie