Designing in the open

The Scottish Enterprise service design team is committed to designing in the open

What does design in the open mean?

According to Brad Frost, designing in the open means

sharing your work and/or process publicly as you undertake a design project

It’s not about making your code open source (although it could include that). It’s about:

• Sharing bits of things as you build them
• Sharing versions of things as they eveolve and change
• Sharing techniques and resources
• Sharing our experiences and stories

For us, designing in the open means sharing all the documents and artefacts and prototypes an anything else we generate publicly by default.

Unless there is a good reason not to - for example, if it contains personal or potentially sensitive information - we make it as widely available as we can as soon as possible. Often, that means our work is available while we are still working on it.

Why design in the open?

Well, we’re a public body, so why shouldn’t the ouputs of our work be available to the people who fund it?

But the process brings many benefits:

• Faster (potentially instantaneous) feedback
• Feedback from a wider group
• Generating buy-in from the community and stakeholders
• Demonstrating our commitment (and work in progress)
• Communicating all day, every day
• Reduce the cost of communication within the team, even if some work remotely

But mostly, it’s just about being open, honest, and transparent. And we reduce our communication overhead because we don’t need to tell people about what we’ve done if it is right in front of them any time they want it.

Some history

Towards te end of 2008, both @numbat70 (Martin Kerr) and @david-obrien (writing) worked for Scottish Enterprise’s web team.

We were asked by our director (this was like our boss’s boss’s boss’s boss) if we could completely redesign, rewrite and rebuild scottish-enterprise.com by the 1st of April.

So, no pressure then. 3 months to completely tear down and rebuild a 5,000 page website.

But we did it. We had no time to contract anyone else to do it, so we did it ourselves.

We did a lot of things we would call agile now, though neither one of us was particularly aware of the term in 2008.

We put together a small, multi-disciplinary team. Mostly content writers; I did front end design and some development. @numbat70 did most of the back end dev.

We used Gerry McGovern’s top tasks methodology to identify user needs.

Most importantly, we all worked in the same small room. We talked, every day, about our work. We helped each other out. We didn’t wait for anyone else to catch up. We wrote and coded and designed and built together, but independently.

No dependencies.

In the end, we got there. We redesigned, rewrote, rebuilt and shipped on 1 April 2009. We got a 10,000 page site down to <500 pages by foucusing on user needs.

The results? Ambiguous. Analytics data was still mostly based on server logs in those days. Google Analytics was still a twinkle in my old mate Sergey’s eye.

Stakeholders hated it. And everyone complained about “their” content going missing (even though “their” content had not, so far as we could tell, been read by anyone in over 6 months.)

Then on Friday night we went to the Arches

That’s just for SEO.

In truth, we started to blog at http://digital.scotentblog.co.uk/. It’s a WordPress blog, dead simple, far away from our internal processes and controls. It just made things easier.

Important people (cf. boss’s boss’s boss’s boss) actually read it. Which, er, surprised us.

Astonished is probably a better word.

Which is all good, but wasn’t making a difference.

Then we moved to the junkyard

AKA our old Paisley office. A beautiful early 20th century building with lovely art deco tiling in the wally close and the shonkiest interior ever.

We had the first floor. Half of it was off limits because, well, there were holes and stuff. And if you opened a window it might fall out onto the street and decapitate a passing buddy.

But it was great. Apart from the trains.

We were properly agile.

We had small teams and no communications overhead.

We had proper, actual, for real kanban boards that we actually stood in front of and talked about our work. Every day. There was loads of wall-space, and plenty of whiteboards

It felt easy, and it felt natural. It felt good.

We plastered that place with post-its and ideas. Some of them came to fruition, most didn’t. Some of those that came to fruition worked, most didn’t.

We tried stuff, we discarded the stuff that wasn’t working, we improved the stuff that was.

And we got results.