My talk from UX Camp London 2011, about the lie of "No Big Design Up Front," the opinion that UX people need to be less lazy and feckless, and finding the gap between the two where Agile UX can flourish.
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
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
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
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
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
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
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
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
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
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;}
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
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”
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!
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
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
\n
\n
\n
\n
\n
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
\n
\n
\n
\n
\n
\n
So here are the BA’s high-level tasks and the corresponding UX tasks. Oooh! I see a synergy!\n
So here are the BA’s high-level tasks and the corresponding UX tasks. Oooh! I see a synergy!\n
So here are the BA’s high-level tasks and the corresponding UX tasks. Oooh! I see a synergy!\n
So here are the BA’s high-level tasks and the corresponding UX tasks. Oooh! I see a synergy!\n
So here are the BA’s high-level tasks and the corresponding UX tasks. Oooh! I see a synergy!\n
So here are the BA’s high-level tasks and the corresponding UX tasks. Oooh! I see a synergy!\n
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
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
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
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
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
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
The last point only applies if you’re not being cavalier about your wireframes like I am\n
The last point only applies if you’re not being cavalier about your wireframes like I am\n
The last point only applies if you’re not being cavalier about your wireframes like I am\n
The last point only applies if you’re not being cavalier about your wireframes like I am\n
The last point only applies if you’re not being cavalier about your wireframes like I am\n
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
\n\n
\n\n
We’ll talk about stubbed design and UX debt in a moment\n\n
We’ll talk about stubbed design and UX debt in a moment\n\n
We’ll talk about stubbed design and UX debt in a moment\n\n
We’ll talk about stubbed design and UX debt in a moment\n\n
We’ll talk about stubbed design and UX debt in a moment\n\n
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
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
\n
\n
\n
\n
\n
\n
\n
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
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
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
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
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
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
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
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
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
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
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