User Interface Design Style Guides are Not Dead, they Just Smell Funny

Usability User Experience User Interface Design

User Interface DesignStyle Guides are Not DeadTHEY JUST SMELL FUNNY

Michael Bechinie | Head of Experience Design | [email protected]#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


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



(3) Develop




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




UIDSGdevelopment



(3) Develop




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




UIDSGdevelopment



(3) Develop




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



UIDSGdevelopment



(3) Develop




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




UIDSGdevelopment



(3) Develop




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




UIDSGdevelopment



(3) Develop




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



UIDSGdevelopment



(3) Develop




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



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 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)


• 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

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?


• 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 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

[email protected]

@beemcog


mailto:[email protected]

https://twitter.com/beemcog

https://www.linkedin.com/in/michaelbechinie/

https://www.linkedin.com/in/michaelbechinie/

Presentations & Public Speaking

User Interface Design Style Guides are Not Dead, they Just Smell Funny