Integrating Agile and Design: Step 1

Designer at work

One of my passions is the integration of Agile and design. Over the last 5 years I have worked with my teams to continually change and innovate with the goal of making design a first-class citizen in an Agile team. There are 6 key steps that we have taken:

  1. Designers write HTML/CSS.
  2. Designers share code ownership.
  3. Designers pair with others.
  4. Design is part of each story (where appropriate).
  5. Design doesn't work ahead of development.
  6. UX design and graphic design are treated as seperate but related concerns.

Today we are going to talk about the first: Designers writing HTML/CSS.

Why should designers write HTML/CSS?

In short, because they are awesome at it! I have had the pleasure of working with fantastic designers in the last 20 years. I can say without exception that the best were not only great visual designers but also executed their designs in clean, well structured HTML/CSS.

On the surface, it may not appear a natural fit: the creative freedom of design and the unforgiving, exact nature of HTML/CSS. When we take a more careful look at design, however, we can see that along side ideation and experimentation there is a technical element that needs to be mastered. This is true no matter what the medium of expression is for the designer: print, screen or physical objects.

Designers come to writing HTML/CSS in their own time. Some are driven to do this from the first time they start designing for the web, others come much later. But what drives them is often the same. They want to see their designs implemented as they envisioned them, they want to push the boundries of the medium, and they value elegance.

The gap - design to implementation

When developers are being handed designs and implementing them in HTML/CSS there is often a visual difference. Depending on the situtation these can range from small acceptable trade-offs to massive mis-implementations of the design. In one case I worked with a developer who couldn't see the differences between serif and sans-serif fonts. This leads to dissatisfaction on the part of the designer. They have laboured long and hard on their designs and want to see them faithfully reproduced. This can be one of the drivers that pushes designers to learn HTML/CSS - seeing their designs faithfully implemented.

It's not until you understand the rules that you can successfully break them. When there is a seperation between the design and the implementation, designers are often frustrated by the limitations.

This can lead to a number of adverse situations. Designers can create designs that while not impossible to implement, could with some small change be simpler and more effective. With this siloed approach, an adverserial relationship develops between design and implementation. Designers hand their work off to the developer. The developer implements it to the best of their ability. The designer takes a QA role, reviewing the implentation and sees the implentation wasn't correct. They send it back to the developer who can't understand why the change is necessary.

I think this happens because design files are, in essence, a form of specification. There is a tremendous amount of information in them and it is difficult to be aware of it all. The specification becomes a contract between the designer and developer and in the worst of cases the process devolves into a negotiation of that contract.

Take this imaginary exchange (no basis in reality :-) between a designer and a developer:

Designer: The design clearly shows a 2.5em space above lists that follow a paragraph and a 2em space when following a level 3 heading.

Developer: It's two hard to do that, I don't think it's even possible, you can't see the difference any way so it doesn't really matter.

Designer: It's important, the whole page is designed on a baseline grid, and if we can't do this it will throw off the vertical rythym. I saw it on other sites, why can't we do it?

Developer: Well, send me the site and I'll have a look. But I don't really have time for these small changes. Can't we just leave it?

These conversations happen a dozen times and the design dies the death of a thousand cuts. To the developer, the time and effort involved to achieve the baseline grid doesn't seem worthwhile. To the designer, it is an intregral part of the design and without it the integrity of the whole design is undermined.

Neither the designer or developer are wrong; it's the wrong structure. The environment is forcing them into conflict.

What does it look like in the team?

On our projects the designers are sitting side by side with the developers and the rest of the team. They are talking about and working on the same stories. They are checking files in and out of the source code repository. Sometimes they are paired with developers, sometimes they are on their own.

Designers thrive on the challenges that come from implementing their designs. Rather than winding up in conflict with developers, they are happy to make the necessary trade-offs themselves rather than have those trade-offs forced on them.

What are the benefits of designers writing their own HTML/CSS?

  • Higher quality code
  • Finding new design opportunities
  • Better flow in the work
  • Better experience for users
  • Higher productivity
  • Easier to maintain and work with

How do developers learn HTML/CSS

Unfortunately many design schools do not understand the benefit of teaching HTML/CSS as an intregal part of web design. Graduates have either taught themselves or have not HTML/CSS abilities at all. Even after 20 years we find that the fastest most efficient way to create HTML/CSS is by hand with a good text editor. For designers who have relied on others to implement their designs or used applications that produce markup for them, learning HTML/CSS can be a daunting proposition.

We use Treehouse to support our designers in learning HTML/CSS. Designers have enjoyed using Treehouse and have developed fantastic skills quickly.

My experience is that once designers have the fundamentals of HTML/CSS under their belt, they start on a journey that sees them continuing to evolve and develop their skills and techniques. They never stop striving to improve the elegance and structure of the HTML/CSS. They use their new found skills to push the boundries of web design.

Unfortunately Treehouse's customer support is extremely poor and surly - you've been warned :-)