Trust takes years to build, seconds to break, and forever to repair.
Customer relationships are built upon trust. Trust that a company will provide the product or service that the customer has paid for. Trust that the company will safely store the customer’s details and not misuse them. Trust that a company respects the customer and will do their best to make them happy.
This trust builds over time, with every interaction between the two. A simple a one-off online transaction, won’t build much. A daily face-to-face interaction will build a far deeper relationship.
If something happens to break this trust, it will be lost and take a long time to rebuild. Often something extraordinary is required to rebuild a broken relationship. If it ever can be.
In the world of user experience design, this is why attention to detail is important. Every time you confuse a user or make them work hard to complete a task you chip away at that relationship. Every time you do something sneaky or use a dark pattern you sour the relationship and turn your customer off your company, potentially losing them (and their friends) forever.
I encountered a perfect metaphor for this in my building recently.
The elevators have been unreliable for a long time. Lot’s of people have stories of being stuck in them. It’s an old building so it’s not surprising, but is still frustrating and scary.
They recently started replacing and upgrading the elevators. Which meant they took one out of action for a month or more.
Last week I turned up to work in the morning, coffee in hand, to find the doors to the elevator that had been out of service open. Bright light was gleaming out of the new elevator in to the dim foyer. Bright, clean, operating theatre temperature light was shining off its newly appointed stainless steel fittings.
And it was just sitting there with the doors open. Waiting for someone to get in and try out the shiny new interior.
Yet no one did.
The problem was that no one trusted it. After too many bad experiences no one was willing to believe that this shiny new elevator would finally work. It’s sudden shiny new appearance only added to the distrust.
That morning, myself and two other people who arrived at the same time as me ended up waiting and taking one of the other older elevators.
That day someone from building management must have noticed this reaction by us occupants.
The next morning I was confronted by the same bright light shining out of the waiting elevator. This time it was adorned with signs urging me to trust it and step in to the light.
Can you imagine the amount of distrust that an elevator has built up that people don’t automatically step in to it, let alone require a sign persuade them it is alright.
People accidentally get in to the wrong elevator all the time. It’s comical seeing the automatic response when someone steps in to an elevator going up when they are going down, just because it opened in front of them.
Bringing this back to designing user experiences, it’s strong metaphor for how important it is not to take a customer’s trust for granted. I’ve seen some extraordinary attempts to rebuild trust over the years but none of them wipe the slate clean again (Facebook’s data privacy issues are a great example). They always leave a lingering memory that stops a customer from ever completely losing themselves in their trust for you again. You’re far better off just not breaking your customers trust in the first place.
When I first started working in an Agile environment I was excited to have finally reached the land of opportunity.
I was well aware of the problems with Waterfall. The big-upfront design phases. The painful stakeholder reviews. Having to endlessly review and revise wireframes. Countless annotations explaining every microscopic detail. Pesky developers not building things as specified.
I thought all these problems would magically disappear with Agile. All of a sudden developers would become my best friends. My wireframes wouldn’t need to be anywhere near as detailed. Document version numbers would stop getting in to double figures. My designs might get launched in the same year I created them.
However, I soon realised that these things didn’t just happen automatically. Agile opens up an exciting new way of working for designers, but it also presents a new set of challenges. To experience the benefits I had to adjust the way I worked.
These are some of the challenges I’ve faced and adjustments I’ve learnt to make to my UX practice along the way.
Challenge #1: Not having time to explore ideas and find innovative solutions
In the Agile software development world dedicated design time becomes a precious commodity. The traditional user-centered design approaches start to encounter problems. Taking the time to conduct in-depth user research, analyse the findings, write them up, and then design an extensive solution is an expensive luxury that is rarely affordable.
It’s hard to take the time when a team of developers is waiting for to you to finish so that they can start. As a UXer it feels like you have a steamroller bearing down on me while you’re screaming: ‘Stop, I need to explore more ideas!’
Challenge #2: Feeling like time spent exploring ideas is a waste when you’re trying to be Lean.
The traditional creative process involves playing with designs and seeing where they lead. More often than not the designs themselves get discarded, but the learnings from them fold back in to the overall solution.
Once you start to embrace a Lean way of thinking, taking the time to play around with different options, then discarding them can feel like your deliberately wasting time.
This test and learn approach is actually a core part of Agile, but we just have to adjust to do it in a different way.
Challenge #3: Getting out of the deliverable business.
Our traditional approach of producing shiny, all-encompassing deliverables doesn’t work in an Agile process. Not only do you not have the time but the documents are usually out-of-date before you finish them.
On the flip side, it’s not just a matter of producing lots of low-fidelity prototypes and then handing them over to developers. There can still be communication breakdowns.
We need to use prototypes as a communication tool, not just a deliverable.
We need to get out of the deliverables business.
Adjusting our practice
All of these challenges can be overcome. We just need to adjust our practices to get the most out of the Agile process. We need to focus on the value we deliver, not just the outputs. Once we do, we’ll find that it actually improves our ability to create awesome experiences.
These are some of the ways I’ve learnt to adjust my practice to be a better designer.
Adjustment #1: UX as a facilitator, not just a designer.
Change the way you see your role in the team. We need to let go of control of every little detail and empower our team. We need to use our research skills to take the team on a journey of understanding and empathising with the user.
We need to become an Information Radiator. Not the sole source of knowledge. Give everyone the knowledge required to build a great product that meets the needs of the target audience. There will still be plenty of design work required by you as a designer, but you will be able to start sharing the load.
Adjustment #2: Design as a continuous activity.
Other fields are embracing the “Continuous” approach. Product management is embracing the Lean Startup movement. Launching a MVP, testing and proving a proposition, then continuing to evolve it.
The development community is doing Continuous Delivery to make this possible.
The ability to release software regularly (i.e. daily rather than a few big releases a year) is allowing teams to reduce feedback cycles. Testing and learning rapidly.
As designers we need to embrace this mindset. We need to change our approach to embrace the benefits of this. Shortening our feedback cycles. Learning quickly. Finding out what experiences work and building on them.
Adjustment #3: Do just-enough, just-in-time.
Just-in-time design does what it says in the tin. Don’t try to do everything upfront. Start by sketching a vision, then figure out the details as you go. Make decisions at the last responsible moment.
Change is relentless. If you do too much upfront, the requirements will probably change by the time you get your designs out there.
Tools & Techniques
These are some of the tools and techniques I’ve been using to make these adjustments to my practice.
Collaborative design workshops
To start projects, run collaborative design workshops with stakeholders and the Delivery team. These involve getting everyone in a room and sketching out their ideas about what the product should/could be.
Put it all up on a wall where anyone can see and contribute to it. This creates a sketchboard – a lightweight shared vision of the product, which everyone is bought in to as they contributed to it.
This shared vision can inform the story writing process when kicking off projects. The sketches can also quickly be turned in to prototypes to test and validate the team’s ideas.
Use Iterations to shorten your feedback loops
The iteration cycle allows us to shorten our feedback loops. Each iteration allows us to design and build something new, quickly turning design ideas into working code. These functioning ideas when can then be tested, validated and improved. We no longer have to wait months/years to see if our design works, we can do it immediately.
Problems throwing things over the wall? There shouldn’t be one in the first place. Co-locate yourself with and become part of the development team. Multidisciplinary teams all working in the same place sharing ideas is a key principle of Agile. You don’t need to waste time typing up emails when you can have a quick conversation.
This also allows us to open up the kimono. Lots of developers have never worked with a UXer before. They want to learn to work with us as well. Co-location naturally allows for this to happen.
As the details start to emerge turn your Sketchboard in to a Design Wall. Fill in the details of your vision as you go.
Claim space alongside the Project team’s card wall. Put our wireframes/visual designs on the wall. This will ‘radiate’ details of the UX design and become a source of truth.
Do just enough, just in time. Don’t aim to capture every detail upfront. Capture just enough, and then have a conversation. Sometimes a paper sketch is enough, others a hi-fi mock is required. It’s the conversation that is important. The closer you can get to designing in code the better.
Conducting lightweight research
Bring user feedback in to the team as often as you can. Go guerrilla. Run three sessions every Friday, or every iteration. Make it easy for the team to watch. Capture you findings on Post-it notes, not in PowerPoint.
Often you can put the findings in to action straight away if the team is still working on the feature.
Add usability fixes to the backlog
If you can’t act on usability fixes straight away, become part of the Agile process and prioritise usability fixes like everything else. Write up stories for them and add them to the backlog. The Product Owner can make an informed decision about whether to prioritise them, or build something new. This helps avoid the tension of us designers trying to squeeze small fixes in to the workload in an unstructured way.
Creating great experiences
Some of these Agile ideas aren’t too dissimilar to existing UX techniques, often they just have a different name to what we usually call them. Some principles can be easily applied to the design process, with just a bit of willingness to learn and adapt.
As designers, Agile provides us some great lessons and opportunities to work in better ways. At the same time we can add value to the process as well. Our ability to visually communicate ideas and share a vision helps drive the process and provide a customer focus which can often be lost in the mix of delivery activities.
They key goal is have an entire team collaborating together, finding ways to combine their skills and talents together to create great experiences.
This post is based on this presentation Agile UX conference presentation.
One of the challenges of running usability testing on mobile devices is how to record a video of the session. On desktops recording sessions is easy. Applications like Morae or Silverback have been allowing us to do screen captures with a picture-in-picture window of a participant’s face for years now. They simply use the mouse pointer and webcams to capture of full picture of what the user is doing.
On mobile devices it is not so easy. On mobile devices it’s just as important to see what the users hand/fingers are doing as the targets they are tap on. When you combine this with the movement of handheld devices recording a usability testing session becomes somewhat more complicated.
On a recent project we ran a round of formal usability testing, where we ran ten participants through a competitor comparison of apps. To record these sessions we put together a somewhat ad-hoc, yet highly effective recording setup that used this option of mounting a camera of the device. Here’s an overview of how we made it work, including:
- Choosing a video recording approach
- The pop-up usability lab
- The camera mount – Mr Tappy
- The cameras
- Recording software
- Remote broadcasting of the sessions
- What would we change next time?
Choosing a video recording approach
There are 3 current options that I’ve seen used to capture a session on a mobile device:
- Attach a camera to the device itself.
- Mount a camera above the space where the device will be used.
- Record a screen capture of the device.
Each of these has their relative pros and cons:
|Attach a camera to the device itself||
|Mount a camera above the space where the device will be used||
|Record a screen capture of the device||
Personally I prefer the first option of attaching a camera to the device itself. In most situations having a clear view of the screen and the hands outweighs the participant’s feeling a little bit weird about the camera hanging over the device.
The pop-up usability lab
Having chosen to go with the option of mounting a camera on the device, we set about turning two meeting rooms in to a full-featured mobile device usability testing lab.
Here are some pictures of what we put together.
What’s happening in the room?
The testing lab was made up of the following equipment:
- Two cameras; one mounted on the device, the other in front of the user capturing their face and them holding the device.
- Both cameras feeding in to a laptop, which was recording the session. We used a MacBook pro for this setup. This machine comfortably dealt the processing load for this setup. It also had the 2 x USB inputs and 1 x HDMI output that we needed to connect to the cameras and TV.
- Laptop sitting to the side where the facilitator could see it. This meant that the facilitator could sit back and watch what the user was doing through the screen rather than having to always be looking over the participant’s shoulder.
- HDMI output cable running to a large TV in the room next door broadcasting the screen share and audio to observers.
The camera mount – Mr Tappy
The centerpiece of the setup was our camera mount – Mr Tappy. Mr Tappy is a simple mount, which you can attach a mobile device to, with an adjustable arm that extends over the top of the device to attached a camera to.
Meet Mr Tappy:
The best part about Mr Tappy is that he can be used for all types of devices; phone, tablet, iOS, Android, Windows. The mount is flexible enough to accommodate any sized device. The only restriction is needing to attach some velcro to the back of the device for Mr Tappy to secure to.
Mr Tappy is the brainchild of Nick Bowmast, who I can happily say I used work with a few jobs ago. He took the idea that came from an old improvised mobile testing sled made out of perspex and turned it in to a high-quality product designed specifically for this purpose. I highly recommend it.
One thing we learned was that it’s important to pick up and hand the device to the participant so that they start with it in their hand. The attached camera mount does make participants reluctant to handle the device. Handing it to them when you first ask them to start doing something on it helps get it in their hand and using it.
Still, a few participants just put it back down on the table and used it there. In our context it wasn’t too much of an issue as using a phone whilst it sits on a tabletop is not an uncommon behavior anyway. Otherwise, it’s important to be aware of it that impacts what you are trying to test.
For the camera mounted on the device we used the iCubie camera that Mr Tappy recommends. It’s the smallest and lightest camera that could be found at the time.
It’s downside is that it’s not super high-resolution. Therein lies the trade-off. We considered using a higher quality camera but they all just became too big and bulky to use on the mount. Instead we decided to concede the quality for being less obtrusive.
For the other camera we had on the table camera focused on the participant we used a Logitech HD Pro Webcam C910. It was less important which specific camera we used for this. We used the Logitech as we had one on hand and knew it did good quality HD video and audio.
The recording software was where we had to improvise the most. All the applications out there at the moment were either too expensive to bother with, didn’t allow us to capture the output from two different webcams at one time, or required too much post-production work to sync video feeds.
In the end we took an ad-hoc approach of simply having the two camera feeds open on the desktop using separate applications, then using a third application to do a screen capture of the whole desktop. Whilst not the prettiest video outputs you’ll ever see, it captured everything we needed it to.
Where it got tricky was finding the right combination of apps that didn’t have conflicts and worked with the various cameras. We had to do a bit of trial and error with different media players, plus trouble-shooting to make it work but we eventually found the right combination that worked. Here’s what we had running:
- Device camera feed - Quicktime 7 Pro
- Participant camera feed – Quicktime 10
- Screen capture – Quicktime 10
- Audio output for HDMI feed to TV – LineIn
We had to ensure we left enough hard drive on the laptop to record 50-100gb of video. Full resolution videos of an hour session typically ended up at 30gb before we optimised them to a lower level. We kept an external hard drive handy to off-load videos.
We also had two laptops that setup so that we could quickly swap them if necessary. Occasionally this was necessary if a video was taking a while to be processed and saved.
Remote broadcasting of the sessions
The setup of the office, with two rooms next to each other and a big TV in one, worked out really nicely for our setup. An alternative option that we were also considering was to broadcast the session to a separate location using Skype (or similar) to screen share the video and audio to another location.
Reflection/glare from the ceiling lights can be an issue in seeing the screen of the device through the camera mounted on Mr Tappy. To avoid this we turned off the lights directly above user (we unscrewed the fluorescent lights).
This creates a problem where the camera can’t deal with the contrast between the screen brightness and the dull background. To compensate for the lack of light we setup a lamp to the side of the user, which lit up their hands. We also turned down the device screen brightness to balance out the difference. The balance between all this needs to be tweaked depending on the exact room.
The unintended side effect of all this was to create a somewhat ‘intimate’ setting in the room for participants to walk in to. We made sure we called it out and explained why so that participants weren’t too put off by it.
Controlling the laptop and video feed
Given that the two rooms were directly next-door we connected a Bluetooth keyboard and mouse to laptop, which we put in the observation room. This allowed the observers to run the laptop and control the video (i.e. starting/stopping and trouble shooting), which helped reduce the load on the moderator in the room.
What would we change next time?
Overall we were very happy with the whole setup. I’d happily take the same approach and recommend it to others – hence why I just put this summary together.
Mr Tappy worked well as the camera mount and solved the problem of a camera mount. I’d still keep looking for a higher resolution camera than the iCubie though.
I’d also keep my eye out for a better media player solution. In fact, as I was putting this post together someone recommended SecuritySpy to me. Despite being made for a different purpose, looks like it would do the trick for a small license fee.
Otherwise, here are some of the approaches I’ve found that other people have used.
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.
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.
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:
- 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.
- 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.
- 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:
- 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.
- 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.
- State the design problem presented.
- Discuss the values, attitude, and approach you brought to the design problem.
- Describe your design process and the major discoveries and ideas you encountered along the way.
- State the parti, or the unifying concept, that emerged from your process. Illustrated this with a simple diagram.
- Present your drawings (plans, sections, elevations, and vignettes) and models, always describing them in relationship to the parti.
- 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.
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.
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.
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.