Taking inspiration from Gov.uk

I know there are more websites out there than Gov.uk, but I somehow feel the need to keep returning to it. It makes the news quite often for positive reasons, which is incredible for a government digital project.

Fail fast, move on – making government digital

Here, the BBC’s Rory Cellan-Jones profiles the Government Digital Service:

The boss of the Government Digital Service was previously the digital director at the Guardian and has had a long career in the technology sector. He contrasts the approach his team is taking with the standard government IT procurement process, where a massive contract is handed to an outside supplier, inevitably a huge company.

“You then end up three years later with something that might be fit for what you were doing five years ago.” Compare this with the GDS approach: “Do it quick, fail fast, learn your lessons and continue to change – that’s why you need the skills inside the organisation.” And with a philosophy of open standards, there is much more flexibility to work with other, smaller suppliers as the project moves on.

FAQs: why we don’t have them

Although FAQs sometimes have their place, I often advise against them because they are usually not user-centred in design. The GDS agrees:

FAQs are convenient for writers – they put everything in a long list; it’s all neatly organised and the ‘Q’ does a lot of work for you. But they’re more work for readers – questions take longer to scan and understand than simple headings and you can’t take any meaning from them in a quick glance.

Also see the comments for an interesting discussion on FAQs.

A Gov supreme

Jeremy Keith uses Gov.uk as an example of a well-implemented responsive design, which adapts according to the device. This article also talks about how the advent of responsive design necessitates improvements in the way we work.

I’ve been doing some workshopping and consultancy at a few different companies recently, mostly about responsive design. I can’t help but feel a little bad about it because, while I think they’re expecting to get a day of CSS, HTML, and JavaScript, what they actually get is the uncomfortable truth that responsive design changes everything …changes that start long before the front-end development phase.

Redesign projects

The theme of this week’s links is redesign projects.

Redesigns are painful. Users find it unsettling when a familiar website radically changes its design, even if the new design is a great improvement. But organisations insist on periodical redesigns. A website is launched to much fanfare, but often the organisation then loses interest, leaving the website to crumble. Technologies and design trends change, and soon enough the website needs to be redesigned again.

Most web designers advocate an iterative approach, where the design is slowly tweaked over time, rather than undertaking wholesale redesigns every few years.

It’s time to do away with a project focused view of the web

Here, Paul Boag argues that it’s time encourage organisations to move away from the project approach.

One of the reasons organisational websites fester and decay is because companies are good at projects and poor at iteration… There is no excuse for only periodically redesigning your site. Why limit your website’s optimal performance to immediately after a periodic redesign, when it could be running at peak performance the entire time?

Design is the easy part…

Another interesting article about the issues surrounding designing for an organisation.

Politics and egos are the main reasons that great design goes awry – either it is never presented (because presenting it is a risk to those egos and would be not wise politically), or it is presented and dismissed, or it is presented and then changed such that egos are not wounded and the politics are in tact, the design integrity is hardly a passing consideration.

Managing your redesign

Moving on all fronts at the same time can overwhelm finite resources, giving rise to a project that’s a mile wide and an inch deep. Unable to get the full attention they deserve, equally worthwhile objectives end up competing for priority. Inevitably, someone loses. Avoid the ‘big bang’ effect.

Trello at St Andrews

At the meeting of the Scottish Web Folk, on Thursday 31 May held at the University of Edinburgh, I gave the above presentation about Trello from Fog Creek Software.

Trello is, according to its own help text,

a collaboration tool that organizes your projects into boards. In one glance, Trello tells you what’s being worked on, who’s working on what, and where something is in a process.

We’ve been using it since December 2011 within the web team at the University of St Andrews and are finding it really useful.

Summary of presentation

The first part of the presentation outlines something of our journey from a team of two members to (hopefully) six by the end of 2012. As our project backlog grew we knew that we needed to manage projects and tasks more collaboratively, to get details out of people’s heads and into a centralised tool.

We started to adopt Agile practices in 2008 which led to us creating a scrum board in the office. But in September 2012 Steve, our Web Manager, broke his foot and when he returned to working from home in December we knew that we needed to move the board online.

We had checked out a number of online, free and hosted applications such as Basecamp, Pivotal Tracker and Jira. However, Trello proved to be for us the perfect match.

The second part of the presentation takes a quick tour through the Trello interface and how it works.

The last part of the presentation involved a hands-on demo of the software. I’ve replaced this with two simple slides representing the two ways that we use Trello.

  1. We have one board called “Web team” which tracks the big picture: project requests, current projects being worked on, know issues, admin tasks, backlog of tasks, etc.
  2. Then we have multiple project boards, one for each project. These have a standard number of columns (backlog, in progress, waiting for, testing, done) and the labels (new feature, enhancement, PHP/JavaScript, bug, documentation, web team admin) are the same across every project.

If you have any questions or observations please leave a comment below or email me directly (gareth.saunders@st-andrews.ac.uk).

Note: this article was also posted to the Scottish Web Folk blog.

Two useful resources when planning Web projects

Web ReDesign 2.0

20110823-webredesign20

A few years ago I came across this really excellent book by Kelly Goto and Emily Cotler: Web ReDesign 2.0: Workflow that Works (New Riders, 2005).

In 10 chapters Kelly and Emily lead you through the workflow of a complete website redesign. They break the process down into five phases:

  1. Define the project.
  2. Develop site structure.
  3. Design visual interface.
  4. Build and integrate.
  5. Launch and beyond.

I’ve increasingly found this framework to be really useful, not only for website redesigns but for developing new sites too. I now think in terms of five phases for most Web-related projects that I work on. I’ve found it also provides a very simple overview for clients to help them understand where we are in the overall project lifecycle.

I now have the book sitting on my desk at all times, within easy reach. Their website also has a number of downloadable resources such as a client survey, tech check list, budget tracker, etc.

Web Design Sketchbook

20110823-webdesignsketchbook

Another resource that I’m finding really useful particularly during phase 1 (define the project) is the Web Design Sketchbook from 37 Media.

The first nine pages contain questions to ask the client, which I’ve found really help you understand the project better. Questions such as:

  • What objectives are you trying to achieve with this site design / redesign?
  • What is the primary “action” the site visitor should take when coming to your site (e.g. make a purchase, become a member, search for information)?
  • If you could communicate only one message to visitors, what would it be?
  • What should users think or feel when they look at the design of you site?

The final page of questions includes a list of word pairs to help you determine the tone of the site, e.g.

  • conservative or progressive
  • cold or warm
  • spontaneous or orderly
  • trendy or classic

The second half of the book contains what they call “layout brainstorming pages with full browser chrome and grids to better plan how your site will look and operate when it’s finished”. A nifty idea.

You can order the sketchbook in two varieties (single project at US $12 or a full 104 page sketchbook for US $25) or you can download and print out the free version, which is released under a Creative Commons license.

Build your own

These resources have inspired us to build our own, drawing on resources from each as well as our own experience and requirements here at St Andrews. When we have I’ll post a link to it here.

What would you include in a Web project workbook?

Our journey into Agile, pt.1

Scrum sprint

Diagram of a Scrum sprint, taken from Scrum in five minutes from Softhouse

In November of last year (2009 if you don’t have a calendar to hand) we started to seriously look into using Agile methodologies to better manage and run our Web projects.
The crunch came when we realised that in many cases we weren’t delivering what we had promised to do, we were snowed under.  We took a day out to evaluate where we were and to our horror we discovered that we

  1. were working on over 20 projects concurrently.
  2. were not moving very quickly on any of them.
  3. had a backlog of over 120 projects, which we estimated would take around 13 years to complete if things continued as they had been going.

Something had to change.  We had to change.  We needed to stop saying yes to everyone about everything and we needed to find a way to more efficiently and effectively plan and manage our projects.

Agile

That’s when we turned to Agile for assistance.

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams

Definition of Agile from Wikipedia

Agile is something that we’d looked into a couple of times in the past. It struck a chord with us: iterative, incremental development was something that we did anyway.  We often practiced pair programming, we were using something akin to a Scrum task board, we had a daily stand-up meeting each morning, at times we would have ‘customers’ sit with us to iteratively work through a design.

Simply adopting certain methodologies doesn’t make you Agile though, but it was a good start. Iterative and incremental, if you like.

Almost Agile, even.

Oh, hang on …

Multiple projects

One of the things that we struggled with most was how to run multiple projects using Agile. Because everything we read talked about the importance of running only one project at a time.  Everyone that I spoke to from commerce or business about it stressed the importance of running only one project at a time, and everyone from higher education I spoke to stressed how impossible it was to run only one project a time.

Then I discovered this paper from Karl Scotland, formerly Development Team Leader at BBC Interactive: Agile planning with a multi-customer, multi-project, multi-discipline team (DOC, 225 KB) who gave me the confidence that it could work. In this conclusion he wrote:

The team is able to manage the various complexities of multiple customers, projects and disciplines by working in a way which allows them to treat the work as if there were only a single customer, project and discipline.  Thus they work on a single pool of stories which are shared by all the different customers, projects and disciplines.

So we could run more than project at a time, if we were careful.  We got planning.

Next week I’ll explain what we did next…