181
User-Centred Agile Development
as problem framing. Singh ( 2008) notes that agile product goals are sometimes set
without ensuring an adequate study of the user’s needs and context.
User research and problem framing can be embedded into UCAD. However, many
UCAD processes do not emphasize framing or the iterative, divergent and convergent
aspects of this phase. UX designers may be expected to quickly gather user insights,
identify contextual needs and frame the problem on their own, once and at the start
of the process. If the team pushes to start coding, this necessitates the problem at
hand is already well defined. If not, the problem at hand may be based on weak or
faulty assumptions about users and context of use ( Constantine, 2001) – which will
also make the solutions to the problem ill-suited for real-life scenarios.
forgetting the context
Usage is affected by the social, physical and emotional contexts, by noise, time and space,
and by what happens prior to and parallel to any system interactions. These aspects must
be taken into consideration both when framing and understanding the problem at hand
and in the design and evaluation of the potential solutions. Prototype testing, even if
simulating realistic scenarios, may not be sufficient on its own to elicit needs.
It appears UCAD settings have less user contact and utilization of user involvement
compared to traditional UCD, emphasize user interface ( UI) over other design activities and prioritize feature implementation over i n-depth user research ( Begnum &
Thorkildsen, 2015; Silva da Silva, Silveira & Maurer, 2013). Singh ( 2008) observes
that agile development teams sometimes have difficulties seeing the whole UX
and relevant user-centred aspects, and instead focus on just- in-time deliveries. In a
worst-case scenario, one may imagine a team holding a faulty understanding of the
real issue at hand, a weak understanding of contextual needs and testing solutions in
non-realistic settings – such as a laboratory.
Focus on UI without investigating r eal-life issues may lead to the team being
unaware of important contextual aspects influencing the overall UX and usability of
a product. This is particularly important with regard to safety-critical solutions used
in complex sensemaking settings, where disregarding social, emotional, contextual
and timely aspects ( e.g. non-verbal communications, expectations, stress, noise, distractions, fatigue) may carry huge risks.
WorkloaD DiScrePancieS anD floW iSSueS
UCAD also faces challenges related to workload discrepancies, interdisciplinary
collaboration and flow issues. At least five generic models have been suggested for
UCAD, aiming to mitigate some of the issues described in the previous sections. The
models are not necessarily mutually exclusive nor are they exhaustive on possible
ways to organize UCAD workflows.
Parallel Model
In the parallel model, UX work and coding is separated, forming two different
“ tracks”. It has also been referred to as the “ dual track agile” model and proposes
doing UX work ahead of development ( Miller, 2005; Sy, 2007).
User-Centred Agile Development
as problem framing. Singh ( 2008) notes that agile product goals are sometimes set
without ensuring an adequate study of the user’s needs and context.
User research and problem framing can be embedded into UCAD. However, many
UCAD processes do not emphasize framing or the iterative, divergent and convergent
aspects of this phase. UX designers may be expected to quickly gather user insights,
identify contextual needs and frame the problem on their own, once and at the start
of the process. If the team pushes to start coding, this necessitates the problem at
hand is already well defined. If not, the problem at hand may be based on weak or
faulty assumptions about users and context of use ( Constantine, 2001) – which will
also make the solutions to the problem ill-suited for real-life scenarios.
forgetting the context
Usage is affected by the social, physical and emotional contexts, by noise, time and space,
and by what happens prior to and parallel to any system interactions. These aspects must
be taken into consideration both when framing and understanding the problem at hand
and in the design and evaluation of the potential solutions. Prototype testing, even if
simulating realistic scenarios, may not be sufficient on its own to elicit needs.
It appears UCAD settings have less user contact and utilization of user involvement
compared to traditional UCD, emphasize user interface ( UI) over other design activities and prioritize feature implementation over i n-depth user research ( Begnum &
Thorkildsen, 2015; Silva da Silva, Silveira & Maurer, 2013). Singh ( 2008) observes
that agile development teams sometimes have difficulties seeing the whole UX
and relevant user-centred aspects, and instead focus on just- in-time deliveries. In a
worst-case scenario, one may imagine a team holding a faulty understanding of the
real issue at hand, a weak understanding of contextual needs and testing solutions in
non-realistic settings – such as a laboratory.
Focus on UI without investigating r eal-life issues may lead to the team being
unaware of important contextual aspects influencing the overall UX and usability of
a product. This is particularly important with regard to safety-critical solutions used
in complex sensemaking settings, where disregarding social, emotional, contextual
and timely aspects ( e.g. non-verbal communications, expectations, stress, noise, distractions, fatigue) may carry huge risks.
WorkloaD DiScrePancieS anD floW iSSueS
UCAD also faces challenges related to workload discrepancies, interdisciplinary
collaboration and flow issues. At least five generic models have been suggested for
UCAD, aiming to mitigate some of the issues described in the previous sections. The
models are not necessarily mutually exclusive nor are they exhaustive on possible
ways to organize UCAD workflows.
Parallel Model
In the parallel model, UX work and coding is separated, forming two different
“ tracks”. It has also been referred to as the “ dual track agile” model and proposes
doing UX work ahead of development ( Miller, 2005; Sy, 2007).