Skip to content

A surprisingly enjoyable errand

January 14, 2013

I just had the surprising pleasure of having to stop in to the Post Office over lunch to send a parcel. This is not an errand I would normally describe a pleasure but this is the first time I’ve seen the Brisbane GPO since their store layout redesign.

The product shelving layout, self-serve kiosks (using the same hardware as supermarkets), easy to follow interactive instructions and well labelled drop-boxes saw me happily serve myself without the need for assistance from any of the floating staff. And all without having to wait in a queue for 20mins.

Brisbane GPO 3 Brisbane GPO 2 Brisbane GPO 1

I’m now looking forward to the next time I have to go old school and use the snail mail.

Kudos to Post Office design team for a job well done.

The Art of Presenting a Concept

December 10, 2012

I recently had the unpleasant experience of watching a badly presented design concept.

It was unpleasant because of my negative knee-jerk reaction to it. Before I control my mouth I started nit-picking minor details, like the choice of font and styles, when all they were after was feedback on the name and the concept.

At the time I was rationally aware that I wasn’t being helpful, yet I couldn’t stop.

The concept itself wasn’t bad; in fact I really liked it. It was just the pitch itself that was badly done.

It was really challenging experience for me because I’m usually on the other side, presenting the concept. I know how frustrating it is to put a lot of work in to a design; considering the proposition and the target audience, how it is represented in the content and structure of a page, and then how the colours and fonts provide just the icing and cherry on top of a well thought out package.

I know what it is like to do all this work and then have someone fixate on just the superficial skin of the concept – it’s really annoying. And yet here I was doing it myself.

The experience got me thinking about what happened. I didn’t want that irrational reaction to be the only feedback they got from me. Thankfully it was an internal piece of work, with colleagues I know well. This gave me the opportunity to mull it over for an hour before getting back in touch and telling them that I actually really liked their concept and that they just had to work on their pitch.

The happy ending to the story is that they did a presentation version 2 the next day and they blew everyone away. Rather than walking out feeling negative, the audience were all really excited by the concept and went away feeling pumped.

What did they do wrong? They made 3 common mistakes:

  1. They didn’t explain what the design that they were showing us was for and the context of how it would be used. They assumed we knew what they were doing and why.
  2. They jumped straight in to the solution without explaining the journey of how they came to that particular solution. In the interests of time they just cut to the chase and presented the final idea.
  3. They presented a draft concept in a high-fidelity polished format, even though it was still a work in progress.

Here’s what they did different the next day which made it far more successful:

  1. They booked a longer time and took us through a more detailed presentation. They provided all the background, context, and alternatives ideas they considered before getting to the solution. Even though the audience already knew bits and pieces of this story it made sure all the gaps were filled in.
  2. They hand drew their concept and presented that instead. If you want someone to focus on the underlying concept (not the fonts and colours) present ideas in the same level of fidelity as the idea – rough drafts. You can’t comment on fonts and colours if they aren’t any there. We do a lot of lo-fi prototyping for exactly this reason.

The best advice I’ve come across on how to present a design concept was in Matthew Frederick’s book 101 Things I Learned in Architecture School, on page 57 he gave this simple set of instructions:

An effective oral presentation of a studio project begins with the general and proceeds toward the specific.

  1. State the design problem presented.
  2. Discuss the values, attitude, and approach you brought to the design problem.
  3. Describe your design process and the major discoveries and ideas you encountered along the way.
  4. State the parti, or the unifying concept, that emerged from your process. Illustrated this with a simple diagram.
  5. Present your drawings (plans, sections, elevations, and vignettes) and models, always describing them in relationship to the parti.
  6. Perform a modest and confident self-critique.

Never begin a presentation by saying, “Well, you go in the front door here” unless your goal is to put your audience to sleep.

Put your money where your mouth is – hire a User Experience Designer

November 14, 2012

A frustration point for me recently has been companies that list the user experience as their most important priority, yet don’t ever do anything about it.

It’s great that people are starting to recognise the importance of the Experience Economy and that a top notch user experience is a must have for company who sees itself as a serious contender in a market.

As a consultant I  tend to get around a few different companies and in the last year or two I’ve ended up doing quite a few project kick-offs in different places. Pretty much without fail, every company has listed creating a great user experience as top priority.

When we run through our project Trade-Off sliders User Experience is usually listed as the least negotiable factor in a project.

Yet, more often than not these companies aren’t willing to put in the effort or resources required to build a great user experience. They don’t do regular user research and have limited direct contact with their customers/users, don’t have any internal design capabilities, and don’t ever actually do anything other than saying “yes, it’s our top priority!” or “It has to have a great user experience“.

Despite all their verbiage, they are really no more than a Level 2 on the UX Maturity scale: They recognise UX is important but it receives little funding.

Courtesy of Planning your Strategy, Renato Feijó – Johnny Holland Magazine

I regularly get people walking past our sketchboards and design walls commenting on how exciting the UX driven approach is. They get excited by our UX tools and the vision they create. Then they walk off in wonderment thinking about how great it would be for their team to work like that – and do nothing about it.

Less talk, more walk. 

Taking a user centered approach to building a product doesn’t just happen by accident. It takes effort and expertise to do these things – but any team can if they have the right mix of skills.

Stop outsourcing the user experience design of your product – your most important asset – to external design agencies.

Bring design capabilities in to your organisation. Hire a UX Designer, someone who specialises in creating awesome experiences.

They will help you get outside of the building and talk to someone who doesn’t have an employee number. They will help you drive projects with a focus on what the user experience will be, not just what 100 page requirements document says. They will help you build a more mature UX practice.

If you make excuses such as “We don’t have the resources” or “We can’t increase our head count” then you’re simply not prioritising your user experience over other things so stop claiming that you do.

Day of the yak shave

November 6, 2012

Some times you just have one of those days where you need to accept that there is a hairy yak standing in front of you and get on with removing it’s hair…

One of the most useful terms I’ve learnt since working side by side with Devs is Yak Shaving.

Yak Shaving: Any seemingly pointless activity which is actually necessary to solve a problem which solves a problem which, several levels of recursion later, solves the real problem you’re working on.

Today has been a day focussed on becoming fully integrated with the Borg that I’m currently working at so that I can access all the internal systems/tools. At the end of the day I have far more hairless yaks to show than tasks completed.

Here’s the long version of the yak shaving story, courtesy of Seth Godin:

Yak Shaving is the last step of a series of steps that occurs when you find something you need to do. “I want to wax the car today.”
“Oops, the hose is still broken from the winter. I’ll need to buy a new one at Home Depot.”
“But Home Depot is on the other side of the Tappan Zee bridge and getting there without my EZPass is miserable because of the tolls.”
“But, wait! I could borrow my neighbor’s EZPass…”
“Bob won’t lend me his EZPass until I return the mooshi pillow my son borrowed, though.”
“And we haven’t returned it because some of the stuffing fell out and we need to get some yak hair to restuff it.”
And the next thing you know, you’re at the zoo, shaving a yak, all so you can wax your car.


Dear Vodafone, I’ve just fallen out of like with you

October 17, 2012

Dear Vodafone

I’m disappointed that I had to write this letter, but due to my recent experience I would like to break up with you. You have failed me in my time of need and have thereby lost my faith and affection.

My iPhone 4 screen shattered last week. I dropped it when putting it in my pocket and it landed at the wrong angle on concrete. Everything else still works, it’s just the screen that shattered. 

No I don’t use a case. I’m morally against covering up a beautiful physical product with an ugly case. A well-designed product shouldn’t need one. I often wonder what Jonathan Ive thinks about people covering up his beautiful industrial design work with a crappy piece of rubber…but that’s another conversation.

Vodafone, why I blaming you for the iPhone’s flaws is because I’ve been paying $10/mo on phone insurance for the last couple of years which is supposed to take care of me in these situations. This is the first time I’ve needed to use the insurance and I’ve found that it is a completely disappointing product.

Let me tell you about my disappointing experience…

I broke the phone on a weekend. That Monday I went in the Vodafone store in the Queen st Mall  to figure out what I needed to do to get it fixed. My assumption was that you’d be able to help me fix it there on the spot somehow. It would probably involve sending it off somewhere to be fixed, but it would only take a day or two to get done. In the mean time you’d supply me with a loaner so that I wouldn’t be left without my crucial communication tool (read ‘extension of my personality’).

It was a busy time for me, I had a crazy busy work week and was going away for the upcoming weekend. I didn’t have the time to follow up and certainly couldn’t afford to be without a phone for long.

When I showed my poor phone to the friendly girl in store she told me that to get it fixed I had to go on the Vodafone website and submit an insurance claim. Once the claim had been processed I’d be given a claim number that I could then bring back in to the store and then they would help me. I asked if I could sit down and do it now on the computer she was showing me on. Unfortunately, there was no point as the claim would take approximately 5 working days to be processed….5 working days. 

What was I supposed to do in the mean time?

Now my phone was still just functional. It ran fine and I could just make out what it said through cracks in the shattered glass. But what would have happened if it didn’t work at all? I’d just have to wait patiently for 5 days while someone processed the paperwork?

She told me the alternative was to go to an Apple store and get them to do it. It would be more expensive (about $225 compared than $125 for the insurance excess) but it would be doe while I wait.

But then why have I being paying for insurance on my phone all this time?

Flabbergasted, I went back to my office to submit the claim online as a matter of principle.

5 days later, I received an email from the insurance company checking my phone number. Due to the poor usability of their web form I accidentally left out a digit of my phone number.  That was on a Thursday, I then had to wait another 4 days to Monday before they replied with my claim number.

Today I went back in the store with my claim number, the lovely girl told me that I’d have to then send off my phone to the company to be fixed. She said it would probably take about 5 days, but wasn’t sure because they don’t usually see the phones again in store as they get sent straight to your address.

There was no automatic offer of a temporary replacement phone to keep me going in the mean time.

I felt sorry for this poor girl, she seemed genuinely pained when I told her that I would prefer to go away as a disgruntled and unhappy Vodafone customer to sort it out myself at an Apple store. She was perfectly friendly and as helpful as she could be. I almost wish that Vodafone would apologise to their staff for putting them in to this position.

I spent a day in a Vodafone store once as part of some customer research. Usually the staff are always hugely helpful and friendly, they are highly affective (and creative) at fixing the problems that they have systems access to sort out. But they are often handcuffed in key areas and end up copping abuse from customers for things they have no control over. They are often left with no choice but to tell customers to call the call-centre to get some things done. From a customers perspective that makes no sense. They are Vodafone staff, working in a Vodafone store, wearing Vodafone branded clothing, why can’t they help me with everything?

This all stems from a bad product decision. Whoever is the product manager of the phone insurance product deserves the blame for this. They chose and use a poor 3rd party vendor who offers an extremely disappointing customer experience.

Either way, as a customer I don’t care. I pay Vodafone for my insurance and am extremely disappointed with how you are (not) helping me in my time of need.

The insurance is provided by a 3rd party company, but it is still your responsibility. I am a Vodafone customer, not a Marsh customer. I pay you $93 per month for your service, part of which is for insurance in case something happens my phone. 

I’ve been a content Vodafone customer for a few years now. Your network issues that everyone always calls you ‘Vodafail’ for don’t bother me too much. I’m a city dweller where I get good enough coverage. Whenever I leave the city I’m generally quite happy to escape phone coverage. I’m happy paying less for the inferior network.

I’ve also always had a soft spot for Vodafone after having worked there for a few months in the Online User Experience Team. They used to be a clear step above their competitors on the online customer experience front, which is more important to me (as a side note this has changed somewhat nowadays as Telstra has managed to catch up quite a lot).

I used to be a net promoter of yours. I would happily give you an 8 on the NPS. Despite all the other complaints I had heard, I was always quietly happy with my service.

Now I have become a detractor. Now I’m left bitching about my experience and how bad Vodafone is to anyone who will listen. I would be lucky to give you a NPS rating of 4 at the moment. In my time of need you were not there for me.

Now I can’t wait for my contract to finish so that I can play the market a little and see what other providers out there are like.

Vodafone, I was hoping that this day wouldn’t come but unfortunately now it has. Unfortunately, it’s not me, it’s you.

I would like to break my ties with. I hope you can understand and do something to change your insurance product in the future, even if it’s just for the benefit other customers other than me.

Yours sincerely
Ben Melbourne

Defining Design Thinking

September 19, 2012

Listening to an interview with Sir George Cox, chairman of the UK’s Design Council, on ABC Radio’s By Design this morning, he gave a great definition of Design Thinking – something that I often struggle to articulate in a simple way.

This is my paraphrased version of what he described. Yes, it’s multipart, but to me that is what makes it more meaningful as it explains the  different elements that make up Design Thinking:

  • Creativity is coming up with new ideas.
  • Innovation is introducing new ways of doing things.
  • Design is channelling creativity for a purpose.
  • Designers are people who have been trained to reframe problems and approach them from different angles.
  • Design Thinking is a way of using design methodologies to find new and innovative solutions to problems.





From Designer to Product Owner: The pleasures and pains of being given control of the product vision

July 19, 2012

As the UX Design discipline has matured in the last few years, business people have started appreciating the value that our design thinking brings. This has created a growing trend of UX Designers taking on more business responsibility and moving in to Product Owner roles.

As a UXer, I see this as a very natural step in the evolution of our profession.  The constant bane of my usability testing life has been UI issues caused by business decisions that are baked in to the value proposition of a product.  Issues created by the design of a page element are easy to fix in comparison.

By taking on the Product Owner role, a UXer is able to move further up the decision making stream and have an input in to these business decisions.  Here they can help shape the product strategy and avoid choices that negatively impact the user experience – rather than having to compensate for them later in design.

My simplified view of a UXer as Product Owner is that they would bring a different focus to the role. Rather than having someone focus on numbers and project management, you would have someone who is passionate about creating great experiences, as well as possessing the skills required to envision and design it.

The flip side of this is that the UXer as a Product Owner would most likely be weaker in the pragmatic business skills required for the role, such as budgeting and planning.  However, with some support from the business these could be easily overcome.

On my latest project I was given this opportunity to take on a Product Owner role, owning and driving the product vision while building a new innovative product.  Not unexpectedly, it wasn’t the entire UX utopian wonderland that I had imagined in my mind.

Here are some of challenges and lessons that I’ve taken away from having to put down my post-it notes and embrace spreadsheets.

What do I mean by a Product Owner

To start, let’s state a quick definition of a the Product Owner role in an Agile team:

Product Owner – The Product Owner represents the voice of the customer and is accountable for ensuring that the team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog.

On a day-to-day basis this means that Devs are always talking with the Product Owner about the scope and requirements for stories.  Then, once a story has been developed and tested, it is shown to the Product Owner before being deployed.

This means that the Product Owner is essentially the key stakeholder who sets the direction of the team, prioritises what they work on and signs-off what they deliver. This isn’t so much about authority as maintaining accountability to the product vision.

About the project

At this point I can’t actually share details of the product itself, however I can talk about the team and project setup.  We assigned our own internal Product Owner as the client wasn’t able to spend much time with us in person on a day-to-day basis, nor did they have much experience building software. What they did have was a clear vision for the product.  Therefore we needed someone within our small team to act as a Product Owner and be responsible for understanding and representing that vision. It made natural sense to assign a UXer to this role as we would normally include a UXer in to our teams to design and articulate the product experience, which requires an understanding of what the product vision is.

What was different for me as a UXer in this case was that I had to take control of guiding the strategic decisions of the product for myself, rather than just designing the interface and advising someone else.

Embracing the natural tension between a UX Designer & Tech Lead

What became a key dynamic of the project was the pairing of myself and the Tech Lead and the way we learnt to work together.

As a pair, the two of us we were responsible for leading the team and communicating with the clients, but both of us with a different focus – me on the vision/user experience and the Tech Lead on figuring out how to build something that combined a challenging suite of technologies.

On any project there is always a natural tension between Designers who want to build the perfect product that they can see in their mind and the Developers who have to find a way to practically build something out of code.  This disconnect can easily turn it to friction if there isn’t collaboration (see Waterfall).

In a healthy team, where each person understands and appreciates the other’s priorities, embracing this tension fuels an ongoing negotiation and collaboration – which is required to build a great product.  This is the basis for believing in the value of multi-disciplinary teams.

For myself personally in this context, it constantly forced me to think not just about what the ideal end state should be, but also about the smaller pragmatic steps required to get there. And if I didn’t, it would only be a matter of time before the Tech Lead pulled me back down to earth.

This wasn’t all just one-sided negotiation though. By articulating my ideas and the intent behind them we were usually able to find solutions that met both our needs, or just simply agree that a high-value feature was worth the high-cost it took to build.

Living between worlds – no longer a blue sky designer

This ongoing negotiation led to a subtle yet significant shift in my mindset.

As a UXer it’s your job to advocate for the user and get the best result for them.  Of course this needs to be balanced with business needs and technical feasibility. However, as a designer I’ve still always tried to find ways to sneak in little extra bits of functionality – no matter how much Minimum Viable Product Kool-Aid I’ve drunk.

As a Product Owner I was acutely aware the full backlog of scope and how adding in anything extra came at a cost of pushing out other features. The clients had a clear vision of what the product should be (this was arguably their MVP) and this in itself was an ambitious piece of work.

It became a day-to-day priority to think about what is the least amount of work we can to do to get this product out the door. Whilst as a UXer I wanted to build the perfect product, the business needed to launch it sometime this year and the technology layer meant there was a lot of work just to get anything up and running.

At times it felt like I had the Designer devil on one shoulder and the Product Owner angel on the other – one trying to convince me to sneak in extra features whilst the other reminded me of the timelines and scope.

Designers love constraints. As a designer it became an interesting challenge to design for the most pared back version of the product I could figure out.

I stopped thinking about what is the dream state for this product, but instead, more pragmatically, how can we get this built? I became focused on what stories could be stripped out and deprioritised in the backlog, not on what other cool things the product could do.

I became acutely aware of this shift one Friday when I was sharing my work-in-progress with other ThoughtWorks UXers during a design studio session.  Whilst the other designers were having fun exploring ideas in a lively session I was getting frustrated because everything they were coming up with was adding to, rather than removing scope.

One practical tool it did make me think about is that the next time I’m running a collaborative design sketching session, a great way of setting the design challenges we usually state as ‘How Might We…’ would be to ask both:

  • What is the blue-sky version of this feature?
  • What is the minimal version of this feature that will still meets the user need?

Living between worlds – not yet a pragmatist Project Manager

The part of the job that I didn’t choose to sign-up for as the Product Owner was the project management duties – coordinating resourcing, sequencing of events to get to the end goal, managing clients, etc. In a smaller team these duties naturally come with the role, as it’s hard to justify a dedicated Project Manager resource when it’s not a full-time workload.

This was not unexpected, nor a major problem. The challenge came from me not being a skilled or experienced PM by nature, particularly on non-design related activities. With some support and assistance from the team we were able to share the load and teach me new skills where appropriate.

The problem came from the amount of my time and focus it chipped away.  It all meant less time that I was able to spend doing actual design tasks and communicating the vision.

Finding time for design

The biggest challenge I faced was carving off dedicated design time to perform my other part of my role, that of the UX Designer on the team.

Prioritising, analysing and reviewing stories with devs became an all-engrossing task on a daily basis.  It was one of my most important tasks as it’s where I had real ability to shape the small details. In a team with 2-3 dev pairs, there were always stories needing to be analysed, reviewed, or just needing some informal input from the PO.  As someone supporting the team I had to prioritise these. The last thing I wanted to do was become a bottleneck or discourage the devs from seeking my input.

This meant that I rarely found the dedicated time to do traditional UX work, such as prototyping and wireframing.  In an Agile world it’s not very PC to say that I sometimes need to put on my headphones and block out the rest of the team, but sometimes it’s necessary to focus on a design task without distractions for a full afternoon so that you can get your head in the problem space. Tackling complex problems can be compared to going through the cycles required to get into deep REM sleep or just achieve flow.

Sometimes the content in a higher-fidelity wireframe or design mock is the best input for a dev to build from.  They focus on coding the plumbing that makes the page work and not the exact layout and copy on page.  A typical example of this is web-forms. I’m quite particular about the getting the language right on these for the user, whereas devs are usually focused on capturing the right data and storing it appropriately.  Taking the time to wireframe out the flow and wordsmithing the content is a small upfront investment.  It takes the guesswork out of the dev time and avoids revisions or accruing UX design debt – but it takes some dedicated time to create.

This kind of work also helps towards building and evolving a design wall, which creates a shared vision that is visible to everyone.   I always had plenty of ideas in my head, but it’s easy to forget that everyone else in the team hasn’t had a chance to be part of all the conversions and whiteboarding sessions. I was the only one who had full view of the overall picture vision that I have in my head.  Taking this time to capture it, get it out of my head and on to a wall is critical is the only way to effectively communicate it.

Feeding the devs – Designing based on a pull system

Agile UX involves designing just-in-time. This pull-based system is a different way of thinking for most designers.

I had to learn to be disciplined about focusing on the stories that were in the immediate backlog, not thinking about the full picture for the next 6-12 months. As much as I wanted to consider and design a solution that would support the entire feature set that we could ever build, it doesn’t help you use your precious design time to keep feeding the devs who are building the here and now.

The thing that I’ve learnt to do is to design for the stories that are coming in the next one or two months (or 2-3 iterations). Usually there is a common theme to what stories are coming up in that period. There is usually a manageable chunk of features that can be considered as a one design piece, so that you don’t have to revisit the design every story.

At the same time this allows for emergent design, where you are able to build, test and learn. Starting from a simple design and allowing the details to be built and refined as you learn more.  This does mean that sometimes you need to circle back and change the parts of the interface that have already been built (find the time for this is another challenge in itself).

What this does mean is that you willingly take on UX design debt.

Accepting UX design debt

Sometimes you need to take on a little bit of debt to be able to purchase something.

As a Product Owner I had to learn to let go of control of every detail and accept some things that weren’t perfect in my mind. Otherwise we would never have been able to get anything done. Partly this was just about learning to be patient in seeing the product evolve. Partly is was it was about letting the team figure out some of the details for themselves, even if it wasn’t perfect from my designers point of view. It comes back to thinking about UX as a facilitator, not just a designer.

No product is perfect in it’s first version. Great products take time to mature. Even the sacrosanct iPod/iPhone took a couple of versions to truly hit its stride.

It’s all about the journey, not the destination

The biggest take-away for me about the experience is the shift in the focus from the destination to mapping out a path to get there.

As Designers we’re great at envisioning these utopian like product states where everything has clean smooth lines and plenty of white space.  We can mock that up for you in no time.  What we’re not so good at is thinking about the steps involved in creating that vision.

The Product Owner needs to find a way of guiding a team to develop a product from it’s current state, be that a rough idea or working software, to where it needs to go in the future. This requires patience and understanding the challenges that need to overcome along the way, particularly that of making it profitable/sustainable in the mean time or the destination changing.

None of the products that we put on a pedestal now started like that in their first version, whether it be the iPhone, Facebook or automobiles.  They all started as something far simpler and have evolved over every iteration to what we know and love today.

As a Product Owner you have to start thinking more strategically about how you steer the product along the way.  Having a better appreciation that this journey is taking place going to make me a better, more effective designer.

Calling all Brisbane based UXers

July 11, 2012

Come join the Brisbane User Experience & Interaction Design Group.

For User Experience & Interaction Design professionals who design interactive systems and products of all types: web, desktop, mobile, consumer electronics, digitally-enhanced environments and more. It’s a get-together to share ideas and learn in a social environment, and is typically made up of short presentations and entertaining discussions on trends, tools, tips and techniques that help Designers in their day to day design work.

This group is the latest version of the IxDA Brisbane group. As part of this technology refresh we the time has come for us to update this group’s name and migrate to the site.

I have also set up the Brisbane User Experience & Interaction Design Group LinkedIn group. I also encourage everyone to join that group so we can continue to increase our visibility and networks.
I look forward to continuing the conversation over on the Meetup group.


The UPA is dead, long live the UXPA!

June 20, 2012

Recently the UPA (Usability Professionals Association) announced that it is changing it’s name to the UXPA (User Experience Professionals Association).

You can see the announcement letter from the president here – An open letter to the User Experience Community

The UPA has long been criticised as being a relic of an old school mentality that ‘Usability’ is a something separate to of the broader UX design discipline. Largely this has just been because they haven’t wanted to change the name of a well cognised professional organisation. None the less this has still led to them being seen as outdated by other groups such as the IxDA (Interaction Design Association). Or in competition with HCI people.

This has also been part of the ongoing conversation about defining User Experience Design, what fits under this umbrella term, or that you can’t design an experience – just the interactions.

Is this change a sign of the UX discipline starting to mature, or just simply a cynical land grab from professional bodies? I’m curious to hear other peoples’ opinions about this.

Although I’ve been an active member of the IxDA for a while (I run the Brisbane group and have been to some of the conferences), I’ve never had much to do with the UPA, other having paid the membership fee for one year and feeling like I got a huge amount out of it.

Does anyone else have any experiences with them?

Remote collaboration setup and etiquette

May 17, 2012

One of the key mantras of Agile is working in co-located teams. Despite this most of my recent projects have involved a distributed team. It seems to have become inevitable that for one reason or another teams can’t be permanently based in the same space.

While I believe that co-location is still the ideal, it doesn’t mean that distributed teams can’t also be productive.

Over the years of being on both sides of the physical divide (both with the majority of the team or by myself) I’ve learnt that a few simple set-up points or attention to basic etiquette can make all the difference.

Here are some of the things I’ve learnt. To me some of these seem really obvious, but based on personal experience over the years I don’t think they are so hence I felt the need to put up a post about it.

Have an always-on channel across locations

Set up a video call to connect the different locations and leave it on the entire working day.  Picking-up the phone and calling really is a big barrier.  Being able to glance over and see the other team or just walk up to the screen and ask a question makes a huge difference is bring remote teams together. I’ve seen this work effectively in a variety of situations. For offshore teams split across two countries, or just projects where the majority of people are based in one room with a few people in different locations.

In one recent project we had a team based in Melbourne, with individual people dialling in at various times from Sydney, Brisbane and London. A Google+ Hangout was left always on so team members working remotely could dial-in from where ever they were at the time and still be connected to the team. Here’s a pic of the main project room, you can see the TV up one end of the room with a laptop and camera next to it running a Hangout. It also led to some fun and games playing with people’s titles.

Ensure there is some face-face contact

It is important to have some face-face contact to get to know people and build a rapport, particularly early on in a project, ideally at the start. The cost of flights & accommodation do add up but having actually met your team members in person makes a huge difference. Even for non-distributed teams the simple act of going out for dinner & drinks together can help break down all the barriers.

Get a mic in the middle of the conversation

When you have a team broadcasting itself, make sure the mic is in the middle of the conversation and can pick up everyone equally well.  Having the microphone at one end of the room, say at the end of a conference table, will always result in the people at the other end of the room being barely audible.

Separate the mic and camera

Webcams that have an inbuilt mic aren’t good for groups. You can’t just hang one up at one end of the room where it provides the best view and then expect to do both. This is usually the worst place to put a mic. One of the simplest ways to do this is to use a traditional Polycom phone in the middle of the room for audio (which is usually the best quality audio option) and then put a webcam in a corner hooked up to a TV with Skype running the video (but muted).  This is also more reliable as even if the video starts having problems you can still keep talking.

Put a camera in a corner where it can see the whole room

This allows anyone remote to see who’s talking, etc. Being able to see the whole room makes a big difference to feeling like you’re in there.

Add a second camera that focuses on the whiteboard/wall

While the detail on the wall probably can’t be read in fine detail, being able to roughly see what everyone else is focussing on helps draw the remote person in to the room. This is where having a video conferencing tools such as Google Hangouts come in to play. Two or more people in the room can dial-in to provide different perspectives of the room.

Use a ‘chaperone’

If you have a meeting in a room when only one person is on the phone, have someone in the room ‘chaperone’ the remote person.  This person becomes responsible for making sure that any audio/video set-up is working and adjusted when necessary. For instance maybe moving a webcam to keep it focussed on the right spot in the room. In workshops this person can write down the ideas of the person on the phone and add them up on the wall. A great example of this taken to the extreme is George Bluth’s ‘surrogate’ in Arrested Development

Try to project your voice

Over the years I’ve developed a ‘conference phone’ voice where I speak slightly louder and try to be clearer (kind of like my talking to a non-native English speaker voice). However, not everyone feels as comfortable doing this so…

Position quiet people closer to the mic

If someone is more softly spoken, recognise it and move him or her closer to the microphone. Likewise, do the opposite for people who have no problem projecting their voice.

Watch out for people creating noise that disrupts the audio

I’ve lost count of the number of times I’ve seen someone sitting right next a mic tapping away at a table, flipping open/closing their phone, etc. On the other end of the phone all you can hear is a banging noise and not the conversation. It’s a simple matter lack of awareness that can completely disrupt a call.

Mute yourself if you’re not talking

No one likes having to call out a heavy breather. And all the background noise adds up.

Level the playing field, have everyone dial in

It goes against the co-location idea a little, but I’ve found that in some situations it’s far more affective to have everyone dial-in to a conference call, even when a group of them are sitting in the same area. This puts everyone on the same level and gives everyone their own individual mic, i.e. their own handset. When teams have regular calls where everyone is giving weekly WIP updates it lets everyone sit at their desk and partially listen in rather than falling asleep in a meeting room where they can’t be heard very well when they do need to say something.

Recommended tools

  • Audio
    • POTS (plain old telephone system) and conference phones are still the most reliable.
    • Skype can be good for audio calls, but I’ve found running video tends to make it lag after longer calls.
  • Video
    • Skype is a simple favourite for 1-1.
    • For multiple people Google+ Hangout have become a tool of choice as it’s free, anyone can dial in without needing to be added (a downside of Skype), there in no limit to number of people, and you can share screens. There are plenty others out there but Hangouts seem to be the least restrictive.
  • Hardware
    • MacBook pro built-in mics work quite we in a room to capture audio, but they need to be in a central location.
    • Logitech HD Pro Webcam C910 provide both good quality audio & video at a reasonable price.