Friday, 2 December 2011

The Open Road

It's now four weeks since we left the UK, and it's been every bit as brilliant as we'd hoped. It's been quite interesting comparing our trip to Ivanka's, which in turn is a bit like the trip we took in 2003-04. While those trips allow(ed) plenty of room for serendipity and adventure, ours is a bit more regimented. Such is life when travelling with small children, especially one with a few minor health issues - knowing well in advance where we'll be staying each night allows us to find things the kids'll like to do, and ensure they get a good night's sleep, making it a more fun and relaxing trip for everyone. And I'd like to think I've learned a lesson or two from The Griswald Family.

That said, we've still had some lovely surprises while we've been en route. Broadly speaking, our trip has had three legs (links are to maps, names for kids in brackets):
The highlight from the first leg was definitely New Orleans. The rest of the Deep South was lovely - the people were friendly and the food was *amazing*, especially in The Brick Pit - but New Orleans itself is something special. We love the music and the mood, so nicely epitomised in David Simon's Treme, and it's something that can't really be captured in photos. The closest we got was when we discovered and joined a Second Line en route from the French Quarter to Frenchmen Street. It was to celebrate a Jewish wedding - hopefully this snap will give you an idea of how vibrant and exciting this can be:

Second Line

The other highlight of Louisiana was the food. Oh my God, the food! We had plenty of good nosh in New Orleans, but the best meal of all was in a town called Breaux Bridge, a few hours West of New Orleans in Cajun Country. There, we discovered the delights of Crawfish Étouffée, which is making me drool just thinking about it...

Crawfish Etoufee

Add New Orleans to your bucket list now, if you haven't already!

As for the second leg, it was all about National Parks. We managed to hit six of these in the space of 11 days (Arches, Canyonlands, Capitol Reef, Bryce Canyon, Zion National Park, Grand Canyon), plus not-National-Parks Monument Valley and Antelope Canyon for good measure.

They were all incredible, but we were surprised to find that Grand Canyon was probably the least engaging of the six - once you've got over the initial wow factor of that view (and to fair, it is a blockbuster view), you find that it's very similar from all the viewpoints, as are the viewpoints from the trails along and inside the rim, and there are way more people there than at the other parks.


Definitely still worth a visit, though.

In contrast, the other parks have a huge amount of variety, both within each park and compared to each other. Zion Canyon is stunning, Bryce Canyon simply bizarre, Canyonlands epic and Arches novel. The National Park Service does a terrific job looking after these treasures, and the Junior Park Ranger programmes they run helped us look after ours. Here's a snap of Zion:

Zion Valley

And Mesa Arch in Canyonlands was another highlight:

Mesa Arch

Anyway, where was I? I was talking about surprises, wasn't I? Well, Route 66 (at least, the 100 mile section we rode on) served up an interesting treat or two. A few stops along the way were littered with Americana (and I'm a fan of Americana), but what made it special was listening to KZKE en route - brilliant!

And now here we are in Hawaii. I knew it was famous for Turtles, but I honestly didn't expect them to pose for me...!


And as for the sunsets...

Anyway, the end of our trip is in sight (arriving in Sydney on 10th December), so our thoughts are turning to the long list of administration awaiting our arrival - not least of which is finding a job. And go on a diet. Maybe after Christmas?

I'm glad to say we've found somewhere to live in Sydney for the first six months (in Cammeray), but we don't move in there until 19th December - we'll bridge the gap in a campervan, first staying at a campsite in the city, and then in one an hour North of the city. It'll be nice to finally empty our bags...! :-)

In the meantime, a full set of photos and few little videos can be found in this Flickr collection.

Thursday, 6 October 2011

A lasting legacy

A few days ago, there was an interesting article in The American comparing Steve Jobs to Thomas Edison. The gist is that Jobs' legacy doesn't measure up to Edison's - mainly because people are generally unaware of how much Edison achieved in his lifetime (it was a lot).

Putting to one side the fact we're not comparing apples with apples, if you'll pardon the pun, I think we're still a long way from realising the extent of Jobs' impact. You can see it far, far beyond Apple's product line. By setting the bar so high, he's forced the entire technology market to change the way they design their products over the past 10 years. I see Jobs' legacy in every phone, every computer, every tablet - anything technological which has an interface. Products formally seen as 'good' are now mercilessly mocked, and don't last long.

Our expectations have gone up. Through the roof.

But the true legacy reaches much further than the technology market. It can be seen in the way we design everything - from physical products, to services, to transport systems, to web sites. We want everything to work better, no exceptions, no excuses.

Of course there have always been companies with a strong customer service record. But given how technology in general, and the web in particular, weaves its way through every aspect of our lives, having such a fantastic cheerleader in the technology world for putting the user experience first - and actually showing how it should be done - has benefitted everyone and everything.

Our ambition for every project, both here at The Team and at previous employers too, reflects this march of progress. We're always thinking about the end user, whether it's a company employee, citizen, customer or student. Whether we're designing services, products, websites, posters, or anything else. All good companies and agencies do this now. And I think Steve Jobs and his colleagues can take some of the credit for this.

Thanks Steve!

(Thanks also to Jonathan Mak for the Apple / Jobs logo)

Friday, 26 August 2011

Leaving on a jet plane

When my wife and I were doing a round-the-world trip in 2003/04, we lived in Sydney for 10 months - and fell in love with the place. So much so that we've decided to move back and spend some more time there; we've spent the last two years trying to get a visa, and I'm happy to say they're letting us in!

We'll be leaving on 15th October all being well, doing some travelling en route, and we'll arrive down under mid-December. We'll start off living in a borough called Cammeray, nicely located between the main harbour and middle harbour (map). No jobs lined up yet, but the intention is to start asking around in September.

Hope to see some of you there!

Wednesday, 27 July 2011

Prototyping in code

I've just written a post for The Team blog on this subject, but given that my personal blog has a more web design-savvy audience I'll do an abridged version here. If this version doesn't make sense, you know where to look!

We hosted the inaugural UX Bootcamp last week, organised by Leisa Reichelt. The subject was ‘Prototyping in Code’. I'll assume for sake of brevity that readers know what prototyping is and why it's important.

But why use working code for prototypes? There are a few potential reasons:
  • With experience, and a set of good templates, it's possible to create and amend a prototype really quickly

  • It allows you to include and test complex interactions, such as click events or fancy form elements. You can also test for different browser widths / screen sizes, including mobile, especially if you have an understanding of media queries

  • By improving our understanding of web site architecture, it strengthens our ability to describe intentions to web developers

  • By designing sites in this way, you don't have to spend money on other tools such as OmniGraffle or Photoshop
The UX Bootcamp was, first and foremost, a crash course in creating basic code. We learned how to mark up content correctly, how to style it using CSS and how to introduce funky interactions using JavaScript (predominantly JQuery, but also Chosen for forms). We learned where to find useful grid templates, for large screens and mobile. There were kittens. We also learned how to use an app to streamline the workflow (I used Espresso, others used Coda). The course material was fantastic, and the facilitators (Anna, Peter and Alex) were incredibly patient and really knew their stuff. We definitely finished the course with a great foundation to build on.

But would we use code for prototyping? That's a harder question to answer. To my mind, if you're starting from a point where you know this stuff, and have a set of familiar templates from which to draw, it might well make sense to use thesetools for creating prototypes. However my feeling was that this wouldn't work as well for designers learning to code for the first time. We depend on these designers to give deep thought to the layout and flow through a website, considering the user's goals at all times - and hacking code could be a big distraction from this. It's far easier to draw a box in OmniGraffle, which is better for subsequent annotation as well.

That said, there's no doubt in my mind that all designers would benefit from a working knowledge of the tools that power the web, and I'm well chuffed with the course. Nice one, Leisa!

Monday, 25 July 2011


When I was growing up, I had what my parents might call an unhealthy obsession with computer games. My brother had a ZX81, my best mate had a Spectrum 48k (with a ram pack!), and I had a Vic 20. And then one birthday, I was lucky enough to get a Commodore 64 - and my life changed forever.

I used to spend countless hours in my room playing computer games. For some reason, the one which always comes to mind now (25 years later) is Gauntlet - but there were dozens more.

So anyway, I recently picked up a couple of copies of ZZAP!! 64, the industry mag for the Commodore 64, and boy did the memories come flooding back!! Ghosts'N Goblins! Paperboy! Rambo! Yie Ar Kung Fu! Green Beret! Out Run! And oh so many more!

I remember owning these issues. Odd what your brain remembers and decides to forget - but then, I was completely obsessed. Clearly a lot of love went into these mags. It wasn't just about game reviews, but hints and tips, game maps, top charts, kick-ass joysticks, 8-bit art, and so much more. Sometimes we got tapes, containing 8 Bit music from our favorite games! Even the adverts were brilliant, showing screen shots and cover art hinting at an altogether more innocent time.

Anyway, seeing as I was enjoying these magazines so much I figured you might too. Here's a gallery on Flickr for y'all:

Wednesday, 13 July 2011

A share of the blame

Like a lot of other people, I'm enjoying the furore around the News International phone hackings scandal. It isn't just schadenfreude; we've tolerated the gutter press for so long that it seemed like an inescapable and unfortunate part of the fabric of Britain. Now, with a fair wind, the Murdoch empire could come crashing down. Bring popcorn.

But one important fact seems to be widely overlooked. Surely the people who used to read the News of the World, and who still read The Sun, the Sunday Sport, The Mirror, not to mention the colourful cheap women's magazines, and other publications like it, are equally to blame? It's their insatiable appetite for gossip that underpins the entire sordid affair. In the same way that kerb-crawlers are considered law-breakers, creating the demand that fuels the supply, shouldn't the same apply to customers of these newspapers? You might even say that kerb-crawlers have a lot less to be ashamed of - at least there are usually consenting adults involved. No-one consented to having their phones hacked.

Of course, all this shines a light on the British psyche. All countries have their equivalent of the red-tops, but ours seems painfully successful by comparison. It really doesn't bear close inspection. It'll be interesting to see whether the demand for (and supply of) salacious gossip declines once the dust settles on this current debacle. Only good can come of this.

Monday, 11 July 2011

Why Google+ has already failed

It's now a week or so since Google launched their new social networking product, Google+, so here are some early thoughts.

I wanted this to be a Facebook killer, for obvious reasons (Blimey, that blog post is four years old!). There was a glimmer of hope shortly after Google+ launched that it might even meet these high expectations - the essential early adopter geeks were arriving en masse, and reporting that it was a great user experience. And sure enough, adding people to 'circles' - creating groups to target your messages - is pretty compelling.

But then what? Unfortunately, first time user experience isn't a good reflection of how well it'll fit into your existing daily activity. This is where Twitter in particular has been so successful - you can dip in as frequently or rarely as you like, wherever you are (especially in a mobile environment, where you might just want to kill a few minutes).

But there are some fundamental shortcomings with the new Google+ product. I should say that, being a Twitter advocate, I consider the lack of features to be a strength. And to be fair the user interface is pretty and functional. But put simply, "the same, but better" isn't going to be enough to bring a critical mass of users over to a new platform - or especially away from existing ones. It worked for Twitter and Facebook because they were sufficiently novel. For Google+, a high enough percentage of new users needs to arrive at the same time to have a chance of success. This is one area where beta testing will not work. By limiting the initial roll-out in the way that they did, and by not having a strong enough mobile story from the get go, I think they've lost the opportunity to launch a winning platform.

Yes, I know there's an Android app. But there's no iPhone app, and the web app doesn't cut it. Say what you like about closed platforms - this will seriously hamper adoption. And there isn't a public API either, which means no desktop apps, making it difficult to integrate Google+ into my working day. I basically have to remember to keep going to the website. The far more attractive alternative is that I keep using my desktop Twitter app and iPhone twitter app, both of which critically already contain the friends and colleagues I care about.

Of course the API and native iPhone app will come, but that's too little too late. The chance has gone for me and, I suspect, for many others. And I can't help but notice that none of the people I'm connected to on Facebook that I'm not connected to on Twitter have joined. And why would they?

I'm sure Google will continue to invest in Google+, just as they seem to continue supporting Buzz (no idea why!). But it'll take more than group video chat and some interesting Feedback tools to persuade people back en masse. Even the commendable 'liberate data' feature won't be enough.

Some bonus links:

Monday, 16 May 2011

Knowledge Management

Late last year, I was interviewed by Business Link on the subject of Knowledge Management. And just like everyone else, I hate seeing myself talk on camera. So when the video was made available earlier this year, I deliberately kept my head down.

But then I read a complementary article about the video by Luis Suarez, and figured what the hell. So here's the video in all it's glory. Feel free to bring me back down to earth in the comments!

PS Obviously it's not "my" business, I didn't have editorial control over that bit..!

Sunday, 13 March 2011

Agile is broken

I've been managing web development teams for 15 years, and it's always interesting to learn how other teams deal with the same challenges we face.

Strong opinions abound as to the extent to which agile should be implemented in a team which builds websites. I used to work at BT where agile development practices were so deeply ingrained that anyone not fully agile was viewed with derision - no doubt arising from bad experiences (Update 19/3: there's plenty of non-agile behaviour in BT, and the previous link was aimed at them. See Kerry's response below). But, coming as I do from a design-led background, this never sat entirely comfortably with me. In my experience, websites (and other products) not considering design from the outset are pretty awful to use. There are of course exceptions, but I haven't worked on them, and I think they're pretty rare. Maybe the project team had a developer with strong design sensitivities? A rare beast indeed.

The shortcomings of a waterfall approach are well documented - and learned first hand I should add. By doing all the graphical design (and too much documentation) up front, it restricts the chance to iterate during build and learn from testing. The process takes much, much longer and you end up with a poorer product which is difficult to fix. Unhappy customers claim this isn't what they asked for. All this is well known.

But the shortcomings of agile aren't often aired in public. When you implement one feature at a time, and build out from there, strategic vision often gets overlooked, as does design integrity. User experience and overall aesthetic tends to take a back seat. There's little consensus up front on the final solution, which means there's a level of uncertainty about how current work will fit into the solution down the road. The larger the team, the more these effects are amplified. And from an agency perspective, clients usually tender out work based on functionality agreed up front - if you're unwilling to commit to this, they'll go elsewhere.

There are several options that try to blend the best of both worlds, outlined in a session here at SXSW by Karl Nieberding (eBay) and Kris Corzine (Wells Fargo). These include "Mini-waterfall", where you put developers and designers in every sprint. The problem is that you get the same problems as full on waterfall (though less pronounced). There's also "Just in time", where designers work two sprints ahead of development, making sure design work is available when developers need it - and there's a sort of interim design vision to work towards. But then you lose agility and flexibility. You can find yourself working on three sprints at once - next, current and last (for testing). There would be too many complex interactions and versions to track - a huge loss of focus.

The system that works well for us at The Team, endorsed by the speakers here, is a system of partnership between designers and developers throughout the life of the project. There are steps you can take to reduce the waterfall risks, getting developers involved in the design process. We test (at best) or peer review (at worst) throughout the project based on whatever assets are available (sketches, wireframes, early designs, prototypes). Most of our projects are fairly short anyway (1-3 months), reducing the risk / impact of upfront design. And when it comes to build, we adopt standard agile development techniques, using e.g. kanban charts, scrum meetings, and other agile practices.

We've found this works best when we put a lot of emphasis on effective kick off meetings. This is the chance for everyone to contribute towards the vision of the project, and for all to understand what it is that's motivating the customer. A good kick off meeting is critical.

It also places a lot of emphasis on the sketching phase of the project. By kicking around the various approaches in sketch form together, designers and developers can explore the best way to solve problems. Then during design the developer can be thinking (possibly subconsciously) about how the solution might be built.

The proof of the pudding, of course, is in results. As well as defining KPIs at the start, we get a sense of success from whether our customer is happy and if users are satisfied. I'm pleased to say that we've had a lot of success implementing this approach, although the fact we improve with every project shows that we have a lot more to learn.

I'll leave you with the 7 rules of engagement as provided by the above-mentioned SXSW presenters:

1. Shared vision - defined clearly at the outset

2. Engage team - ask for input from everyone, but make it clear it isn't necessarily a democracy

3. Stakeholder buy-in - risk involved, but also reward

4. Excite with prototypes

5. Sit together

6. Communicate - build empathy

7. Get out of the way - once you've established working patterns, support rather than dictate

I can't emphasise No.5 enough - in my experience, all of this falls apart if you're not in constant communication. I don't just mean meetings (which we try and limit), I mean the awareness of activity across the team and involvement of people at a time convenient to the project.

And there's one more thing missing from this - I think the team can form around clearly articulated and prioritised software requirements. This helps drive assumptions out of the system, bringing crucial alignment to the thinking going on in the group.

A game which is broken

Seth Priebatsch (of TED talk fame) gave a keynote here at SXSW which focused on game mechanics, touching on the areas where he feels there is huge potential for application. These include loyalty, customer acquisition and global warming - but his most useful comments (I thought) were about education.

He sees school as "a game which is broken". Schools are near perfect game ecosystems, containing motivated players, challengers, awards, rules, allies, enemies, levels, appointment dynamics, incentives and disincentives and yet we've based education on the wrong rewards. We've replaced the real reward (learning) with a fake reward (test and exam results).

He unpacked the game analogy further; grades are simply levels, and based on that analogy you should never be able to level down. There's currently too large a focus on failing - it should be based on progressions instead. We should start with e.g. zero experience points, so we can then focus on the positive progression through the system.

He had some interesting views on cheating, too - the current disincentive isn't on cheating, it's on getting caught. People learn how to play the game based on how you've designed it. He was educated at Princeton, where he says cheating has been greatly reduced there (from 400 examples per year down to 2), by getting students to write the honour system themselves and sharing the burden of reporting cheating - complicity is treated as much a crime as cheating itself. So, when they take a test, there is no teacher, no admin of any kind. The mentality has changed so the "enemy" is no longer the teacher - it's the test, and you get there together.

At The Team we've got several projects on the go that focus on education, for both children and adults, at school and in the workplace, and it set me thinking about whether the mechanics in those systems can be improved. How effective would it be to influence educational systems via the IT systems which are supposed to help? What are the moral implications? Other than using the Princeton anecdote, what other information do we have to justify a modified design approach?

This also needs to be considered alongside something called the Hierarchy of Cognitive skills. It's one thing to repeat something learned by rote, but the real goal is to progress through the levels through understanding, applying, analysing, evaluating and creating. My gut feel is that the focus on the appropriate rewards would help move more students through this process.

Lots of food for thought!

Saturday, 12 March 2011

The message is the medium

I'm attending the SXSW conference in Austin, Texas, and will be posting notes from the best sessions here. All of them obviously written in a hurry, and some of which may even make sense!

First up is an excellent presentation from Josh Clark (@globalmoxie), who talked about iPad design headaches. All examples listed here are iPad apps (Update 14/03/11, his slides can be found here).

iPad users have a low resting heart rate...sitting, reclining, a device of leisure and recreation - and this should drive a lot of the design decisions.

Avoid "greedy pixel syndrome" - continue to recognize the value of white space. Don't just jam in the information. Let me ask for it when I need it. Create an environment of "ask and answer". Make each tap satisfying. Think: tap quality is more important than tap quantity.

Media hypertrophy / overkill - it's tempting to focus on first time use, but more important to consider people using them every day. Example: ABC news website has an awful globe thing showing all the videos - good for demos (perhaps), but a bad presentation of news, much of which can't be seen - and therefore poor for repeat usage.

Supress the urge to show off. Focus on the content more than the form. Example: Solar walk. Sophisticated interface, but it falls away so you can focus on the content. Example: Marvel comics, great example of how to get past the interface, get to the content. Example: New York Times - familiar isn't always bad.Example: Flipboard - comfort and familiarity. And people love it. We have centuries of know-how when it comes to presenting text - lean on it.

But don't be too tied to analogue - are page flips necessary? Feedback is good, but speed and feeling are critical. Don't distract.

Side note: iBooks enables page flips, but on iPad calendar / contacts, even though the information is shown in a book form, swipe to turn page doesn't work. Actually deletes contacts!

Ask: Is different actually better?

Avoid metaphor clutter. Choose one and make it work. If it looks like a physical object, people will try to interact with it. Example: App called "Manage" uses several real world metaphors that make you want to interact - but you can't.

Avoid popover pox. Example: Twitterific is great, but should just use popovers for quick peeks - not for extended exploration.

iPad elbow. "I hate the iPad's back button with the heat of a million suns" - too small, too high. Example: Twitter app does a great job getting rid of the back button. Think: Where do your fingers naturally come to rest?

We're so used to mouse pointers, but using fingers to touch changes things Psychologically, Ergonomically and Emotionally. "Big screens invite big gestures"

The old adage of the medium being the message is now turned on it's head. Now, "the message is the medium". "Buttons are a hack". 2 year olds have a fresh perspective on this.

Explore multitouch gestures. Example: Uzi draws you into experimentation. (From a chat I had with him afterwards: What affordances can you give to show multitouch gestures are available or enabled? For more conventional apps, you obviously need to avoid presenting multitouch options up front, as this would probably confuse the user as they're getting started. Maybe consider hiding them under 'help' settings, or showing a couple of circles flicking across the screen to hint at the functionality. Another option is waiting until say fifth time of use before being more explicit. And then perhaps repressing the hint when you'e detected that the function has actually been used - although remember that iPads, unlike iPhones, are often used by more than one person)

Wednesday, 12 January 2011

The Future of Intranets

Seeing as it’s the new year, I figured its time for a prediction or two!

I believe that 2011 is going to see a significant change in the way we look at intranets. To try and figure out what these changes might be, let’s have a look at two big trends we’re seeing.

1. External tools empowering the workforce

People everywhere have embraced not only online services such as Facebook and Twitter (500m+ and 175m+ registered users, respectively), but also consumer tools such as the latest smartphones (50m iPhones sold up to April 2010 alone). These aren’t just the tools your employees want to use, but also the ones your customers enjoy using. Many of them are using these tools to develop and maintain relationships, solve problems, or build communities - the latest big thing, Quora, being a great example.

Is this a drain on time and resources? Maybe for some, but in this ultra-competitive age companies can’t afford to ignore the benefits. Making internal services and information more broadly available on more devices means:

- your customers can make direct contact with the right people in your organisation more quickly, leading to greater customer and employee satisfaction and reduced call centre costs
- your staff become aware of customer needs more quickly and in the right context, allowing them to adapt your business more quickly
- your staff can spot emerging trends and demands more quickly, and this information can be used to support appropriate strategic responses, as well as generate new sales opportunities
- the company will be seen as tech savvy, increasing the prospects of new clients doing business with you.
- this company profile helps with attracting and retaining talent - giving staff this freedom is liberating and exciting!
- time wasted trying to locate important information is greatly reduced
- time and money spent trying to protect non-sensitive information can instead be focused on protecting that which is of genuine strategic importance
- internal projects which might benefit from input from external sources are more likely to be successful

The highly motivated employees most likely to make a difference to your business - especially the emerging generation - will depend on these tools to do their jobs to the best of their abilities. Indeed, we need to learn from digital natives as they join the workforce taking all this for granted.

2. Continued emergence of open source

While we did our fair share of intranet design work in 2010 using large intranet tools, such as Microsoft Sharepoint and SiteCore, we’re also noticing an increasing reluctance to use these tools. Whether this is because the licences are so expensive, or the tools are painful to configure, it doesn’t really matter - companies are becoming more receptive to alternatives. And this comes at a time when open source has come of age, with powerful open platforms such as Drupal and Django being used for just about everything else. Why not intranets?

There are many reasons - poor interoperability with other existing systems comes to mind - but one of the main ones is inertia. Many companies have invested a huge amount of money in the existing solutions, and change is slow, painful and expensive. But for those on a more limited budget - or those starting with a clean sheet of paper - the options are starting to open up. We’re certainly investing effort in this direction in 2011.

So, what does all this mean?

It’s time to reassess the purpose and nature of the intranet. It used to be that intranets were all about internal communications, and making sure secrets were kept that way. Certainly both of these factors remain mission critical.

But now the monolithic approach to intranets is holding many businesses back. As demonstrated above, if your company isn’t taking advantage of the benefits of appropriate transparency and connectedness, your competitors will be. Intranet projects going forward will be less about creating a single internal system, and more about managing and supporting several systems - only some of which will be under your direct control, and the remainder will need to take external access into account.

The good news is that there is already an established process for designing these new systems. User Centred Design has always started from the position of enquiry; of trying to find out what communication patterns are needed or currently exist and then seeking to improve them - not start from the technology and work backwards from there. If we start by abandoning assumptions, especially those around conventional intranet design, it will have a massive effect on the fitness of your business going forwards.