How to do Agile Properly – Part 2: Design

Part 1 of this series

Designers naturally fight against the Agile process, and it is hard to blame them. The typical process defines that the designer provide little pieces of a design at a time. This doesn’t make sense – a design is a holistic piece of creativity in its own right. Imagine if you were asked to draw a house, but piece-by-piece. First, draw the chimney. Now a window box. Now a hill in the background. Now the front door. It would drive you crazy, and of course, whenever you sketched the next bit in, you would have to change the previous ones to keep the composition sensible.

In practise, trying to shoe-horn the designers into this process ends up (in places I have worked, at least) with the developers being halfway through implementing the design on the stories for the current iteration, and the designers being halfway through changing everything for the next one. I would catch a glimpse of the designer’s screen, and see that everything I had done so far was already out-of-date. This problem would progressively worsen with every iteration. It was disheartening, and inefficient.

This isn’t the designer’s fault. They are not used to the same restrictive processes that developers are, and they shouldn’t be. They need more room to be creative.

Colouring It In

Before any designs can be built, we need to have a good idea of what it is we are building. Brainstorming ideas and mad designs is all well and good – but this should certainly take place before any development begins. That said, whilst the stories are being written, it’s a great idea to be throwing together a few off-the-wall designs, to be treated as prototypes. This gives the designers a chance to work without restriction and really express themselves creatively. Some great ideas can come out of this process.

Once the stories are written, we can move on to wireframes. This is where our design starts to get some structure, and this what our developers will be able to initially start working with. There are lots of tools for creating wireframes – OmniGraffle, Visio, and so on. My tool of choice would definitely have to be Balsamiq Mockups.

It can be very easy to start treating a wireframe as a design. I’ve been in several meetings where it’s been suggested the font is too small, or the colours in the wireframes are wrong and so on. The point of a wireframe is to map out what elements we can expect to have in a design, relationships between pages, and their basic interation and positioning. The wonderful thing about Balsamiq Mockups is the result looks like a sketch. There is no way you could mistake it for a design, and this keeps conversations focussed on the important points. Here is an example I made in less than two minutes!

Balsamiq Mockups

Balsamiq Mockups is available as a standalone app, or as plug-ins to Jira and Confluence (my management tools of choice). It stores data in XML format, and the web-enabled versions of the software have very little disadvantages over the desktop app. I recently chatted with Giacomo ‘Peldi’ Guilizzoni (the company’s founder) over Skype, and he was a lovely and helpful guy. The desktop version is only $79 per user. The plug-ins include licenses for up to 3 desktop versions, and you can get a refund of the difference if you bought the desktop version first!

We’re Good To Go

So, now we have our stories, and our wireframes. It is at this point development would begin. We will concentrate on the design track first. Since we have valid wireframes, and we know what elements to expect on our page, our developers can get on with functionality, and good, clean POSH. The design does not have to exist at this point. I have found, at Silver Squid that developing without design first let’s the developer get the cleanest code, and the designer work without restriction.

Our first story might be:

As a Designer I want to create a base design so that I have a template to build further designs upon

For this the designer should get an idea of the design language of the site, the colour schemes, the typography, and so on. Of course, this is Agile and as such it can all change, but having somewhere to start is A Good Thing. It should be based upon the prototypes they built in the planning stage, which were hopefully well received!

Following that, stories could be something like:

As a Developer I want a design for navigation to exist so that I can apply it to the HTML to make the site more attractive

This means that the designer focusses on the navigation. The wireframes should have included basic expected behaviour – whether the navigation is dropdown, or static, etc. The acceptance criteria will list the expected states of the navigation, to ensure all scenarios are covered. For example:

  • Navigation Item
  • Active Navigation Item
  • Hovered Navigation Item
  • Navigation Item with Subnavigation (contracted)
  • Navigation Item with Subnavigation (expanded)
  • Subnavigation Item
  • Active Subnavigation Item
  • Hovered Subnavigation Item

There are a lot of potential states in a even slightly complex web app. Making sure these are all covered in the acceptance criteria leaves little room for error later. We should also allow in each story for amendments to the rest of the design to keep everything feeling coherent.

Don’t Forget Interaction & Animation

The latest and greatest web apps have sliding menus, fading modal dialogue boxes, pulsing buttons etc. Any dynamic movement like this will not come through in your static Photoshop files. It is important that these are decided by a qualified designer or UX guy, and that he works with the front-end developers to ensure it works as he expects it to. As much as possible should be noted along-side marked up designs. Often these touches get forgotten and the front-enders make it up themselves, which can be a huge mess of sliding, throbbing, fading, scaling madness.

As I’ve said before, these are practises that work for me! Everyone is different. How do you implement design in your Agile process?

In part 3, we will start breaking down the development process into its component parts, and show how the team works together to get things done.

5 thoughts on “How to do Agile Properly – Part 2: Design

  1. Having experience with UI design and dev teams, your comments and scope on the approach to development is sound advice. I look forward to PT3. Interesting approach Balszmiq uses for conceptual structure. Though I don’t think I could get used to that relaxed look. I think many of my clients would be turned off by that too. I guess it all depends on your brand and approach to client communications.

    Though the importance of a pre-developed structure is a must. I am very fond of the results of Omnigraffle. I do use Adobe Illustrator from time to time to do many sitemap layouts and page comps as well.

  2. @neven
    I feel that the results of OmniGraffle are too polished. If a base design is provided alongside your wireframes the contrast between these can be made clear, and the design and the wireframes (and/or sitemap) can be critiqued in the most useful and constructive manner.

    Of course, YMMV :) This methodology works great for me.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>