SlideShare une entreprise Scribd logo
1  sur  107
Télécharger pour lire hors ligne
The Secret Of Agile UX



         James O’Brien
      james@sparrk.co.uk
The Secret Of Agile UX
   Or, How to avoid Big Design Up Front
by pretending not to do Big Design Up Front




                James O’Brien
             james@sparrk.co.uk
Who is this guy anyway?
Who is this guy anyway?
  UX Freelancer for 10 years
Who is this guy anyway?
   UX Freelancer for 10 years
Agile UX practitioner for 5 years
Who is this guy anyway?
   UX Freelancer for 10 years
Agile UX practitioner for 5 years
 Sideline in Agile Enablement
Who is this guy anyway?
   UX Freelancer for 10 years
Agile UX practitioner for 5 years
 Sideline in Agile Enablement
  I HAVE DONE WRONG THINGS
Who is this guy anyway?
   UX Freelancer for 10 years
Agile UX practitioner for 5 years
 Sideline in Agile Enablement
  I HAVE DONE WRONG THINGS
   But you can learn from my
            mistakes
Agile UX – How To Avoid Big Design Up Front By Pretending Not To Do Big Design Up Front
๏   No magic bullets contained within
๏   No magic bullets contained within
๏   Do not attempt to implement by rote
๏   No magic bullets contained within
๏   Do not attempt to implement by rote
๏   Not guaranteed to work with Enterprise
    Agile, Cargo Cult Agile or Scrumbut
๏   No magic bullets contained within
๏   Do not attempt to implement by rote
๏   Not guaranteed to work with Enterprise
    Agile, Cargo Cult Agile or Scrumbut
๏   Requires interaction with BAs and
    Developers
๏   No magic bullets contained within
๏   Do not attempt to implement by rote
๏   Not guaranteed to work with Enterprise
    Agile, Cargo Cult Agile or Scrumbut
๏   Requires interaction with BAs and
    Developers
๏   Risk of improved delivery and morale
“No Big Design Up Front”
i1   i2   i3   i4   i5
Design
 for i1




          i1   i2   i3   i4   i5
Design    Design
 for i1    for i2




           i1       i2   i3   i4   i5
Design    Design    Design
 for i1    for i2    for i3




           i1        i2       i3   i4   i5
Design    Design    Design    Design
 for i1    for i2    for i3    for i4




           i1        i2        i3       i4   i5
Design    Design    Design    Design    Design
 for i1    for i2    for i3    for i4    for i5




           i1        i2        i3        i4       i5
Have a
Design    Design    Design    Design    Design
                                                  fucking
 for i1    for i2    for i3    for i4    for i5
                                                   party




           i1        i2        i3        i4         i5
Have a
Design    Design    Design    Design    Design
                                                  fucking
 for i1    for i2    for i3    for i4    for i5
                                                   party




           i1        i2        i3        i4         i5




 THIS NEVER WORKS
i0   i1   i2   i3   i4   i5




Agile’s Dirty Secret: i0
i0   i1   i2   i3   i4   i5
Design
 for i1




          i0   i1   i2   i3   i4   i5
Design
Design
           for i1
 for i1
            & i2




           i0       i1   i2   i3   i4   i5
Design    Design
Design
           for i1    for i2
 for i1
            & i2      & i3




           i0        i1       i2   i3   i4   i5
Design    Design    Design
Design
           for i1    for i2    for i3
 for i1
            & i2      & i3      & i4




           i0        i1        i2       i3   i4   i5
Design    Design    Design    Design
Design
           for i1    for i2    for i3    for i4
 for i1
            & i2      & i3      & i4      & i5




           i0        i1        i2        i3       i4   i5
Design
          Design    Design    Design    Design
Design                                            for i5,
           for i1    for i2    for i3    for i4
 for i1
            & i2      & i3      & i4      & i5 plan fucking
                                                   party




           i0        i1        i2        i3         i4        i5
Design
          Design    Design    Design    Design              Have a
Design                                            for i5,
           for i1    for i2    for i3    for i4             fucking
 for i1
            & i2      & i3      & i4      & i5 plan fucking party
                                                   party




           i0        i1        i2        i3         i4        i5
Design
          Design    Design    Design    Design              Have a
Design                                            for i5,
           for i1    for i2    for i3    for i4             fucking
 for i1
            & i2      & i3      & i4      & i5 plan fucking party
                                                   party




           i0        i1        i2        i3         i4        i5




          THIS NEVER WORKS
Agile’s Other Dirty Secret:
  Planning
Gather
Requirements




 Agile’s Other Dirty Secret:
   Planning
Gather        Analyse
Requirements   Requirements




 Agile’s Other Dirty Secret:
   Planning
Gather        Analyse      Write
Requirements   Requirements   Epics




 Agile’s Other Dirty Secret:
   Planning
Gather        Analyse      Write   Scope
Requirements   Requirements   Epics     R1




 Agile’s Other Dirty Secret:
   Planning
Gather        Analyse      Write   Scope    Write
Requirements   Requirements   Epics     R1    Stories




 Agile’s Other Dirty Secret:
   Planning
Gather        Analyse      Write   Scope    Write    Plan
Requirements   Requirements   Epics     R1    Stories    R1




 Agile’s Other Dirty Secret:
   Planning
Gather        Analyse      Write   Scope    Write    Plan
Requirements   Requirements   Epics     R1    Stories    R1




 Agile’s Other Dirty Secret:
   Planning ~= Design
Write
Epics
Wait... isn’t that how
   design works?
Wait... isn’t that how
          design works?
✦   Pair with BAs during analysis
Wait... isn’t that how
          design works?
✦   Pair with BAs during analysis
✦   Wireframe based on requirements and feed those into
    epics
Wait... isn’t that how
          design works?
✦   Pair with BAs during analysis
✦   Wireframe based on requirements and feed those into
    epics
✦   Refine your wireframes as the epics are validated by the
    business
Wait... isn’t that how
          design works?
✦   Pair with BAs during analysis
✦   Wireframe based on requirements and feed those into
    epics
✦   Refine your wireframes as the epics are validated by the
    business
✦   Some IA and UX artefacts will pop out of this process
    naturally
Wait... isn’t that how
          design works?
✦   Pair with BAs during analysis
✦   Wireframe based on requirements and feed those into
    epics
✦   Refine your wireframes as the epics are validated by the
    business
✦   Some IA and UX artefacts will pop out of this process
    naturally
✦   Develop your modular design language
Wait... isn’t that how
          design works?
✦   Pair with BAs during analysis
✦   Wireframe based on requirements and feed those into
    epics
✦   Refine your wireframes as the epics are validated by the
    business
✦   Some IA and UX artefacts will pop out of this process
    naturally
✦   Develop your modular design language
✦   Only go hi-fi when the release is scoped
Gather        Analyse      Write   Scope    Write    Plan
Requirements   Requirements   Epics     R1    Stories    R1
Gather        Analyse      Write   Scope    Write    Plan
Requirements   Requirements   Epics     R1    Stories    R1




 Identify UX
Requirements
Gather        Analyse        Write   Scope    Write    Plan
Requirements   Requirements     Epics     R1    Stories    R1




                    Define
 Identify UX   large-scale IA
Requirements       (to feed
                 into epics)
Gather        Analyse       Write      Scope    Write    Plan
Requirements   Requirements    Epics        R1    Stories    R1




                    Define
 Identify UX   large-scale IA Wireframe
Requirements       (to feed     Epics
                 into epics)
Gather        Analyse       Write   Scope       Write    Plan
Requirements   Requirements    Epics     R1       Stories    R1




                    Define               Begin
 Identify UX   large-scale IA Wireframe site
Requirements       (to feed     Epics    design
                 into epics)           language
Gather        Analyse      Write   Scope     Write     Plan
Requirements   Requirements   Epics     R1     Stories     R1




                    Define               Begin
 Identify UX   large-scale IA Wireframe site Wireframe
Requirements       (to feed     Epics    design Stories
                 into epics)           language
Gather        Analyse      Write    Scope     Write    Plan
Requirements   Requirements   Epics      R1     Stories    R1




                    Define               Begin
 Identify UX   large-scale IA Wireframe site Wireframe Hi-Fi
Requirements       (to feed     Epics    design Stories i1 of R1
                 into epics)           language
Align Your Strategies Early
Align Your Strategies Early
✦   Mobile First == Agile Minimum Valuable Product
Align Your Strategies Early
✦   Mobile First == Agile Minimum Valuable Product
✦   User Testing fits with frequent demos and releases
Align Your Strategies Early
✦   Mobile First == Agile Minimum Valuable Product
✦   User Testing fits with frequent demos and releases
✦   Browser Testing fits with Continuous QA
Align Your Strategies Early
✦   Mobile First == Agile Minimum Valuable Product
✦   User Testing fits with frequent demos and releases
✦   Browser Testing fits with Continuous QA
✦   Accessibility exposes a layer that automated testing
    can exploit
Align Your Strategies Early
✦   Mobile First == Agile Minimum Valuable Product
✦   User Testing fits with frequent demos and releases
✦   Browser Testing fits with Continuous QA
✦   Accessibility exposes a layer that automated testing
    can exploit
✦   Feedback from the business validates your design
Align Your Strategies Early
✦   Mobile First == Agile Minimum Valuable Product
✦   User Testing fits with frequent demos and releases
✦   Browser Testing fits with Continuous QA
✦   Accessibility exposes a layer that automated testing
    can exploit
✦   Feedback from the business validates your design
✦   Share knowledge with BAs wherever possible
Support Story Writing
Support Story Writing
✦   Feed Wireframes into stories as functional artefacts
Support Story Writing
✦   Feed Wireframes into stories as functional artefacts
✦   Develop your personas with BAs so they can frame
    stories around the personas
Support Story Writing
✦   Feed Wireframes into stories as functional artefacts
✦   Develop your personas with BAs so they can frame
    stories around the personas
✦   Define your UX principles as NFRs
Support Story Writing
✦   Feed Wireframes into stories as functional artefacts
✦   Develop your personas with BAs so they can frame
    stories around the personas
✦   Define your UX principles as NFRs
✦   Let developers know that the wireframes are
    canonical
Support Story Writing
✦   Feed Wireframes into stories as functional artefacts
✦   Develop your personas with BAs so they can frame
    stories around the personas
✦   Define your UX principles as NFRs
✦   Let developers know that the wireframes are
    canonical
✦   Feed hi-fis if you have them, but keep the
    developers focused on the wireframes
During Development
Prepare to Refactor
Prepare to Refactor
✦   Organise your files to prepare for change
Prepare to Refactor
✦   Organise your files to prepare for change




           http://photoshopetiquette.com/
Prepare to Refactor
✦   Organise your files to prepare for change
Prepare to Refactor
✦   Organise your files to prepare for change
✦   Use design/UX patterns wherever possible
Prepare to Refactor
✦   Organise your files to prepare for change
✦   Use design/UX patterns wherever possible
✦   Use stubbed design and UX debt
Prepare to Refactor
✦   Organise your files to prepare for change
✦   Use design/UX patterns wherever possible
✦   Use stubbed design and UX debt
✦   Build a reusable asset library early on
Prepare to Refactor
✦   Organise your files to prepare for change
✦   Use design/UX patterns wherever possible
✦   Use stubbed design and UX debt
✦   Build a reusable asset library early on
✦   Use a preprocessor like LESS to ensure your CSS can
    be quickly refactored
Prepare to Refactor
✦   Organise your files to prepare for change
✦   Use design/UX patterns wherever possible
✦   Use stubbed design and UX debt
✦   Build a reusable asset library early on
✦   Use a preprocessor like LESS to ensure your CSS can
    be quickly refactored
✦   Focus on high-friction targets first - the UX debt will
    be less painful for users on the low-friction ones
Digression:
Digression:
Digression:
We Need To Rethink The Way
    We Do Deliverables
The web is not flat images
       any more
The web is not flat images
       any more
✦   We need to be able to show multiple states and
    animations easily
The web is not flat images
       any more
✦   We need to be able to show multiple states and
    animations easily
✦   We need the rest of the team to be able to
    understand the scope of a design unambiguously
The web is not flat images
       any more
✦   We need to be able to show multiple states and
    animations easily
✦   We need the rest of the team to be able to
    understand the scope of a design unambiguously
✦   We need to be able to refactor our deliverables
    quickly, and have the refactoring cascade through
    the whole project
The web is not flat images
       any more
✦   We need to be able to show multiple states and
    animations easily
✦   We need the rest of the team to be able to
    understand the scope of a design unambiguously
✦   We need to be able to refactor our deliverables
    quickly, and have the refactoring cascade through
    the whole project
✦   We need to have a tool that supports patterns and
    modularity
Hannah Donovan
✦   What does our 3/4 view look
    like?
✦   http://www.webdirections.org/
    resources/hannah-donovan-
    designing-without-the-browser/
✦   http://www.webdirections.org/
    resources/hannah-donovan-
    telling-stories-through-design/

✦   @han
Jan Srutek




http://www.slideshare.net/JanSru/communicating-and-
           selling-ux-design-deliverables
Project Meteor




http://projectmeteor.org/
Stubbed Designs?
Stubbed Designs?
✦   Stubbed Designs act as placeholders for
    features that haven’t been designed yet
Stubbed Designs?
✦   Stubbed Designs act as placeholders for
    features that haven’t been designed yet
✦   They can also be your progressive
    enhancement baseline
Stubbed Designs?
✦   Stubbed Designs act as placeholders for
    features that haven’t been designed yet
✦   They can also be your progressive
    enhancement baseline
✦   They should be simple, but they don’t need
    to be ugly
You can flag stubs too
.stub:before{
width : 64px; height : 64px;

background : url(/core/images/nodeploy/flag-stub.png)
right top no-repeat;

display : block; content:" ";

position : absolute; right : 0; top : 0;}

.stub{position : relative;}
You can flag stubs too
.stub:before{
width : 64px; height : 64px;

background : url(/core/images/nodeploy/flag-stub.png)
right top no-repeat;

display : block; content:" ";

position : absolute; right : 0; top : 0;}

.stub{position : relative;}
Agile UX – How To Avoid Big Design Up Front By Pretending Not To Do Big Design Up Front
Agile UX – How To Avoid Big Design Up Front By Pretending Not To Do Big Design Up Front
UX Debt?
UX Debt?
“Good enough” or “quick fix”
solutions that get you past a
       problem quickly
UX Debt?
“Good enough” or “quick fix”
solutions that get you past a
       problem quickly
But too much debt can choke a
 project further down the line
UX Debt?
“Good enough” or “quick fix”
solutions that get you past a
       problem quickly
But too much debt can choke a
 project further down the line
So you must address UX debt
periodically - during i zero or
     UAT are good times
Defining “Done”
Defining “Done”
✦   Don’t be precious about signoff
Defining “Done”
✦   Don’t be precious about signoff
✦   If it works well enough, sign it off and raise an
    enhancement - let the client decide how important
    design perfection is
Defining “Done”
✦   Don’t be precious about signoff
✦   If it works well enough, sign it off and raise an
    enhancement - let the client decide how important
    design perfection is
✦   Or track imperfections as defects or UX debt and
    raise tasks to fix them
Defining “Done”
✦   Don’t be precious about signoff
✦   If it works well enough, sign it off and raise an
    enhancement - let the client decide how important
    design perfection is
✦   Or track imperfections as defects or UX debt and
    raise tasks to fix them
✦   Be open to developers’ suggestions but stand firm
    on the really important stuff

Contenu connexe

En vedette

Comment s'adapter à la croissance d'une startup ? (ConFoo 2017 Montréal)
Comment s'adapter à la croissance d'une startup ? (ConFoo 2017 Montréal)Comment s'adapter à la croissance d'une startup ? (ConFoo 2017 Montréal)
Comment s'adapter à la croissance d'une startup ? (ConFoo 2017 Montréal)Lucien Boix
 
Comment s'articule l'écosystème de l'innovation en France ?
Comment s'articule l'écosystème de l'innovation en France ?Comment s'articule l'écosystème de l'innovation en France ?
Comment s'articule l'écosystème de l'innovation en France ?Justine Fradin
 
Engagement, rétention, UX... dans les App
Engagement, rétention, UX... dans les AppEngagement, rétention, UX... dans les App
Engagement, rétention, UX... dans les AppLaFrenchMobile
 
Financer votre projet de startup - Le financement de l'innovation par BPI France
Financer votre projet de startup - Le financement de l'innovation par BPI FranceFinancer votre projet de startup - Le financement de l'innovation par BPI France
Financer votre projet de startup - Le financement de l'innovation par BPI FranceLa French Tech Rennes St Malo
 
Ux design & ergonomie des interfaces 6ème édition (extrait)
Ux design & ergonomie des interfaces 6ème édition (extrait) Ux design & ergonomie des interfaces 6ème édition (extrait)
Ux design & ergonomie des interfaces 6ème édition (extrait) Usabilis
 
How to Make the Switch to Conversation-Driven Sales
How to Make the Switch to Conversation-Driven SalesHow to Make the Switch to Conversation-Driven Sales
How to Make the Switch to Conversation-Driven SalesDrift
 
Explorez votre potentiel de réussite grâce au Startup Founder Canvas
Explorez votre potentiel de réussite grâce au Startup Founder CanvasExplorez votre potentiel de réussite grâce au Startup Founder Canvas
Explorez votre potentiel de réussite grâce au Startup Founder CanvasMarseille Innovation
 
Mobile First to AI First
Mobile First to AI FirstMobile First to AI First
Mobile First to AI FirstLaFrenchMobile
 
Onopia - Business Model de Dashlane
Onopia - Business Model de DashlaneOnopia - Business Model de Dashlane
Onopia - Business Model de DashlaneOnopia
 
Startup 101 : voyage au pays des merveilles
Startup 101 : voyage au pays des merveillesStartup 101 : voyage au pays des merveilles
Startup 101 : voyage au pays des merveillesWilly Braun
 
UX 프로젝트 가이드 (UX Project Guide)
UX 프로젝트 가이드 (UX Project Guide) UX 프로젝트 가이드 (UX Project Guide)
UX 프로젝트 가이드 (UX Project Guide) RightBrain inc.
 
10 méthodes UX appliquées à votre projet Web
10 méthodes UX appliquées à votre projet Web10 méthodes UX appliquées à votre projet Web
10 méthodes UX appliquées à votre projet WebCore-Techs
 
The Truth About Lead Capture Forms
The Truth About Lead Capture FormsThe Truth About Lead Capture Forms
The Truth About Lead Capture FormsDrift
 
#1 Startups Seminar
#1 Startups Seminar#1 Startups Seminar
#1 Startups SeminarMarcel EBOA
 
Guide de financement de la startup innovante édition 2017
Guide de financement de la startup innovante édition 2017Guide de financement de la startup innovante édition 2017
Guide de financement de la startup innovante édition 2017Mondher Khanfir
 
Startup/Digital Marketing 2.0: Growth Hacking Thru UX
Startup/Digital Marketing 2.0: Growth Hacking Thru UXStartup/Digital Marketing 2.0: Growth Hacking Thru UX
Startup/Digital Marketing 2.0: Growth Hacking Thru UXSoon-Aik Chiew
 

En vedette (17)

Comment s'adapter à la croissance d'une startup ? (ConFoo 2017 Montréal)
Comment s'adapter à la croissance d'une startup ? (ConFoo 2017 Montréal)Comment s'adapter à la croissance d'une startup ? (ConFoo 2017 Montréal)
Comment s'adapter à la croissance d'une startup ? (ConFoo 2017 Montréal)
 
4CAD Startup
4CAD Startup4CAD Startup
4CAD Startup
 
Comment s'articule l'écosystème de l'innovation en France ?
Comment s'articule l'écosystème de l'innovation en France ?Comment s'articule l'écosystème de l'innovation en France ?
Comment s'articule l'écosystème de l'innovation en France ?
 
Engagement, rétention, UX... dans les App
Engagement, rétention, UX... dans les AppEngagement, rétention, UX... dans les App
Engagement, rétention, UX... dans les App
 
Financer votre projet de startup - Le financement de l'innovation par BPI France
Financer votre projet de startup - Le financement de l'innovation par BPI FranceFinancer votre projet de startup - Le financement de l'innovation par BPI France
Financer votre projet de startup - Le financement de l'innovation par BPI France
 
Ux design & ergonomie des interfaces 6ème édition (extrait)
Ux design & ergonomie des interfaces 6ème édition (extrait) Ux design & ergonomie des interfaces 6ème édition (extrait)
Ux design & ergonomie des interfaces 6ème édition (extrait)
 
How to Make the Switch to Conversation-Driven Sales
How to Make the Switch to Conversation-Driven SalesHow to Make the Switch to Conversation-Driven Sales
How to Make the Switch to Conversation-Driven Sales
 
Explorez votre potentiel de réussite grâce au Startup Founder Canvas
Explorez votre potentiel de réussite grâce au Startup Founder CanvasExplorez votre potentiel de réussite grâce au Startup Founder Canvas
Explorez votre potentiel de réussite grâce au Startup Founder Canvas
 
Mobile First to AI First
Mobile First to AI FirstMobile First to AI First
Mobile First to AI First
 
Onopia - Business Model de Dashlane
Onopia - Business Model de DashlaneOnopia - Business Model de Dashlane
Onopia - Business Model de Dashlane
 
Startup 101 : voyage au pays des merveilles
Startup 101 : voyage au pays des merveillesStartup 101 : voyage au pays des merveilles
Startup 101 : voyage au pays des merveilles
 
UX 프로젝트 가이드 (UX Project Guide)
UX 프로젝트 가이드 (UX Project Guide) UX 프로젝트 가이드 (UX Project Guide)
UX 프로젝트 가이드 (UX Project Guide)
 
10 méthodes UX appliquées à votre projet Web
10 méthodes UX appliquées à votre projet Web10 méthodes UX appliquées à votre projet Web
10 méthodes UX appliquées à votre projet Web
 
The Truth About Lead Capture Forms
The Truth About Lead Capture FormsThe Truth About Lead Capture Forms
The Truth About Lead Capture Forms
 
#1 Startups Seminar
#1 Startups Seminar#1 Startups Seminar
#1 Startups Seminar
 
Guide de financement de la startup innovante édition 2017
Guide de financement de la startup innovante édition 2017Guide de financement de la startup innovante édition 2017
Guide de financement de la startup innovante édition 2017
 
Startup/Digital Marketing 2.0: Growth Hacking Thru UX
Startup/Digital Marketing 2.0: Growth Hacking Thru UXStartup/Digital Marketing 2.0: Growth Hacking Thru UX
Startup/Digital Marketing 2.0: Growth Hacking Thru UX
 

Dernier

UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationIES VE
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfDaniel Santiago Silva Capera
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Websitedgelyza
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-pyJamie (Taka) Wang
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesDavid Newbury
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.YounusS2
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Will Schroeder
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureEric D. Schabell
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?IES VE
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxUdaiappa Ramachandran
 
Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Commit University
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1DianaGray10
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfinfogdgmi
 

Dernier (20)

UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
 
201610817 - edge part1
201610817 - edge part1201610817 - edge part1
201610817 - edge part1
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Website
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-py
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond Ontologies
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability Adventure
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptx
 
Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdf
 

Agile UX – How To Avoid Big Design Up Front By Pretending Not To Do Big Design Up Front

  • 1. The Secret Of Agile UX James O’Brien james@sparrk.co.uk
  • 2. The Secret Of Agile UX Or, How to avoid Big Design Up Front by pretending not to do Big Design Up Front James O’Brien james@sparrk.co.uk
  • 3. Who is this guy anyway?
  • 4. Who is this guy anyway? UX Freelancer for 10 years
  • 5. Who is this guy anyway? UX Freelancer for 10 years Agile UX practitioner for 5 years
  • 6. Who is this guy anyway? UX Freelancer for 10 years Agile UX practitioner for 5 years Sideline in Agile Enablement
  • 7. Who is this guy anyway? UX Freelancer for 10 years Agile UX practitioner for 5 years Sideline in Agile Enablement I HAVE DONE WRONG THINGS
  • 8. Who is this guy anyway? UX Freelancer for 10 years Agile UX practitioner for 5 years Sideline in Agile Enablement I HAVE DONE WRONG THINGS But you can learn from my mistakes
  • 10. No magic bullets contained within
  • 11. No magic bullets contained within ๏ Do not attempt to implement by rote
  • 12. No magic bullets contained within ๏ Do not attempt to implement by rote ๏ Not guaranteed to work with Enterprise Agile, Cargo Cult Agile or Scrumbut
  • 13. No magic bullets contained within ๏ Do not attempt to implement by rote ๏ Not guaranteed to work with Enterprise Agile, Cargo Cult Agile or Scrumbut ๏ Requires interaction with BAs and Developers
  • 14. No magic bullets contained within ๏ Do not attempt to implement by rote ๏ Not guaranteed to work with Enterprise Agile, Cargo Cult Agile or Scrumbut ๏ Requires interaction with BAs and Developers ๏ Risk of improved delivery and morale
  • 15. “No Big Design Up Front”
  • 16. i1 i2 i3 i4 i5
  • 17. Design for i1 i1 i2 i3 i4 i5
  • 18. Design Design for i1 for i2 i1 i2 i3 i4 i5
  • 19. Design Design Design for i1 for i2 for i3 i1 i2 i3 i4 i5
  • 20. Design Design Design Design for i1 for i2 for i3 for i4 i1 i2 i3 i4 i5
  • 21. Design Design Design Design Design for i1 for i2 for i3 for i4 for i5 i1 i2 i3 i4 i5
  • 22. Have a Design Design Design Design Design fucking for i1 for i2 for i3 for i4 for i5 party i1 i2 i3 i4 i5
  • 23. Have a Design Design Design Design Design fucking for i1 for i2 for i3 for i4 for i5 party i1 i2 i3 i4 i5 THIS NEVER WORKS
  • 24. i0 i1 i2 i3 i4 i5 Agile’s Dirty Secret: i0
  • 25. i0 i1 i2 i3 i4 i5
  • 26. Design for i1 i0 i1 i2 i3 i4 i5
  • 27. Design Design for i1 for i1 & i2 i0 i1 i2 i3 i4 i5
  • 28. Design Design Design for i1 for i2 for i1 & i2 & i3 i0 i1 i2 i3 i4 i5
  • 29. Design Design Design Design for i1 for i2 for i3 for i1 & i2 & i3 & i4 i0 i1 i2 i3 i4 i5
  • 30. Design Design Design Design Design for i1 for i2 for i3 for i4 for i1 & i2 & i3 & i4 & i5 i0 i1 i2 i3 i4 i5
  • 31. Design Design Design Design Design Design for i5, for i1 for i2 for i3 for i4 for i1 & i2 & i3 & i4 & i5 plan fucking party i0 i1 i2 i3 i4 i5
  • 32. Design Design Design Design Design Have a Design for i5, for i1 for i2 for i3 for i4 fucking for i1 & i2 & i3 & i4 & i5 plan fucking party party i0 i1 i2 i3 i4 i5
  • 33. Design Design Design Design Design Have a Design for i5, for i1 for i2 for i3 for i4 fucking for i1 & i2 & i3 & i4 & i5 plan fucking party party i0 i1 i2 i3 i4 i5 THIS NEVER WORKS
  • 34. Agile’s Other Dirty Secret: Planning
  • 35. Gather Requirements Agile’s Other Dirty Secret: Planning
  • 36. Gather Analyse Requirements Requirements Agile’s Other Dirty Secret: Planning
  • 37. Gather Analyse Write Requirements Requirements Epics Agile’s Other Dirty Secret: Planning
  • 38. Gather Analyse Write Scope Requirements Requirements Epics R1 Agile’s Other Dirty Secret: Planning
  • 39. Gather Analyse Write Scope Write Requirements Requirements Epics R1 Stories Agile’s Other Dirty Secret: Planning
  • 40. Gather Analyse Write Scope Write Plan Requirements Requirements Epics R1 Stories R1 Agile’s Other Dirty Secret: Planning
  • 41. Gather Analyse Write Scope Write Plan Requirements Requirements Epics R1 Stories R1 Agile’s Other Dirty Secret: Planning ~= Design
  • 43. Wait... isn’t that how design works?
  • 44. Wait... isn’t that how design works? ✦ Pair with BAs during analysis
  • 45. Wait... isn’t that how design works? ✦ Pair with BAs during analysis ✦ Wireframe based on requirements and feed those into epics
  • 46. Wait... isn’t that how design works? ✦ Pair with BAs during analysis ✦ Wireframe based on requirements and feed those into epics ✦ Refine your wireframes as the epics are validated by the business
  • 47. Wait... isn’t that how design works? ✦ Pair with BAs during analysis ✦ Wireframe based on requirements and feed those into epics ✦ Refine your wireframes as the epics are validated by the business ✦ Some IA and UX artefacts will pop out of this process naturally
  • 48. Wait... isn’t that how design works? ✦ Pair with BAs during analysis ✦ Wireframe based on requirements and feed those into epics ✦ Refine your wireframes as the epics are validated by the business ✦ Some IA and UX artefacts will pop out of this process naturally ✦ Develop your modular design language
  • 49. Wait... isn’t that how design works? ✦ Pair with BAs during analysis ✦ Wireframe based on requirements and feed those into epics ✦ Refine your wireframes as the epics are validated by the business ✦ Some IA and UX artefacts will pop out of this process naturally ✦ Develop your modular design language ✦ Only go hi-fi when the release is scoped
  • 50. Gather Analyse Write Scope Write Plan Requirements Requirements Epics R1 Stories R1
  • 51. Gather Analyse Write Scope Write Plan Requirements Requirements Epics R1 Stories R1 Identify UX Requirements
  • 52. Gather Analyse Write Scope Write Plan Requirements Requirements Epics R1 Stories R1 Define Identify UX large-scale IA Requirements (to feed into epics)
  • 53. Gather Analyse Write Scope Write Plan Requirements Requirements Epics R1 Stories R1 Define Identify UX large-scale IA Wireframe Requirements (to feed Epics into epics)
  • 54. Gather Analyse Write Scope Write Plan Requirements Requirements Epics R1 Stories R1 Define Begin Identify UX large-scale IA Wireframe site Requirements (to feed Epics design into epics) language
  • 55. Gather Analyse Write Scope Write Plan Requirements Requirements Epics R1 Stories R1 Define Begin Identify UX large-scale IA Wireframe site Wireframe Requirements (to feed Epics design Stories into epics) language
  • 56. Gather Analyse Write Scope Write Plan Requirements Requirements Epics R1 Stories R1 Define Begin Identify UX large-scale IA Wireframe site Wireframe Hi-Fi Requirements (to feed Epics design Stories i1 of R1 into epics) language
  • 58. Align Your Strategies Early ✦ Mobile First == Agile Minimum Valuable Product
  • 59. Align Your Strategies Early ✦ Mobile First == Agile Minimum Valuable Product ✦ User Testing fits with frequent demos and releases
  • 60. Align Your Strategies Early ✦ Mobile First == Agile Minimum Valuable Product ✦ User Testing fits with frequent demos and releases ✦ Browser Testing fits with Continuous QA
  • 61. Align Your Strategies Early ✦ Mobile First == Agile Minimum Valuable Product ✦ User Testing fits with frequent demos and releases ✦ Browser Testing fits with Continuous QA ✦ Accessibility exposes a layer that automated testing can exploit
  • 62. Align Your Strategies Early ✦ Mobile First == Agile Minimum Valuable Product ✦ User Testing fits with frequent demos and releases ✦ Browser Testing fits with Continuous QA ✦ Accessibility exposes a layer that automated testing can exploit ✦ Feedback from the business validates your design
  • 63. Align Your Strategies Early ✦ Mobile First == Agile Minimum Valuable Product ✦ User Testing fits with frequent demos and releases ✦ Browser Testing fits with Continuous QA ✦ Accessibility exposes a layer that automated testing can exploit ✦ Feedback from the business validates your design ✦ Share knowledge with BAs wherever possible
  • 65. Support Story Writing ✦ Feed Wireframes into stories as functional artefacts
  • 66. Support Story Writing ✦ Feed Wireframes into stories as functional artefacts ✦ Develop your personas with BAs so they can frame stories around the personas
  • 67. Support Story Writing ✦ Feed Wireframes into stories as functional artefacts ✦ Develop your personas with BAs so they can frame stories around the personas ✦ Define your UX principles as NFRs
  • 68. Support Story Writing ✦ Feed Wireframes into stories as functional artefacts ✦ Develop your personas with BAs so they can frame stories around the personas ✦ Define your UX principles as NFRs ✦ Let developers know that the wireframes are canonical
  • 69. Support Story Writing ✦ Feed Wireframes into stories as functional artefacts ✦ Develop your personas with BAs so they can frame stories around the personas ✦ Define your UX principles as NFRs ✦ Let developers know that the wireframes are canonical ✦ Feed hi-fis if you have them, but keep the developers focused on the wireframes
  • 72. Prepare to Refactor ✦ Organise your files to prepare for change
  • 73. Prepare to Refactor ✦ Organise your files to prepare for change http://photoshopetiquette.com/
  • 74. Prepare to Refactor ✦ Organise your files to prepare for change
  • 75. Prepare to Refactor ✦ Organise your files to prepare for change ✦ Use design/UX patterns wherever possible
  • 76. Prepare to Refactor ✦ Organise your files to prepare for change ✦ Use design/UX patterns wherever possible ✦ Use stubbed design and UX debt
  • 77. Prepare to Refactor ✦ Organise your files to prepare for change ✦ Use design/UX patterns wherever possible ✦ Use stubbed design and UX debt ✦ Build a reusable asset library early on
  • 78. Prepare to Refactor ✦ Organise your files to prepare for change ✦ Use design/UX patterns wherever possible ✦ Use stubbed design and UX debt ✦ Build a reusable asset library early on ✦ Use a preprocessor like LESS to ensure your CSS can be quickly refactored
  • 79. Prepare to Refactor ✦ Organise your files to prepare for change ✦ Use design/UX patterns wherever possible ✦ Use stubbed design and UX debt ✦ Build a reusable asset library early on ✦ Use a preprocessor like LESS to ensure your CSS can be quickly refactored ✦ Focus on high-friction targets first - the UX debt will be less painful for users on the low-friction ones
  • 82. Digression: We Need To Rethink The Way We Do Deliverables
  • 83. The web is not flat images any more
  • 84. The web is not flat images any more ✦ We need to be able to show multiple states and animations easily
  • 85. The web is not flat images any more ✦ We need to be able to show multiple states and animations easily ✦ We need the rest of the team to be able to understand the scope of a design unambiguously
  • 86. The web is not flat images any more ✦ We need to be able to show multiple states and animations easily ✦ We need the rest of the team to be able to understand the scope of a design unambiguously ✦ We need to be able to refactor our deliverables quickly, and have the refactoring cascade through the whole project
  • 87. The web is not flat images any more ✦ We need to be able to show multiple states and animations easily ✦ We need the rest of the team to be able to understand the scope of a design unambiguously ✦ We need to be able to refactor our deliverables quickly, and have the refactoring cascade through the whole project ✦ We need to have a tool that supports patterns and modularity
  • 88. Hannah Donovan ✦ What does our 3/4 view look like? ✦ http://www.webdirections.org/ resources/hannah-donovan- designing-without-the-browser/ ✦ http://www.webdirections.org/ resources/hannah-donovan- telling-stories-through-design/ ✦ @han
  • 92. Stubbed Designs? ✦ Stubbed Designs act as placeholders for features that haven’t been designed yet
  • 93. Stubbed Designs? ✦ Stubbed Designs act as placeholders for features that haven’t been designed yet ✦ They can also be your progressive enhancement baseline
  • 94. Stubbed Designs? ✦ Stubbed Designs act as placeholders for features that haven’t been designed yet ✦ They can also be your progressive enhancement baseline ✦ They should be simple, but they don’t need to be ugly
  • 95. You can flag stubs too .stub:before{ width : 64px; height : 64px; background : url(/core/images/nodeploy/flag-stub.png) right top no-repeat; display : block; content:" "; position : absolute; right : 0; top : 0;} .stub{position : relative;}
  • 96. You can flag stubs too .stub:before{ width : 64px; height : 64px; background : url(/core/images/nodeploy/flag-stub.png) right top no-repeat; display : block; content:" "; position : absolute; right : 0; top : 0;} .stub{position : relative;}
  • 100. UX Debt? “Good enough” or “quick fix” solutions that get you past a problem quickly
  • 101. UX Debt? “Good enough” or “quick fix” solutions that get you past a problem quickly But too much debt can choke a project further down the line
  • 102. UX Debt? “Good enough” or “quick fix” solutions that get you past a problem quickly But too much debt can choke a project further down the line So you must address UX debt periodically - during i zero or UAT are good times
  • 104. Defining “Done” ✦ Don’t be precious about signoff
  • 105. Defining “Done” ✦ Don’t be precious about signoff ✦ If it works well enough, sign it off and raise an enhancement - let the client decide how important design perfection is
  • 106. Defining “Done” ✦ Don’t be precious about signoff ✦ If it works well enough, sign it off and raise an enhancement - let the client decide how important design perfection is ✦ Or track imperfections as defects or UX debt and raise tasks to fix them
  • 107. Defining “Done” ✦ Don’t be precious about signoff ✦ If it works well enough, sign it off and raise an enhancement - let the client decide how important design perfection is ✦ Or track imperfections as defects or UX debt and raise tasks to fix them ✦ Be open to developers’ suggestions but stand firm on the really important stuff
  • 109. Continuous Availability ✦ Is horrible and makes it difficult to get into the zone and you can’t listen to music and YOU HAVE TO DO IT
  • 110. Continuous Availability ✦ Is horrible and makes it difficult to get into the zone and you can’t listen to music and YOU HAVE TO DO IT ✦ If developers think you’re unapproachable, they’ll guess at implementation – THIS IS BAD
  • 111. Continuous Availability ✦ Is horrible and makes it difficult to get into the zone and you can’t listen to music and YOU HAVE TO DO IT ✦ If developers think you’re unapproachable, they’ll guess at implementation – THIS IS BAD ✦ Be available with your body language as well as your speech: “My time is infinite and you can have as much as you want”
  • 112. Continuous Availability Strategies
  • 113. Continuous Availability Strategies ✦ The Sacrificial Lamb – when there are >1 people in a role, they rotate their availability
  • 114. Continuous Availability Strategies ✦ The Sacrificial Lamb – when there are >1 people in a role, they rotate their availability ✦ The Scary Face – a physical flag you can raise when you need to focus, but it requires a lot of discipline
  • 115. Continuous Availability Strategies ✦ The Sacrificial Lamb – when there are >1 people in a role, they rotate their availability ✦ The Scary Face – a physical flag you can raise when you need to focus, but it requires a lot of discipline ✦ No-meeting Hours – you stay available to the team but no meetings can be booked, reduces the chance of being pulled away
  • 116. Continuous Availability Strategies ✦ The Sacrificial Lamb – when there are >1 people in a role, they rotate their availability ✦ The Scary Face – a physical flag you can raise when you need to focus, but it requires a lot of discipline ✦ No-meeting Hours – you stay available to the team but no meetings can be booked, reduces the chance of being pulled away ✦ Be careful not to overuse these and drive devs away!
  • 117. Leverage QA and Showcases
  • 118. Leverage QA and Showcases ✦ Don’t let the devs destroy the showcase environment - use it for guerilla user testing!
  • 119. Leverage QA and Showcases ✦ Don’t let the devs destroy the showcase environment - use it for guerilla user testing! ✦ Ensure the devs focus on making deployment simple so you can incorporate rapid prototyping (but you probably don’t want to do this on the showcase environment)
  • 120. Leverage QA and Showcases ✦ Don’t let the devs destroy the showcase environment - use it for guerilla user testing! ✦ Ensure the devs focus on making deployment simple so you can incorporate rapid prototyping (but you probably don’t want to do this on the showcase environment) ✦ You can automate some UI and accessibility testing using Selenium: http://code.google.com/p/web- accessibility-testing/downloads/list
  • 121. Leverage QA and Showcases ✦ Don’t let the devs destroy the showcase environment - use it for guerilla user testing! ✦ Ensure the devs focus on making deployment simple so you can incorporate rapid prototyping (but you probably don’t want to do this on the showcase environment) ✦ You can automate some UI and accessibility testing using Selenium: http://code.google.com/p/web- accessibility-testing/downloads/list ✦ While you’re automating, ensure that test data is structured so as to stress the UI
  • 122. There’s more How do we estimate UX effort? Leveraging Test Data Reusable Brainstorming UX and Automation UX and Spikes Optimising Research with Agile UX on the card wall
  • 123. Agile Won’t Wait http://www.flickr.com/photos/uriel1998/
  • 124. Now go and build incredible things.
  • 125. Thank You James O’Brien james@sparrk.co.uk

Notes de l'éditeur

  1. This talk was going to be called “Why Agile People are liars and UX People are lazy and feckless” but I try and keep getting lynched to once a month so instead I called it...\n
  2. \n
  3. \n
  4. \n
  5. \n
  6. \n
  7. I’m also making one very large assumption here, and that is that your team is the right size to deliver the scope of the project you have. If your team needs two UXers and they only have you, that’s a problem that this talk is not designed to address.\n
  8. I’m also making one very large assumption here, and that is that your team is the right size to deliver the scope of the project you have. If your team needs two UXers and they only have you, that’s a problem that this talk is not designed to address.\n
  9. I’m also making one very large assumption here, and that is that your team is the right size to deliver the scope of the project you have. If your team needs two UXers and they only have you, that’s a problem that this talk is not designed to address.\n
  10. I’m also making one very large assumption here, and that is that your team is the right size to deliver the scope of the project you have. If your team needs two UXers and they only have you, that’s a problem that this talk is not designed to address.\n
  11. I’m also making one very large assumption here, and that is that your team is the right size to deliver the scope of the project you have. If your team needs two UXers and they only have you, that’s a problem that this talk is not designed to address.\n
  12. No Big Design Up Front – we all know what this means right? No, you’re wrong. “Design” means a lot of things in software development, and it’s easy for PMs, BAs and us to attach this tenet to the wrong sort of design.\n
  13. Of course because that short uncomplicated planning period doesn’t leave a lot of time to front-load the design, you may have tried doing something like this. This never works because design effort and development effort can be orthogonal. Something gets planned in for i4 that would take more than one iteration to design, and suddenly you’re swamped. No fucking party for you!\n
  14. Of course because that short uncomplicated planning period doesn’t leave a lot of time to front-load the design, you may have tried doing something like this. This never works because design effort and development effort can be orthogonal. Something gets planned in for i4 that would take more than one iteration to design, and suddenly you’re swamped. No fucking party for you!\n
  15. Of course because that short uncomplicated planning period doesn’t leave a lot of time to front-load the design, you may have tried doing something like this. This never works because design effort and development effort can be orthogonal. Something gets planned in for i4 that would take more than one iteration to design, and suddenly you’re swamped. No fucking party for you!\n
  16. Of course because that short uncomplicated planning period doesn’t leave a lot of time to front-load the design, you may have tried doing something like this. This never works because design effort and development effort can be orthogonal. Something gets planned in for i4 that would take more than one iteration to design, and suddenly you’re swamped. No fucking party for you!\n
  17. Of course because that short uncomplicated planning period doesn’t leave a lot of time to front-load the design, you may have tried doing something like this. This never works because design effort and development effort can be orthogonal. Something gets planned in for i4 that would take more than one iteration to design, and suddenly you’re swamped. No fucking party for you!\n
  18. Of course because that short uncomplicated planning period doesn’t leave a lot of time to front-load the design, you may have tried doing something like this. This never works because design effort and development effort can be orthogonal. Something gets planned in for i4 that would take more than one iteration to design, and suddenly you’re swamped. No fucking party for you!\n
  19. Of course because that short uncomplicated planning period doesn’t leave a lot of time to front-load the design, you may have tried doing something like this. This never works because design effort and development effort can be orthogonal. Something gets planned in for i4 that would take more than one iteration to design, and suddenly you’re swamped. No fucking party for you!\n
  20. Oh thank God, you think, this extra iteration gives me a bit more time to front-load the design work! You may have seen this pattern at work, I know Lynn Miller famously wrote a case study around it, and Johanna Kollman has presented it as her research solution: http://www.agileproductdesign.com/useful_papers/miller_customer_input_in_agile_projects.pdf Fortunately Johanna’s not in the room tonight, because...\n
  21. Nope, all that happens is the design work expands to fill the time available – only because it never had enough time to be done right in the first place. Design and development can be more orthogonal than this – you need to either front-load as much as you can, or find ways to simplify the design process and make it responsive to changing priorities.\n
  22. Nope, all that happens is the design work expands to fill the time available – only because it never had enough time to be done right in the first place. Design and development can be more orthogonal than this – you need to either front-load as much as you can, or find ways to simplify the design process and make it responsive to changing priorities.\n
  23. Nope, all that happens is the design work expands to fill the time available – only because it never had enough time to be done right in the first place. Design and development can be more orthogonal than this – you need to either front-load as much as you can, or find ways to simplify the design process and make it responsive to changing priorities.\n
  24. Nope, all that happens is the design work expands to fill the time available – only because it never had enough time to be done right in the first place. Design and development can be more orthogonal than this – you need to either front-load as much as you can, or find ways to simplify the design process and make it responsive to changing priorities.\n
  25. Nope, all that happens is the design work expands to fill the time available – only because it never had enough time to be done right in the first place. Design and development can be more orthogonal than this – you need to either front-load as much as you can, or find ways to simplify the design process and make it responsive to changing priorities.\n
  26. Nope, all that happens is the design work expands to fill the time available – only because it never had enough time to be done right in the first place. Design and development can be more orthogonal than this – you need to either front-load as much as you can, or find ways to simplify the design process and make it responsive to changing priorities.\n
  27. Nope, all that happens is the design work expands to fill the time available – only because it never had enough time to be done right in the first place. Design and development can be more orthogonal than this – you need to either front-load as much as you can, or find ways to simplify the design process and make it responsive to changing priorities.\n
  28. Nope, all that happens is the design work expands to fill the time available – only because it never had enough time to be done right in the first place. Design and development can be more orthogonal than this – you need to either front-load as much as you can, or find ways to simplify the design process and make it responsive to changing priorities.\n
  29. But what happens if you focus on that nice uncomplicated planning? Here’s a typical planning session. Gosh, look at that - you probably know what’s being delivered in R1 a long time before R1 starts development. Note that it’s easier (cheaper) to add time to planning than development, so if you need more time, ask early!\n
  30. But what happens if you focus on that nice uncomplicated planning? Here’s a typical planning session. Gosh, look at that - you probably know what’s being delivered in R1 a long time before R1 starts development. Note that it’s easier (cheaper) to add time to planning than development, so if you need more time, ask early!\n
  31. But what happens if you focus on that nice uncomplicated planning? Here’s a typical planning session. Gosh, look at that - you probably know what’s being delivered in R1 a long time before R1 starts development. Note that it’s easier (cheaper) to add time to planning than development, so if you need more time, ask early!\n
  32. But what happens if you focus on that nice uncomplicated planning? Here’s a typical planning session. Gosh, look at that - you probably know what’s being delivered in R1 a long time before R1 starts development. Note that it’s easier (cheaper) to add time to planning than development, so if you need more time, ask early!\n
  33. But what happens if you focus on that nice uncomplicated planning? Here’s a typical planning session. Gosh, look at that - you probably know what’s being delivered in R1 a long time before R1 starts development. Note that it’s easier (cheaper) to add time to planning than development, so if you need more time, ask early!\n
  34. But what happens if you focus on that nice uncomplicated planning? Here’s a typical planning session. Gosh, look at that - you probably know what’s being delivered in R1 a long time before R1 starts development. Note that it’s easier (cheaper) to add time to planning than development, so if you need more time, ask early!\n
  35. But what happens if you focus on that nice uncomplicated planning? Here’s a typical planning session. Gosh, look at that - you probably know what’s being delivered in R1 a long time before R1 starts development. Note that it’s easier (cheaper) to add time to planning than development, so if you need more time, ask early!\n
  36. So what process does a BA go through to turn analysed requirements into epics? Well, it’s another iterative process. Define what you think the behaviour is, validate that with the stakeholders, refine your assumptions based on their response. Wait a minute...\n
  37. \n
  38. \n
  39. \n
  40. \n
  41. \n
  42. \n
  43. So here are the BA’s high-level tasks and the corresponding UX tasks. Oooh! I see a synergy!\n
  44. So here are the BA’s high-level tasks and the corresponding UX tasks. Oooh! I see a synergy!\n
  45. So here are the BA’s high-level tasks and the corresponding UX tasks. Oooh! I see a synergy!\n
  46. So here are the BA’s high-level tasks and the corresponding UX tasks. Oooh! I see a synergy!\n
  47. So here are the BA’s high-level tasks and the corresponding UX tasks. Oooh! I see a synergy!\n
  48. So here are the BA’s high-level tasks and the corresponding UX tasks. Oooh! I see a synergy!\n
  49. Also, keep the list of stakeholders with UX input as small as possible. I don’t care how many stakeholders you have, only a subset really need input into UX and design - your job is to whittle that subset to the very minimum. Conspire with the BA on this one, believe me they have strategies for doing this sort of thing.\n
  50. Also, keep the list of stakeholders with UX input as small as possible. I don’t care how many stakeholders you have, only a subset really need input into UX and design - your job is to whittle that subset to the very minimum. Conspire with the BA on this one, believe me they have strategies for doing this sort of thing.\n
  51. Also, keep the list of stakeholders with UX input as small as possible. I don’t care how many stakeholders you have, only a subset really need input into UX and design - your job is to whittle that subset to the very minimum. Conspire with the BA on this one, believe me they have strategies for doing this sort of thing.\n
  52. Also, keep the list of stakeholders with UX input as small as possible. I don’t care how many stakeholders you have, only a subset really need input into UX and design - your job is to whittle that subset to the very minimum. Conspire with the BA on this one, believe me they have strategies for doing this sort of thing.\n
  53. Also, keep the list of stakeholders with UX input as small as possible. I don’t care how many stakeholders you have, only a subset really need input into UX and design - your job is to whittle that subset to the very minimum. Conspire with the BA on this one, believe me they have strategies for doing this sort of thing.\n
  54. Also, keep the list of stakeholders with UX input as small as possible. I don’t care how many stakeholders you have, only a subset really need input into UX and design - your job is to whittle that subset to the very minimum. Conspire with the BA on this one, believe me they have strategies for doing this sort of thing.\n
  55. The last point only applies if you’re not being cavalier about your wireframes like I am\n
  56. The last point only applies if you’re not being cavalier about your wireframes like I am\n
  57. The last point only applies if you’re not being cavalier about your wireframes like I am\n
  58. The last point only applies if you’re not being cavalier about your wireframes like I am\n
  59. The last point only applies if you’re not being cavalier about your wireframes like I am\n
  60. By the time development begins, you’re still not going to have everything ready. But you should know what’s coming, and you should be able to feed a starting point to the developers, and prioritise your own goals for the coming iterations. LIASE WITH THE BAs ON THAT POINT.\n
  61. \n\n
  62. \n\n
  63. We’ll talk about stubbed design and UX debt in a moment\n\n
  64. We’ll talk about stubbed design and UX debt in a moment\n\n
  65. We’ll talk about stubbed design and UX debt in a moment\n\n
  66. We’ll talk about stubbed design and UX debt in a moment\n\n
  67. We’ll talk about stubbed design and UX debt in a moment\n\n
  68. Change is a fact of life in software development. Agile is a tool designed around that fact, and to make it work, Software Engineers have had to develop strategies and tools. Now it’s our turn to either make those strategies apply to UX or develop our own. Because ultimately Agile will allow us to make better things faster.\n
  69. Change is a fact of life in software development. Agile is a tool designed around that fact, and to make it work, Software Engineers have had to develop strategies and tools. Now it’s our turn to either make those strategies apply to UX or develop our own. Because ultimately Agile will allow us to make better things faster.\n
  70. \n
  71. \n
  72. \n
  73. \n
  74. \n
  75. \n
  76. \n
  77. Stubbed design means that forthcoming requirements don’t need to hold up development in the present. Maybe you have an ugly but functional flow that you can add with minimal branding. Or maybe you have the visual design roughly set but the behaviour is still being refined. Get it to a form where it can be included - maybe that’s just a static image - and get it in there\n
  78. Stubbed design means that forthcoming requirements don’t need to hold up development in the present. Maybe you have an ugly but functional flow that you can add with minimal branding. Or maybe you have the visual design roughly set but the behaviour is still being refined. Get it to a form where it can be included - maybe that’s just a static image - and get it in there\n
  79. Stubbed design means that forthcoming requirements don’t need to hold up development in the present. Maybe you have an ugly but functional flow that you can add with minimal branding. Or maybe you have the visual design roughly set but the behaviour is still being refined. Get it to a form where it can be included - maybe that’s just a static image - and get it in there\n
  80. Flag your stubs so stakeholders in demos clearly know what’s functional and/or final and what isn’t.\nWe use a class to put the stubbed element into pos:rel so that the specificity required to override it is very low - this way we don’t fuck up any prior-positioned elements. Also you can set the nodeploy folder in SVN not to be deployed on releases, so even if the stub class stays in the doc, the image won’t be, and no-one with a life will be any the wiser.\n
  81. Here’s an example of one of my stubs - the behaviours weren’t defined, the js wasn’t written but for demos we put this in to stop stakeholders asking why one of the landing pages was so empty.\nNow, this can be a risky strategy. Stakeholders might see a static image and assume it works. Or they may see the ugly but functional flow and assume that’s how it’s always going to look. So it’s important to have been priming stakeholders on your approach as early as possible.\n
  82. This isn’t the only strategy for dealing with UX debt – you have to work out what works best for you and your team. You could also work one day a week on UX debt, or use the last iteration as a stability rush. Other suggestions for what might constitute UX debt - Legacy Browser Support, or CSS3 enhancements; give example of MW SecondaryAction buttons\n
  83. This isn’t the only strategy for dealing with UX debt – you have to work out what works best for you and your team. You could also work one day a week on UX debt, or use the last iteration as a stability rush. Other suggestions for what might constitute UX debt - Legacy Browser Support, or CSS3 enhancements; give example of MW SecondaryAction buttons\n
  84. This isn’t the only strategy for dealing with UX debt – you have to work out what works best for you and your team. You could also work one day a week on UX debt, or use the last iteration as a stability rush. Other suggestions for what might constitute UX debt - Legacy Browser Support, or CSS3 enhancements; give example of MW SecondaryAction buttons\n
  85. \n
  86. \n
  87. \n
  88. \n
  89. \n
  90. \n
  91. \n
  92. \n
  93. \n
  94. \n
  95. \n
  96. \n
  97. \n
  98. \n
  99. \n
  100. Here are a bunch of things that either don’t have time to talk about tonight or for the most part I don’t have answers for yet. I want to answer all of these, and I hope you’ll help me do that.\n
  101. Agile, as a discipline, is 10 years old this year. It’s rapidly becoming THE way that software is built. It’s not going to stop and wait for us to catch up, and it’s going to keep innovating and keep making the process leaner. We can try and keep bending our existing tools and processes around Agile, and watch as the theory and practice become ever more divergent, or we can start running to catch up. I believe we can get it right, and we should get it right, because...\n
  102. ...this is what happens if we get it right.\n
  103. \n