1. 1
(slide 1)
How We Integrate UX and Design into Agile
(slide 2)
Just a little bit about me first.
My name is Gavin Coughlan. I have been working at Boost New Media for the last 6
years, initially as a frontend developer, after which I moved in to project management.
Boost adopted Scrum about three years ago, and I started the transition from project
manager to Scrum Master at the same time, a path I’m sure a lot of you have taken. At
Boost no longer works outside of Scrum at all, it is written in to all our proposals now,
and I guess have no need to go in to the benefits we have seen at Boost.
I now run several Scrum workshops for free at Boost to help spread the good word, as
well as facilitate our monthly Scrum lunch, or Scrunch, where we invite Scrum
practitioners around Wellington to discuss any issues or successes we are having. It
has attracted a wide array of people from various industries so far, and is a great way to
informally meet other people going through the same things as yourself. I also get
ritually abused and man the mixing desk of our fortnightly Agile TV show, The Board.
So my talk today will be about UX and design within Scrum, and it will be very much
from a Scrum Masters point of view.
I’ll quickly run through what points I’ll be talking about today
(slide 3)
• Why the waterfall approach fails
• Some existing approaches to UX in Scrum
• Our initial approach to Agile design
• Our current approach to agile design
• What we will be doing in the future
We will have time after the presentation for questions where I’ll be joined by Sean
Lipidis, one of the designers at Boost, so we will be able to answer anything you ask
from a couple of different perspectives.
I want to start by getting in to why I’m even here. Why is UX and Design in Scrum even
a topic we feel the need to discuss? The origin of Scrum lies in software engineering,
there was a need to change the way we worked to adapt to change quicker, so it
obviously concentrates on development practises, but UX and design is trickier to break
down in to smaller increments. Upfront designs have been the norm for so many years

2. 2
that people find it hard to imagine a different approach, and there has been a lot of
resistance in the design world to Scrum. But there was resistance in the software
engineering world at the start too, and it’s up to us to change that. It can work, in fact, it
not only works, but in my opinion is a much more logical approach to UX design.
Hopefully by the end of today’s presentation you’ll see why.
The first thing I want to go through is how Boost worked when I first joined back in 2006,
the waterfall approach.
(slide 4)
I won’t go in to the pitfalls of the waterfall process as a whole, just how it fails when it
comes to design and UX. And the reason I am mentioning this at all is to illustrate how
far we have come, and how some approaches to UX design in Scrum are really quite
similar to waterfall.
On each project we would undertake a large discovery phase where we would try to get
an understanding of everything the client wanted, from full functionality to a complete
look and feel. Moodboards would be produced and pixel perfect wireframes would go
through many iterations until we were happy to move of to a full site design.
This would involve many rounds of visual design, an often painful process where clients
couldn’t divorce themselves from the idea that what they saw at this stage had to be the
final product. There was a huge amount of back and forth as each and every element
that that made up a site was perfected. During this process there was also a hell of a lot
of waste which costed both sides money.
Once we had a design, it was set in stone. But sites aren’t buildings meant to last many
years in their initial form. In fact, a site built that way is a failure in design. They should
be modified and improved continuously over time. In the waterfall process the design is
finished before development even begins, and if the needs of the site change, as they
always will, all the design hours have been used up in the initial phase of the process
and can’t be revisited.
I’m going to touch on a couple of the the current approaches to UX in Scrum that we
avoided as they seemed doomed to failure from the outset.
The first is doing a big upfront design.
(slide 5)
Big upfront design is when all the design is completed at the start of a project, once the
design is nailed down development can start, and the team can start their sprints. This
is basically no different then using the waterfall approach, it isn’t agile and it promotes
waste. Designers can’t see any potential issues without first seeing some

3. 3
implementation, and assumptions are made about what is needed and may never
actually be required.
The second approach is skinning.
(slide 6)
This is where you see the developers implement all the features and the design is
brought in at the end of the project to apply the design. Again Boost avoided this
approach as it means that there is a lot of rework involved as the UX is fixed.
Developers are not usually experts in UX, so this is not a priority as the design-free site
is built. So a designer has to work backwards and fix the issues that will definitely arise,
which also leads to a lack of consistency interactions.
And if a designer is brought in at the end, how do they make the best decisions? They
have not been involved up to this point and aren’t intimate with the site.
Another issue we could see here is the development period eating in to the budget. if
you tell a designer they will have 50 hours of design time on a project, but when it
comes time for them to jump on board there is only 20 hours left, the quality is going to
suffer pretty drastically.
We didn’t take either of these approached when we started using Scrum. When we first
started, we applied the washing machine approach.
(slide 7)
The washing machine approach involves wireframing and designing a sprint ahead of
time. You start with a sprint 0 and do all the UX design work for sprint 1, and in sprint 1
you do all the UX design work for sprint 2, and so on throughout the project. User
testing is done as much as possible and the UX is revised as needed. Stories will have
tasks for UX and design, and often the these tasks are separated out and worked on
well in advance of development
We used this particular approach when we began the DigitalNZ project.
(slide 8)
Digital New Zealand is a project led by the National Library, and it aims to make New
Zealand’s digital content easy to find, share and use. This includes content from
government departments, publicly funded and private organisations and community
groups in the culture and heritage sector.
We worked closely with DigitalNZ to create wireframes and design a sprint ahead,
essentially a sprint 0. We user tested as much as we could in the time allowed until the

4. 4
UX was good enough to start development, with the intention of refining as the project
progressed.
Once we got in to the sprints proper we kept doing design and UX a sprint in advance,
splitting the design out from future stories occassionally so we could work on it ahead of
time.
We were finally able to minimise the amount of rework and waste associated with a
waterfall approach, and the design and UX was fully integrated in to the process, which
in turn lowered the cost of any necessary amendments.
But there were still downsides associated with this approach. We still had to revisit
earlier designs as more features were added in order to keep it coherent and consistent.
Also, the designers felt that they were not allowed to consider the site as a whole when
designing it, and the staggered approach frustrated them. And a frustrated designer is
not going to be producing there best work. And it’s not all that agile, as we are not
valuing the people over the process this way.
And finally, we never felt that a Sprint 0 was ideal for us. We never thought this
delivered value, something we wanted to do from the very beginning of the project.
Sprint 0 often seemed to just become a time for documenting requirements and creating
wireframes and design upfront, again, not very agile. We wanted to integrate these
elements in to the stories so that we could deliver small increments of value, and
releasable features, from sprint one.
So that takes us to the approach we use today, which isn’t to say this is the approach
we will be using tomorrow. We are constantly looking to refine and improve our design
process. Boost has had many conversations and meetings to seek out better ways of
integrating design in to the Scrum process, some productive and some heated.
We don’t claim to have the silver bullet, and whilst our current approach has it’s
challenges, it is the best process we have discovered.
We’ll use The National Library website as an example to help illustrate how we do
things at Boost.
(slide 9)
The National Library beta website launched in October 2011 for public feedback and
has since replaced the Library’s corporate website, as well as a number of its separate
and siloed collection databases.
In the past we had produced hi-fidelity wireframes to outline all the functionality and UX
of a site. We produced these wireframes with a variety of tools and printed them out so

5. 5
we could go through them with clients. This again led to time being used up that didn’t
have to be.
So we needed to adjust how we worked, and we used the concept of hi-fidelity
wireframes as a starting point to do so.
(slide 10)
We created a simple, usable design that was very modular. Rather then concentrate on
any real design elements, the designer was focussed on the UX during this phase. The
designs were built directly in HTML and CSS by the designer, and effectively became
working, usable high fidelity wireframes. This dramatically improved the workflow
between the designer and the developer, as they were both working on the same
features at the same time, with feedback being passed back and forth with an efficiency
that wasn’t possible before.
The designs followed a set of simple rules which enabled the developers to implement
features. Because this design was so modular it could be tweaked as we went by the
designer as they saw fit.
One thing that is worth pointing out is that the product owner had very limited input into
the design at this stage. This ensured that the process was kept as lightweight as
possible.
We were able to do this due to the long history we had working together. There was a
high degree of trust there, and of course trust needs to be earned. We are using this
process on other projects now, and luckily we also have earned trust with these other
clients as well. We realise that this would be much more difficult to utilise with a new
client.
Clients traditionally expect a full design and wireframes outlining the UX in advance of
the build. Many even expect this during the proposal process. This is the way that it has
always been done but of course that doesn’t mean the old way works or should be
continued to be followed. Convincing new clients that they will achieve more value more
quickly this way is a challenge, and it will be for some time.
Anyway, back to the National Library beta.
(slide 11, 12, 13, 14)
As mentioned before, the initial design was implemented immediately and a separate
Git repository was setup for the designer. This was used to manage and share the
HTML and CSS. Whenever possible the designer provided the HTML and CSS for the
implemented design, correcting semantic or accessibility issues as he worked.

6. 6
UX testing was undertaken from day one. This largely took the form of interviews with
people from the user group. As soon as we had results from this testing, they were
presented back to the whole team.
If we were unsure about the best approach for a particular feature in terms of the UX,
we would choose the option we felt worked best and implement it. We could then test
how this work - this was a good way to cut down on the time it takes second guessing
the best option and what may be the best experience for the user.
We were very aware of the pitfalls of leaving the design until late in a project, as
previously mentioned, so we established a rough timeline for the main design. From
there we could plan backwards from the required launch date to establish when in the
project we should start the full design.
Because the interim design was so lightweight and modular, we could easily fit any
design needed for new functionality into the designers workflow while he was also
working on the full site design. The UX was constantly revised as new features were
added.
At this stage, the designer now had an intimate knowledge of the project as a whole,
especially the audience. This made the design process a lot more fluid, and the design
was much more informed then if we had produced it all before any development had
begun.
We started with a reverse brief to the client which took into account the feedback on the
interim design. The designer had a wishlist of ideas for UX refactoring to implement
when doing the full design, which were presented to the product owner. At that stage
the designer and product owner worked together to prioritise these ideas.
The next step was to create moodboards so that the client could provide some focussed
feedback.
(slide 15, 16, 17)
We create the moodboards to take the client through some ideas for colours, fonts and
various design elements across the site such as button types and navigation styles. The
client picks out the bits they like and don’t like, and we feed this information in to the full
design. It’s an invaluable process that we use on all our projects.
The initial design was then produced and presented to the client.
(slide 18)
This only went through one minor revision and was accepted. Due to the constant
involvement of the designer throughout the project, alongside the client, the back and
forth when it comes to producing a design has been drastically reduced.

7. 7
Once we had an accepted design, the designer then iterated it out through all of the
existing functionality across the site.
(slide 19, 20, 21)
Due to the fact that we already had the HTML and CSS in place, and the workflow
within the team fine tuned, the process of implementing the design was relatively
straightforward.
On top of that, there was no need for wireframes at this stage as we had a working site,
which removed a dependency for the designer that enabled the work to proceed as fast
as possible.
In summary the key benefits were:
(slide 22)
• Workflows established and optimised early
• Simple initial design reduces cost of adding new features and revisiting design
• Have a potentially shippable product at all times
• Designer had a great deal of intimacy with the client and the project when creating the
final design
• Able to design the site as a whole rather than piecemeal, which contributed to a high
level of design polish which has in the past been difficult with agile projects
Challenges included:
(slide 23)
• Users became quite attached to the interim design
• Required a very high level of trust with the client
• Required and a true team approach
• Wireframes could still be a bottle-neck during development as it took time to explore
different UX options
I’d also like to quickly talk about a process we used with a new client on a short project.
(slide 24)
NZonScreen is the online showcase of New Zeland television and music video, with
over 2,000 titles available to watch on their site for free. they came to us with a basic
brief, they wanted an iPhone app, Reel Choice, which played the latest releases from
the NZonScreen website.

8. 8
We did have to create concepts for the app as they needed to show these to get funding
for the project.
(slide 25)
These concepts acted as wireframes for the project. We did no design upfront, and
even though this was a new client, we were able to begin development immediately
before any designs were seen. We were able to do this largely because the client was
very keen to work in an Agile way, in fact they didn’t want to work any other way, so
they trusted the process.
We had four weeks to complete the app, we started doing one week sprints, but after
sprint one the team decided during a retrospective that two week sprints would be
prefereable so that they could have more to show at the reviews.
Much like the National Library project, the developer and the designer worked together
very closely. In this case they actually sat beside each other, and were committed 100%
to the project. The communication between them was constant, and both had an equal
understanding of what they were trying to achieve at all times.
When the client saw each iteration at the reviews, they saw both the functionality and
the design for the first time simultaneously. This allowed us to get the app completed in
a short timeframe, and due to the interaction between designger and devloper, the
quality did not have to sufer as a result.
And finally, what Boost will be doing in the future.
(slide 28)
We are continuing to inspect and adapt our process and have some ideas to help
smooth out some of the pain points.
• Get a good headstart on the UX
• Reduce the time to complete wireframing
• Team design studios - bring the whole team together for a wire framing session for
each new feature
• Improve workflow between developer and designers
So thats the presentation, I will be posting this on the Boost blog tomorrow, thank you
very much for listening.
We have some time for questions now, where I’ll be joined by a Boost designer, Sean
Lipidis.
(slide 29)