Wednesday, August 17, 2011

My free ride on a Heathrow Terminal 5 ULTRa Pod

I've been following PRT and the ULTRA project at Heathrow in particular since 2005, so I've been getting rather excited by the prospect of trying it out.

Eventually I got tired of waiting for an opportunity to use the Terminal 5 business car park where the first loop seems to be in a Google-like extended beta, so I just took a bus from work to Heathrow, followed signs to the business car park via level two of the short term car park, and there it was.

(If the image above is at right-angles to reality, use my Google+ version instead)

(Sorry the video is totally un-edited - I'll update it to something shorter and snappier once I've got on top of the necessary file conversion and editing tool stack)

There's a lot to like about this form of transport:

  • The pods wait for you, not vice-versa
  • They're comfortable - there's no need to stand because you were the last aboard
  • They take you straight to your stop without stopping at anyone else's stops
  • They take you closer to your destination than a tram or rail line, and aren't scared of a little gradient either
  • They're more wheelchair friendly than the bus (though wheelchair users - and suitcase stackers - might benefit from a warning of any gradients)
  • Reduced greenhouse effects and zero local air pollution

Were there any negatives?

  • The ride was a little bumpier and noisier than I expected, but totally tolerable
  • The Door Open and Door Close buttons are familiar from lifts (elevators) and commuter trains, but in neither context is there a separate Start button - I don't mind it, but I really can't see its purpose
  • I'm pleased to see that you can go from any one of the three stops to any other one, but I'm really looking forward to seeing the scalability I mentioned in my 2005 post, and we won't see that until you have multiple linked circuits

So overall, the experience was everything I'd hoped for. Sadly we won't see it at the London Olympics, but I look forward to seeing it rolled out to airports, campuses and town centres all over the world.

Wednesday, August 03, 2011

Reflecting on Central St. Martin's Service Design Short Course - day 2

This morning Vincenzo asked if there were any product designers on the course - I'm not one, but as I mentioned in my introductory video, always wanted to be an inventor, so stood by with interest and was invited to knock up a door wedge to keep the doors open, which I did with creativity and enthusiasm. But when I finished my wedge made from coffee-cup holders, not only was it too big to fit, but as Allan pointed out, both the doors already had handy wall-hooks to hold them open.

Moral of the story? Use research to refine the brief...

Thinking of briefs, I'm on the green team, with a client brief from Camden Council's cycle training scheme. We were asked to review a selection of design methods, and come up with a plan for researching and creating a design over the remainder of our two weeks. We came up with something based on the Design Council's double-diamond approach:

I really want to deliver something good, and I'm itching to narrow the aims of the project down to something that will be do-able but still impressive. But I have to remember that we're still in the opening, divergent, phase of the first diamond, and where I want to be is the end of the second, convergent, phase. I have to hold myself back from jumping the gun.

In other words, I have to trust the process, Francis. Use research to refine the brief...

Thursday, July 21, 2011

Don Norman's Living with Complexity - notes for #uxbcldn

I'm reading Don Norman's Living with Complexity for a UX Book Club London meetup, but I am also trying to prepare for the Service Design short course at Central St Martins that I will be taking next month, so I'm going to focus on his comments on Service Design - especially since this is the first Don Norman book I've read where he discusses this topic.

In many ways the book is something old, something new. The old bit - and none the less true for it - is his job description for designers:
The designer's job is to provide people with appropriate mental models.
[ch 2, p29]
The official new element is the complexity of the title, and his view that many devices and services involve an irreducible complexity which cannot be magicked away, as he expresses in a quote:
Every application has an inherent amount of irreducible complexity. The only question is who will have to deal with it, the user or the developer (programmer or engineer). (Tesler and Saffer 2007)
[ch 2, p46]

Chapter 6, Systems and Services, and chapter 7, Waits, are the most directly relevant to service design. He discusses the relative immaturity of Service Design compare to Product Design in characteristically IxD terms:

The world of services is different from that of products, in part because they have not been studied as much as products. Although one would think that service providers should also adhere to the standard themes of good interaction design, that is, good feedback along with coherent conceptual models, in practice it is not that simple. Services are often complex systems, barely understood even by the service provider, with multiple components spread across many geographical locations and divisions of the company.
[ch 6, p144]
Don Norman has respect for the challenge: services are described in terms of complexity, back-stage and front-stage, recursiveness (a customer's back-stage may be a clerk's front-stage) and the systems thinking required.

Amongst other case studies, he describes IDEO's re-design of Amtrak's Acela Express: how IDEO declined an RFP for redesigning train interiors in favour of redesigning the entire service, starting with "learning about routes, timetables, costs" through 10 stages to "Continuing the journey" (how true - I would use UK long distance train services far more if I could hire a car at my destination as simply as I can at an airport), and Apple's iPod and iTunes, both illustrating roads to commercial success that involve thinking of the offering as a system and its delivery as an extended service.

I found an equally coherent but somewhat contrasting perspective in Journey to the Interface, a pamphlet published back in 2006 by Demos and Engine Service Design.

They take a more humanist approach:
Service designers do not see service as something that can be reduced to a commodity. They focus on how people actually experience services, in order to understand how large service organisations can create better relationships with their users and customers.

Experiences and relationships are the recurring themes of this pamphlet.
This model is not necessarily incompatible with the Don's - early on we get a little BUPA case study, which ends:
A tangible change that has emerged from doing this exercise regularly is that customers calling to discuss their hospital visit are now offered a checklist of things that other people in similar situations have asked. This was introduced after BUPA realised that people often didn’t know what to ask when the call finished with the question ‘is there anything else I can help you with?’ Alison, again: "You have to do as much as possible to manage getting into people’s shoes – psychologically, emotionally, physically"
Although the terminology is different, this example fits right in Don Norman's emphasis on ensuring that the user develops a mental model which includes understanding the most relevant future options.

Two things that distinguish the Demos / Engine Service Design approach from Don Norman's are,
[1] the emphasis on relationships, eg
The picture of service is no less complex from the interface as it is from a systemic perspective. What is different, however, is that the interface focuses on how people and services relate, not simply the shape of existing services.
and [2], the emphasis on co-production, eg:
Service designers focus on a specific kind of engagement:
engagement at the interface. Deliberation has to take place at the point of delivery to create the kind of engagement required for co-production – that where people are mobilised, coached, and
encouraged to participate in the ‘common enterprise’ of generating positive outcomes.
A point shared by both publications is the difficulty of measuring (and thus funding) the value of services which are designed to provide long-term or preventative outcomes - I would like to have seen some discussion of Social Impact Bonds here, as one apparently appropriate mechanism.

All in all, I'd say Don Norman's book is an excellent overview of various design issues from an Interaction Design perspective. There was a common feeling at the UX Book Club London meeting I was at (IG Index - thanks Jane and Chris!) that it would be most appropriate to an interested non-designer, and in fact the Service Design chapter was found by many to be the most interesting, perhaps because we weren't, in the main, Service Designers.

On Service Design specifically, I found it a helpful snapshot, if conservative in vision. The greater ambitions of Journey to the Interface are somewhat focussed on a specific British context, but I find it entirely plausible that changing the relationship between service users and service providers could have more radical effects than changing the relationship between consumers and their products or programs, especially when achieved by techniques like co-production.

Saturday, July 02, 2011

The uses of magic

Being a dad can be frustrating sometimes. Johnny now watches CITV more than the BBC children's channels, and I've been getting polite but continuous requests for the much advertised Bey Blades. And he brings back reading books as homework from school every day - plus two for the weekend - and that's been turning into a mutually dreaded ordeal.

So I was thinking I needed to take a step back and come up with a better way. So I drew a pentagram on a scrap of paper, numbering arms from one to five, and inscribing the initials "BB" in the middle. I then explained to Johnny that each time he read his homework book without flopping or wailing he'd get a sticker on one arm of the star, and when he'd got one on all five arms, we would go out and buy a Bey Blade. He was horrified by this quandary and resourcefully suggested several alternative ways he could earn the stars, which I politely declined.

I would just like to record that by the time we got to the fourth and fifth homework sessions he was snatching the book out of my hands, refusing to let me read it through first, and confidently and proudly reading it aloud. (And today will be shopping day)

Am I proud of stooping to bribery and succumbing to commercial advertising? Not really, but I don't care about that. Johnny's education, and our relationship, are more important, and I'm pleased I worked that out. Could I have come up with a smarter solution? Well, yes, I'm sure and any suggestions gratefully received. Meanwhile, I will gratefully continue to learn whatever it is those who teach learn from those they teach.

Thursday, June 23, 2011

#AgileUX Agile Safari to

AgileUX Agile Safari to MindCandy

Yesterday MindCandy were kind enough to host the Agile UX Meetup group for an Agile Safari where they showed us round their offices and discussed how they have combined User Experience Design with Agile development as part of their current success story.

MindCandy’s original hit product was PerplexCity, but they are now best known for MoshiMonsters, a games, virtual pets and social site for children aged 7-12 which has been described by some as the Facebook of kids, especially now that it has 50 million users worldwide. The product is directly funded by subscriptions, which not only provides a solid business model but gives immediate feedback on the success of new features.

What MindCandy gets from Agile

The story goes that before MoshiMonsters, MindCandy raised $10m, burned down $9m of this on waterfall-style development for PerplexCity, then, 2 months into their final 6 month plan, decided something had to change and introduced agile to make MoshiMonsters. From their perspective, the rest is history, and agile is seen as a core component of the company’s culture, from the top down.
MindCandy's Christmas Party, 2010, with the Big Board in the background

As MindCandy's main product is aimed at kids, and already has high penetration in many markets, they need to keep it fresh by adding features in order to [a] avoid letting their users get bored, and [b] avoid leaving a window of opportunity for their competitors.

How Agile works at MindCandy

A product board meets regularly and signs off projects, basically at a one-line level of abstraction eg “Add MiniGame Fun Park”.

Each project gets a team, some of whose members will be “ring-fenced” for that project (presumably others are shared as needed). The team works with a full-time scrum master (so developers can get on with development), and have their own four-column (Not Started / In Progress / In Test / Completed) section of the big board. There are some kanban-like features too, each team member can only put his name on two tasks. Teams deliver user stories in two-week cycles, the product manager (Dharmesh, in agile terms, the product owner) will focus on delivering something for each user story. Features are may be delivered as several user stories over several sprints.

MindCandy staff see themselves as being triumphantly team-focused in working practices and reporting structures. Co-location is seen as important and all UK staff currently sit together on one floor of Tea House in Shoreditch - they hope to keep the vibe as they expand to another floor.

They don’t do the “we will commit to two the following two weeks worth of work” thing, preferring to simply prioritise whatever’s still on the Not Started list. Likewise they don’t see themselves as deadline driven, though external deadlines such as school holidays are naturally part of the landscape and will help focus as decision time nears - “to ship is to choose”.

How UX works at MindCandy

Yael is the User Experience designer and works with Axel, the visual designer. They sit side-by-side in the middle of the development area. UX work is done within 2-week sprints as part of user stories. User stories are often implemented in two passes, the first (the first week of the sprint) concentrating raw functionality, the second (the second week) allowing for the UI to be optimised.

MindCandy don’t go in for big up-front research, nor do they currently use personas. They do have a good understanding of their target market from long  exposure to it, and from community managers.

Challenges overcome

MindCandy also work with an off-shore team who are fully agile and work on non-game focussed projects to allow the internal teams to work on the core games. MindCandy do company-wide sprint reviews (with team-level kick-off, stand-up and retrospectives), and the off-shore team takes part in these.

Off-shore teams are not part of the big-board but they use Acunote as a light-weight Scrum tool which allows them to do Scrum their way.

They do a lot of Skype - messaging even more than calling - and most desks (apart from marketing) just don’t have phones.

Looking forward

Their current agile and UX processes have clearly served them well so far. As their market gets more mature, MindCandy feel the need to get even more agile, both developing faster and learning faster.

They plan to introduce UX personas in order to target variations in their age 6-14 user base better, and hope to fit more regular user testing into the time and space available.

They now have a full-time business intelligence analyst to identify areas of concern which might otherwise be masked by their overall success, and are extending their use of analytics.

On the productivity front they have a full-time tools and environment expert who describes himself a the “force multiplier”, and who looks for areas of friction which he can automate and / or accelerate.


I’d really like to thanks Martyn, Raph, Axel, Yael and Dharmesh of MindCandy for a fascinating and exciting Agile Safari, and of course Johanna Kollman and Agile UX for organising it.