Developer Blog

Agile Design: Kanban with our Web Designers

There seems to be large body of work on the use of Agile development ideas with UX Design, including some good ideas and tips. I also find that being an agile practitioner for the time I have, I want everyone else in the world to use the same processes. This is natural, especially as our adoption of Agile at Codeweavers has enhanced the working environment and business as a whole. So, when I found myself working with our new design department recently we started to look at the ways our existing Kanban boards could work with, and for, the design team.

Our design team has two designers, one who mainly concentrates on the interacting with clients and producing the design concepts, and one who does most of the CSS and implementation of the design. We also found that implementation of design didn’t just mean CSS and chopping up photoshop files, but producing materials for print, prototypes and interior design. This brought a distinction between the two types of work undertaken by the team: design and implementation.

In terms of the feedback loops involved in the whole process within team, this distinction worked well. As you’ll see from the case study below, the iterative emphasis you get from Agile works well for design. It meant that the designers could get feedback on the actual design of a web page/branding etc earlier and separately to the implementation.

The Kanban Board Layout


Our work in progress board in development has columns: Next, In Development, Done, Customer Acceptance, Live. This has come about over a couple of years of evolution and has been in place for around 4 months now – one of the longest standing layouts. As we’re keen on keeping an ubiquitous language at Codeweavers I thought it would be best for the design team’s work in progress boards to have the same columns, and we’d define the meaning in terms of the design and implementation.

Two Boards, Same Columns

The design team backlog works similarly to the development team as requests come in, some are important, some just ideas and some absolutely vital. This helped us trim down the list to just the important, upcoming tasks which we then split into Design or Implementation. The Design side of things could then be handled using next, in development (or “in design” technically), done and customer acceptance columns. Once the design process is finished the same set of columns could be used down stream but applied to implementation. Hopefully this will give us the correct balance of separation between the two types of task.

Next

The tasks that only need some implementation would go in the “Next” column for the implementation section and everything that needed a design from a concept or a brief would sit here.

In Design

For the design section of the board this means that the task is being researched, mocked up on Adobe Creative Suite and then presented as a design concept. As this is the artistic phase of the process the deliverable is often quite subjective to personal opinion so moving the item to done and then customer acceptance was likely to loop back into this column quite frequently. This is the nature of the job and the short feedback loops that Kanban offers really helps the design team.

Done

This column is useful for pre-approval within the team and within the organisation. It makes the feedback loop shorter if there are obvious pitfalls in design decisions before the organisation presents the deliverable to the client.

Customer Acceptance

A self explanatory column here – in traditional design process terms this would be the place to get “sign-off” from the customer thereby stamping approval of the design before it goes into implementation.

Next (Implementation)

Once a design is finalised it can go here waiting for build.

In Implementation

This column is where the design gets cut up into images, created as HTML, implemented through CSS, glued using art card or spread out using glitter.

Done (Implementation)

Once finished the task can be viewed by interested internal parties. As with the development team, any member of the team gets veto on a task being defined as “done” if they are not happy with the quality or completion of the task.

Customer Acceptance (Implementation)

This column is equivalent to the development board column for web based tasks as we’d deploy any changes to our DEMO environment. For print based work or other types of task this would be pre-flight checks, paper prototypes etc that are sent or presented to the client. All this allows a short journey for the task back into “In Implementation” if there are changes or problems needed. I wouldn’t expect any task to go all the way back to design from here but it would still fit in the process if needed – although we’d have to look at the upstream customer acceptance column if it did.

Live

Now all the work is completed and approved it can go to live, or the printers, or on the wall or where it needs to go. On the development board we record the date when a task moves to this column so that we can monitor flight time – but that’s another story for the design team – one step at a time.

Case Study: Car-Finance.net Design Realignment

Regular iterative feedback would have helped us during this piece of work as we could have delivered something to the customer earlier, got better, granular feedback and been able to incorporate feedback within the later parts of the design.

The design team were tasked with realigning the design of a multi part web site for our existing client. The design concept was delivered in one go as a multi page PDF covering each section of the site and when we go feedback there were issues with parts of the site that we duplicated across all pages. We quickly identified that, had we just done the home page and sent that for approval, the same feedback could then have been taken into account when designing all subsequent sections.

In terms of the implementation, we are going to brand each section separately and then approve and deliver it, so the customer gets their new content earlier while we finish the other parts of the site.

Integration with the Development Team

The implementation side of the design WIP board can also feature as a swim lane on the development team WIP board. This helps for cross-discipline pairing or the use of designers as a specialist in the development team but still gives visibility in the whole design team process.

We work with either 2 or 3 work cells in the development team, with each cell taking a swim lane on the WIP board. Depending on the task in hand we can easily have one work cell working on a design/development swim lane to get a CSS layout produced, or implementing a javascript menu etc.

Conclusions

It really is too early to say if this is going to work or even be adhered to. The team is enthusiastic about the adoption of this process for design and it certainly adds coherence between all the teams at Codeweavers Ltd. At the moment we have no wall space for the design kanban board so we’re using http://www.kanbantool.com which means the visibility isn’t as high as it could be, but we are moving offices soon where the boards from all teams will be much closer together, physically and operationally.

Needless to say, I’ll be adding new posts with regard to our progress and to give a different perspective I’ll see if our designers and managers will also post here about their views on the new system. Keep an eye our our RSS or Twitter feed for updates.