Concept
Inleiding
Samenwerken
en
Communiceren
Wanneer
een
UX
designer
een
Ict‐omgeving
betreedt
waar
Agile
gewerkt
wordt
zorgt
dat
ervoor
dat
deze
persoon
op
een
iets
andere
manier
tewerk
moet
gaan
dan
hij
dat
gewend
is.
Hij
moet
namelijk
beter
samenwerken
met
het
ontwikkelteam
en
hij
moet
z’n
werk,
wat
in
een
vrij
hoog
tempo
wordt
gedaan
(research/wireframen/ontwerpen
etc.),
goed
communiceren
met
het
ontwikkelteam
zodat
deze
z’n
bevindingen
en
designs
meenemen
tijdens
het
bouwen
van
de
software.
“Bij
Agile
moeten
organisaties
een
omgeving
hebben
waarin
snelle
communicatie
tussen
teamleden
mogelijk
is.”
(Cohen
et
al.,
2004)1
Userstories
In
het
begin
van
een
Agile
project
(sprint
0)
worden
er
als
een
basis
voor
de
te
bouwen
applicatie
userstories
opgesteld
met
het
team
en
de
klant
(productowner),
deze
hebben
de
vorm
van
bv.
:
“Als
designer
wil
ik
graag
mijn
email
kunnen
managen
zodat
ik
in
contact
kan
blijven
met
mijn
gebruikers”
Volgens
velen
zijn
deze
user
stories
voor
UX’ers
geweldig
omdat
het
goed
te
vergelijken
is
met
bv.
persona’s
uit
de
UX
toolbox.
Een
UX’er
kan
hier
dus
een
geweldige
bijdrage
aan
leveren
door
in
deze
beginfase
de
business
en
gebruikers
(strategielaag
van
Garett,
user
needs
en
site
objectives)
door
te
lichten
met
de
andere
tools
uit
de
UX
toolbox
om
erachter
te
komen
wat
deze
echt
nodig
hebben.
Al
deze
stories
bij
elkaar
vormen
de
product
backlog
van
het
project
en
hier
wordt
dan
in
samenspraak
met
de
klant
een
priorisering
aan
toegevoegd.
Echter
is
dit
vrij
zonde
om
te
doen
aangezien
deze
stories
tesamen
al
een
soort
van
backbone
vormen
van
de
applicatie
(Jeff
Patton,
2008).2
Deze
backbone
met
alle
subtasks
en
specificaties
zorgen
voor
een
mooie
structuur
die
gebruikt
kan
worden
voor
het
design
van
de
applicatie
maar
ook
voor
de
1
Cohen,
D.,
Lindvall,
M.,
&
Costa,
P.
(2004).
An
introduction
to
agile
methods.
In
Advances
in
Computers
(pp.
1‐66).
New
York:
Elsevier
Science.
2
http://www.agileproductdesign.com/blog/the_new_backlog.html
bouw
ervan.
Waarom
zou
je
het
uit
elkaar
halen?
Dat
is
alsof
je
een
mooie
boom
hebt
gekweekt
en
hem
vervolgen
ontdoet
van
z’n
bladeren
(de
stories
uit
de
productbacklog
losmaken
van
de
backbone
van
de
applicatie),
de
bladeren
vervolgens
in
aparte
zakken
stopt
(andere
prioriseringen
en
roadmaps
ervan
maken),
en
de
boom
omzagen
(de
meest
logische
structuur
weggooien).3
Als
UX’er
zou
je
de
beginstructuur
nog
meer
kunnen
finetunen
(met
de
klant)
zodat
je
echt
een
logisch
geheel
hebt
waar
je
vervolgens
mooi
mee
aan
de
slag
kunt
gaan.
Hiermee
kun
je
dan
makkelijker
tot
een
‘overall
concept’
komen
en
dit
helpt
je
ook
beter
je
designwerk
in
stukken
te
hakken.
Wat
ook
een
van
de
dingen
is
die
bij
Agile
UX
belangrijk/handig
kan
zijn
(Desiree
Sy,
2007)4
Snelheid
Omdat
Agile
snelheid
aan
het
ontwikkeltraject
toevoegt
(“delivering
value
fast”)
is
het
handig
om
je
designwerkzaamheden
strak
te
plannen
en
er
wordt
in
veel
gevallen
ook
gesproken
dat
‘paralell
tracks’
een
goede
manier
is
om
Agile
en
UX
te
combineren.
Dit
houdt
in
dat
je
qua
design
een
sprint
vooruit
loopt
op
het
ontwikkelwerk
en
dat
je
vervolgens
het
ontwikkelteam
volgt
om
wat
de
sprint
ervoor
is
gebouwd
te
testen.
Het
plaatje
hieronder
geeft
dat
model
weer.
(Desirée Sy, Adapting Usability Investigations for Agile User-centered Design)
Als
UX
designer
heb
je
dus
je
handen
vol
met
werk,
je
bent
aan
het
ontwerpen
voor
de
volgende
sprint
(S+1),
je
bent
informatie
aan
het
verzamelen
voor
nog
3
http://www.agileproductdesign.com/blog/the_new_backlog.html
4
http://www.upassoc.org/upa_publications/jus/2007may/agile‐ucd.pdf
een
sprint
verder
(S+2)
en
ook
nog
het
design
aan
het
testen
van
de
vorige
sprint
(S‐1)
(wat
overigens
weer
kan
zorgen
voor
info
voor
S+2)
.
Door
al
deze
drukte
is
er
natuurlijk
niet
altijd
een
mogelijkheid
om
met
het
team
te
praten
over
je
designs
en
hoe
ze
je
designs
precies
moeten
verwerken.
“User
experience
people
working
on
Agile
teams
become
masters
of
development
time
travel
nimbly
moving
back
and
forth
through
past,
present,
and
future
development
work.”
(Jeff
Patton)
Idee
Het
concept
waar
ik
aan
zit
te
denken
is
eigenlijk
al
een
tijd
geleden
ontstaan
maar
dan
in
een
iets
andere
vorm.
Ik
had
toen
een
idee
om
een
digitale
applicatie
te
maken
welke
het
Agile
process
zou
vergemakkelijken
tot
een
volledig
digitale
workflow.
Niets
geen
‘geeltjes’
op
de
muur
hangen,
niets
geen
papieren
product
backlog
meer,
niets
geen
whiteboard
met
een
burndownchart
erop.
Alles
verpakken
tot
een
digitaal
product
dat
alles
automatiseerd
en
waar
eventueel
een
smartboard
aan
kan
worden
toegevoegd
om
het
geheel
visueler
te
maken
in
de
ruimte
waar
men
zit.
Hier
ben
ik
uiteindelijk
vanaf
gestapt
omdat
die
papieren
tools
er
nou
juist
voor
zorgen
dat
mensen
niet
meer
8
uur
per
dag
in
hun
beeldscherm
zitten.
Hierdoor
wordt
de
Agile
teamspirit
nou
juist
gevoed.
En
alle
papieren
dingen
aan
de
muur
zorgen
juist
voor
een
cohorent
beeld
bij
het
team
(en
voor
meer
aankleding/sfeer
eventueel).
En
bovendien
zijn
er
al
erg
veel
digitale
tools
aanwezig
die
dit
bewerkstelligen.
Het
idee
hierboven
heb
ik
dus
snel
laten
varen
maar
heeft
uiteindelijk
toch
meegespeeld
bij
het
komen
tot
mijn
nieuwe
concept.
Ik
wil
namelijk
nu
alsnog
een
digitale
tool
maken
als
hulpmiddel
binnen
het
Agile
project,
maar
deze
keer
niet
zozeer
voor
het
hele
Agile
proces,
nu
juist
om
de
communicatie
die
zo
belangrijk
is
tussen
de
designers
en
de
ontwikkelaars
te
onderstuinen
en
mogelijkheden
te
bieden
aan
de
UX
designer
om
z’n
werk
te
vergemakkelijken,
te
verduidelijken
en
te
ondersteunen.
De
digitale
tool
kan
eventueel
‘standalone’
worden
ingezet
bij
Agile
maar
ook
zou
het
makkelijk
zijn
als
het
zou
aansluiten
op
bestaande
issue/bugtracking/projectmanagement
systemen
als
Jira
(veel
gebruikt
bij
pure
Ict
projecten)
en
Basecamp
(veel
gebruikt
in
de
creatieve
industrie).
Een
aantal
zaken
zouden
in
de
applicatie
terug
moeten
komen.
Deze
hebben
ook
direct
temaken
met
de
elementen
die
eerder
zijn
genoemd
in
de
inleiding
van
dit
stuk:
‐ een
inzicht
verschaffen
in
de
oorspronkelijke
‘backbone’
van
de
applicatie
met
user
stories,
voordat
hij
is
opgedeeld
en
geprioriseerd.
‐ het
selecteren
van
brokken
designwerk
hieruit,
die
direct
met
elkaar
te
‐ ‐
‐ ‐
maken
hebben.
Is
handig
voor
het
designen
ervan,
“tien
vliegen
in
een
klap”.
het
koppelen
van
designdeliverables
hieraan
zodat
het
ontwikkelteam
makkelijk
kan
zien
hoe
de
user
stories
(of
brokken)
en
dus
eigenlijk
de
applicatie
qua
(interaction‐)design
in
elkaar
moeten
komen
te
zitten.
het
onderstuint
op
deze
manier
de
communicatie
en
samenwerking
tussen
de
twee
(of
meer)
disciplines.
Let
wel:
natuurlijk
is
het
geen
vervanging
van
de
normale
interpersoonlijke
communicatie,
het
is
wel
een
onderstuining.
het
helpt
de
UX’er
z’n
werkzaamheden
te
plannen
door
inzichtelijk
te
hebben
waar
het
ontwikkelteam
mee
bezig
is
en
waar
het
de
komende
sprint(s)
mee
bezig
gaat
zijn.
Geen
ge‐email
meer
van
documenten,
en
geen
verloren/verdwaalde
documentatie
die
niemand
leest
op
bijvoorbeeld
wiki’s.
Informatie
bevindt
zich
dicht
bij
waar
het
gebeurt,
namelijk
tussen
(eigenlijk
verbonden
aan)
de
userstories,
tasks,
features,
bugs,
to
do’s,
etc.
Visueel
Hieronder
staat
als
het
ware
de
backbone
afgebeeld
zoals
hij
in
de
applicatie
voor
kan
komen.
Groen
zijn
de
userstories,
geel
zijn
de
tasks,
en
roze
zijn
de
subtasks
of
task
details.
Wanneer
het
ontwikkelteam
druk
bezig
is
met
het
bouwen
van
het
email
gedeelte
van
de
software
waar
een
mail
verzonden
wordt
kan
het
designteam
al
aan
de
slag
gaan
met
het
gedeelte
waar
mail
kan
worden
verwijderd.
Dit
kan
men
dan
netjes
aangeven
in
de
applicatie
en
natuurlijk
is
dit
van
tevoren
besloten
met
het
ontwikkelteam.
Deze
gaan
in
de
sprint
erna
aan
de
slag
met
dit
ontwerp
van
‘deleten
van
email’.
Maar
misschien
hoort
er
bij
het
deleten
van
de
email
rekening
te
worden
gehouden
qua
design
met
iets
anders
uit
de
backlog.
Designers
kunnen
dit
nu
dus
in
een
vroeger
stadium
zien
aankomen,
als
er
ook
in
de
beginfase
(sprint
0)
al
is
nagedacht
over
het
‘overall
concept’.
Aan
de
stories
en
tasks
kan
dan
designwerk
en
andere
informatie
worden
gekoppeld
zodat
ontwikkelaars
kunnen
ziet
welke
elementen
moeten
worden
gebouwd
en
welke
structuur
er
moet
worden
aangehouden.
Extras
Dit
is
een
hele
simpele
versie
van
het
concept
natuurlijk,
maar
er
kan
hier
nog
vanalles
aan
worden
toegevoegd
om
te
zorgen
dat
de
Agile
projecten
soepeler
verlopen.
Hierbij
kun
je
bijvoorbeeld
denken
aan
versiebeheer
van
de
designs,
een
tijdlijn
waarop
te
zien
is
hoe
de
paralleltracks
binnen
het
project
verlopen,
een
customerside
om
input
van
de
klant
te
krijgen,
ondersteuning
voor
tools
als
Balsamiq/Axure/Photoshop
ed.
Maar
het
is
een
tool
die
een
goeie
extra
functionaliteit
zou
kunnen
toevoegen
aan
bestaande
software
(misschien
in
de
vorm
van
een
plugin).
