(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

1

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

2

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

3

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

4

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.

5

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.

6

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.

7

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)

8