You've done your research, synthesized some brilliant ideas, and have even brought your design through team reviews - congratulations, but the fun is just beginning! Between the next morning and the ship date there is almost always a stream of change requests ranging from, "You forgot to specify how to handle this error case" to "We need to make this menu more prominent because usability test participants are missing it". In the later phases of a release cycle, each change request presents a conundrum: Design changes may be crucial to the quality of user experience. Yet changes that would have been no-brainers in previous weeks are now much more expensive and controversial, because teams need stable specifications to do their jobs well. As the poor designer in the middle of it all, you may feel like you can't win. And you can't quit the game. This talk addresses the challenges of change management, one of a designer's biggest and most visible responsibilities. It includes a concrete set of processes and practices to handle change requests, and thoughts on promoting a culture of addressing change responsibly, efficiently, and with empathy for everyone involved.

1. Su-Laine Yeo Brodsky
UX Designer
2015
Managing
Design Change
in the Software
Development
Process

2. Agenda
• What is “late” design change?
• How does it affect project team
members?
• What is a good change management
process?
• How can organizations handle
change better?
Participate Please!

3. UX spec
signed off
Code
freeze Release
Project
start
Normal design
process
Late design
changes

5. You need to start building the product
before the design specification is
perfect

6. How does change affect team
members?

7. Yes, but not on the original schedule.
You can’t constantly change the design
and expect a quality product.
Developer
Implementing that widget is a lot harder than I
thought it was going to be, so I’m putting in this
other widget instead.
Developer

8. Every spec change requires us to update
test plans, test that the change was
implemented, and possibly regression-
test.
QA Specialist

9. This affects fifteen translators.
Poor change management makes the
docs not match the software.
Developer
The button on this page says ‘Apply’ when on
every other page it says ‘Apply Now’ That’s
horrible.
Technical Communicator

10. Who needs to be involved in change
approvals?
How will this change affect the critical
path?
Developer
I’ll need to update the project plan.
Project Manager

11. Cost of Change vs.
Time
UX spec
is signed
off
Code
Freeze
Release
Project
start

12. “The general tendency for
quality to degrade with
change” - Steve McConnell

13. What is a good change
management process?

14. Signs of Good Decision-
Making
• Impacts on all departments are
considered
• Prioritization is comparable with bug
fixes
• Team can absorb change with effort
proportional to scope
• Decision-making is fast
CC BY-NC-ND 2.0, Roger Marks

15. Signs of Good
Communication
• Everyone knows what
we’re building
• People can efficiently find
out what has recently
changed

16. Scenario
1. Initial design process
2. Change request is made
3. Change Control Board reviews the
change
4. Designer communicates the change
CC BY-ND 2.0, Daniele Vico

17. Step 1: Initial Design
Usability
testing
Formal
design
reviews
with team
SignoffUser-
centered
design
process
Final
team
review

18. Use
metadata to
bridge gaps

19. Step 2: Change Request is
Made
1. Person requesting the change
brings it up with the designer.
2. Proposer and designer pre-screen
the request.
3. Designer describes the change
outside of the official spec and
sends it in an email or ticket to the
Change Control Board
“Nobody is using the
Snooze feature
because the snooze
option is off by
default”

20. Highlight
changes with
red

21. Step 3: Change Control Board Review
Where:
• Silence-
implies-
consent
• Email/Defect
Tracking
System
• Meeting
What:
• Who requested the
change, and
rationale
• Focus on future
risk/benefit
Who:
• Product
owner, not
designer,
should make
Go/No Go call

22. Often Worthwhile
• Feasibility problems
• Consistency
• Spec housekeeping: typos,
contradictions, missing info
• Under-specified edge cases
• Text strings (unless translated)
• Logic for disabling controls
• Progress feedback
• Defaults
CC BY 2.0, Kurtis Garbutt

23. Especially…

24. … developer-
driven changes
CC BY-NC-ND 2.0, J. McGuire

25. Step 4: Communicating
Changes
1. Log: Project manager can keep a
log of change requests
2. Highlight: UX designer updates
and highlights the official spec
3. Archive: UX designer updates the
spec version number and archives
the previous version
CC BY-NC-ND 2.0, Joel Kiraly

26. Updating and Highlighting the Spec (1 of 2)
Take a copy of the signed-off specification. Rename the copy.

27. Updating and Highlighting the Spec (2 of 2)
Merge the accepted changes into the complete spec.
Preserve highlighting.

28. Move the newest version to
the canonical spot
Move the older version to the
Archive folder
(On the Project Server)

29. How can organizations handle
change better?

30. Resilient Processes
Development
• Design code to be
refactored
• Separate language
strings
• Use low-fidelity
placeholders for
artwork
QA
• Automate testing
• Focus early
testing on
business logic,
scalability,
performance
Documentation
• Minimize repetition
• Use screenshots
sparingly
• Focus early on
planning, outlining,
and indexing
• Omit unnecessary
detail

31. Resilient Organizations
• Plan and budget for change
• Hire change-resilient people
• Promote respectful inquiry about
the risks and costs of change
CC BY-NC-ND 2.0, Bugsy Sailor

32. - Nicolas Gouy, Agile with Guts
Value comes from a
balance between chaos
and discipline
- Nicolas Gouy, Agile with Guts
CC BY-SA 2.0, Benson Kua

33. Su-Laine Yeo Brodsky
www.interelement.ca
Thank You!
Further Reading:
Software Project Survival
Guide by Steve McConnell
www.construx.com @sulaineyeo
Presenter: