Latest Articles

Alexander McCall-Smith Engages Web 2.0

The Daily Telegraph is in the middle of a 20-week serialisation of an online book created by author Alexander McCall-Smith, his first such project. New Media Knowledge caught up with the organisers to discuss ‘Corduroy Mansions’.

more

Business Brief: Video Advertising Looks to Future

Google has announced it will incentivise advertisers on its video properties as well as launching research programmes into how Web users consume Internet video material. New Media Knowledge spoke to a number of industry players to gauge their views on where the video advertising market is going.

more

‘Virtual Home’ for Ex-Pats in London Established

A social network aimed at providing information for ex-pats living in London has been established. New Media Knowledge met the site’s co-founder to find out more.

more

• Rough Guide to: Social Media and the Law
• Record Visits for UK Blog Sites
• Clearing Congestion
• Rough Guide to: Pay-Per-Click Advertising
• Opinion: What Happens to Newspapers?
• LinkedIn Adds Business Applications
• What Happens to Newspapers?

Related Articles

• User Centred Design - Course

  In order to make sure your site meets your audience’s needs, you need to start by understanding your audience.  This one day course demonstrates a variety of industry-standard tools and techniques that allow you to gain insight into your audience, what they are looking for online, and how to give it to them. more

Beers & Innovation: Developers and Designers

Our Beers and Innovation event on Tuesday 12 February covered the changing roles of developers and designers with the advent of Agile programming methods and user-centred design. Ian Delaney reports.

The Panel

Laura Francis (Chair) - Semantico

Martina Schell - Flow

Mark Stringer - Agile Lab

Chris Heilmann - Yahoo!

 

Martina Schell began by explaining some of the basic terms in a short presentation. The job of the designer has evolved well beyond what the layperson might imagine. It’s not just about drawing pretty pictures, but extends upwards and might include consideration of:

• - how information is communicated to users and at what point;
• - the interaction between users and the site;
• - the structural relationship between product components and features;
• - how the product or service will deliver value to its users and what that value might be.

So what is called ‘the design process’ no longer occurs at the end of a project, giving a pretty interface to a fully-developed product, but rather is likely to involve at least five stages:

1. Research: Learning about the people who use or are going to use your product, and the context in which they’ll use it. It can include ethnographic techniques such as shadowing, diary studies and interviews, as well as focus groups, benchmarking and online tracking (for web projects).

2. Concept: Examining the needs of your users and of your business, and coming up with innovative solutions to address those needs. During this stage, the visual design team work on concepts for brand interpretation. The visual and interaction ideas come together for concept testing sessions with target users.

3. Iterative design: Designing and usability-testing mock-ups of your product through a series of repeated cycles. There’s interaction design, information architecture, visual design and content to be worked through in detail. The result of each cycle feeds into and refines the next, ensuring that the final user experience is simple and delightful.

4. Implementation: The development team often needs quick interaction solutions when they encounter unexpected technical constraints. There’s also accessibility checks and testing to perform, and a final usability test of the working product.

5. Launch: The roll-out is managed to ensure users experience a smooth transition from any legacy product. Once the product is out, it’s important to gather feedback and metrics. This can include further usability testing and ethnographic work, along with web analytics.

At the same time, the way in which developers work has also changed, following the embrace of Agile programming methods. Previously, Schell noted, development started with a strict specification from a client. The developers went away and made it, normally after a fairly lengthy period of time. Then the project go passed on to the next team, probably the designers. This is known as the waterfall approach.

Agile techniques change the focus - the aim is to create working code as quickly as possible and to work in collaboration with clients, users, designers and other stakeholders. The first versions of the code are unlikely to be 100% satisfactory, but it enables those stakeholders to understand more about what they want from the product, site or service and for subsequent versions to get better faster. Agile developers acknowledge that they don’t really know what the product will look like or how it will function twelve months from now.

Why are these approaches better for clients and users? asked event chair Laura Francis.

The answer lies in the nature of the risks involved in product development. User-centred design puts great emphasis on research and planning; both approaches take the developing product back to users and clients at several stages of the process. Agile, in particular, aims to minimise the risk of failed projects by allowing their course to change dynamically in response to user testing, changing circumstances and clients’ needs. This is in contrast to a project managed using the waterfall approach, which would continue onwards to its prescribed goal and often fail because the initial assumptions and list of requirements was either insufficient or incorrect. Many large corporate projects have failed in this way.

Panelist Leisa Reichelt suggested that the UCD approach is about "show rather than tell". It’s about putting the user at the centre of the development experience rather than simply making guesses about what they might want. It thus takes the risk out of innovation. Mark Stringer concurred: "Clients generally don’t know what they want, even if they think they do. Agile gives us an opportunity to ask them again and again."

For practitioners, one advantage is that Agile methods are a lot more fun. Because of the necessity for collaboration and conversation, people from different disciplines aren’t locked away diligently working on the same task for weeks on end, alone. This may seem like a frivolous point, but Reichelt contends that it means those involved in such projects retain high levels of energy and enthusiasm for their work. It was also pointed out that, for clients, a big benefit of Agile is the possibility of having a revenue-earning site or service much more quickly than waterfall projects.

Panelist Chris Heilmann, speaking from the perspective of an internal developer at Yahoo!, joked that the main difference that Agile had made to his work is that he could now go past the kill date with impunity. More seriously, he suggested that Agile - especially through face-to-face stand-up sessions across teams - had helped teams properly collaborate. Using this technique, it makes it possible to understand what is stopping other people working in other disciplines from performing at their top level, and doing something to alleviate that, as opposed to the culture of blame and delays that could otherwise prevail.

Agile might not be suitable for everyone, Reichelt conceded. It will work badly if it is suddenly imposed from above. People used to a method that promises to deliver X by Y might find the apparent freedoms and looseness of the approach difficult to adapt to. Stringer felt that agencies don’t necessarily have to go the whole mile with Agile. Taking a few of the most positive elements might be enough. For example, a half-way house that simply allows clients to see and use working software earlier into the project than previously would be very beneficial on its own, making those clients feel better about the project as a whole.

The panel also raised the possibility that an agency does not have to be entirely ‘up-front’ about the way it works. However, both Heilmann and Stringer thought this was a mistake since explaining the technique meant that ‘difficult’ conversations about costs and timing are conducted early in the process. Heilmann recalled that at his first meeting with new clients as a freelance developer, he showed them three circles containing the words ‘fast’, ‘good’ and ‘cheap’ and asked the prospective client to pick two. Stringer explained that the difficulty in finding acceptance among clients for Agile methods is because we compare building anything to an engineering model: building a website is seen as analogous to building a bridge. Thus websites are thought to go through various processes in a factory-style chain. This is a false analogy, he contended: software development is actually about problem-solving in an uncertain environment rather than industrial style production. Late decisions, improvisation, backtracking and changing direction ought to be viewed as valuable elements rather than mistakes or impediments to progress.

In the last segment of the session, talk moved to the sort of people that are best adapted to this new development environment. People with no appreciation whatsoever of what other disciplines than their own entail are least likely to thrive. People need to be multi-skilled and multi-talented. But the panel was keen to establish that this doesn’t mean a team composed of Jacks and Jills of all trades - generalists with no specific skills. Look for ‘T-shaped’ people, Reichelt suggested: people with an in-depth knowledge of their own discipline, but also an understanding, basic skillset and appreciation of a number of other disciplines.