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 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.

I had the pleasure of presenting on Finding time for Design within Agile software delivery.

Unfortunately, it’s rare to have a dedicated Copy Writer on a team unless the product is either content heavy or marketing driven. Largely the duty of authoring all those small but important bits of text tends to fall to the User Experience Designer and Product Manager/client when creating and reviewing wireframes.

In the worst-case scenario it gets left with the Devs to do when they are building pages. In this case instructional text, error messages, field labels, etc. end up sounding like the have been written by an emotionless robot. This is not a slight aimed at the English skills of my technically minded colleagues, but more a reality of what happens when copy is produced as a by-product of writing functional code.

Recently a colleague of mine, Meaghan Waters, shared a set of content writing guidelines, which had previously been shared with her by an old colleague, Amy Teshio.

It has some great tips and reminders on how to write compelling content. I found it so valuable and helpful that I had to share it here as well:

Clear, Compelling, Concise

Like most things in life, good writing is about thinking and feeling:

• If you can think clearly, you can write clearly.
• If you are passionate about what you have to say, your text can be compelling.
• If you can be dispassionate about how you’ve said it, your text can be concise.

Some tips:

Believe in your message.

Trusts its value. Let it speak for itself. Tell stories. Know when to move from information, to story, to visual rendition, back to information, etc. (or consult with others).

Get it down on screen/paper, then revise.

Let the flurry happen. Put it aside and come back with fresher eyes. Consult with our editorial team. Give yourself enough time to draft, consult, revise. Writing is different from editing. Don’t try to do them simultaneously.

Edit, edit, edit.

Remember, just because you are reluctant to give up a particularly nice word, sentence or paragraph doesn’t mean the reader will miss it. If you are having trouble giving it up, copy it to a separate file and make it your own buried treasure.

“Vigorous writing is concise. A sentence should contain no unnecessary word, a paragraph no unnecessary sentence, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.”
William Strunk, Jr., The Elements of Style

Vary your sentence length.

Mix up the rhythm. It keeps it interesting and sounds less robotic.

As a general rule, a good sentence contains one idea.

If you have another idea to convey, start a fresh sentence.

Find your voice and stay with it.

Know your audience.
Voice should reflect subject matter.
Use the appropriate tone:

• Formal vs Casual
• Serious vs Humorous

Use active verbs. Avoid “to be” constructions and the passive voice.

No: The white iPhone is preferred by generation Xers.
Yes: Generation Xers prefer the white iPhone.

Stay close to the idea.

Don’t put too many qualifiers between you and your message. This attempt to be conscientious will only confuse the reader. Readers don’t retain ideas that are in remote locations.

Don’t say “perambulate” when you can say “walk”.

Avoid jargon. Use the simple, reliable work. Good writing is not so much a matter of using unfamiliar words, as using familiar ones in unfamiliar ways.

Watch stuff like:

Three factors of influence versus three influences.

When talking to different participants, paper copy remains a critical component of the way they manage day-to-day information.
But note: paper copy didn’t do the talking to the different participants.

Avoid passive voice/double gerunds.

No: The e-binder concept form was seen as a way to provide a format for organizing sharing.
Yes: Participants see the e-binder as a way to organize the sharing of information.

Why learnings instead of lessons? Why around instead of about?

General UX books

	The Design of Everyday Things, Donald A. Norman *most often recommended A classic read from one of the gurus of UX. This is my favourite book to recommend to people who are just starting to understand and appreciate the importance of UX. It highlights the amount of design that we encounter and use on a day-to-day basis without ever noticing – which is a sign of successful design. After reading this you’ll never look at door handles the same way again.
	Emotional Design: Why We Love (or Hate) Everyday Things, Donald A. Norman Don Norman’s follow up book which shows the journey he went on as a designer, where he went from focusing primarily on aesthetics/form to appreciating the impact that emotions and psychology have on the way we experience design.
	The Elements of User Experience: User-Centered Design for the Web and Beyond, Jesse James Garrett This is best, most straightforward explanation I’ve found that can articulate the difference between Interaction Design, Information Architecture, Visual Design, UI Design, and how all this hangs together to create a website.
	The Inmates Are Running the Asylum, Alan Cooper When it was first released this book challenged the common approach to design as being something that was done in a token way after the engineers has done all their hard work. This once pioneering book has now become a bit dated in my eyes. Not because it is any less relevant, but just because there are very few companies that don’t at least nominally acknowledge that user experience is important. Whether they do anything about it is another matter. It’s still a worthwhile read, but nowadays it just feels a bit like it’s stating the obvious.

Usability

	Don’t Make Me Think! A Common Sense Approach to Web Usability, Steve Krug *most often recommended The is the classic book about web usability and how easy it can be get it right if you approach it the right way. A must read for anyone starting to get it to UX, and best of all it can be read in an hour or three.
	Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems, Steve Krug *most often recommended The companion book for Don’t Make Me Think that is the best step-by-step guide to conducting usability testing you’ll find. Krug’s basic point is it really is straightforward and anyone can do it. This books shows you how easy it can be. This quick to read book will leave you ready to start conducting tests that day.
	Web Form Design: Filling in the Blanks, Luke Wroblewski This is the book that I am the most thankful that someone took the time to write. Luke W. does a great job of answering the questions about how people use web forms. While he rightly doesn’t give any absolutes about what is the best layout, he provides research based insights to understand how all the little details, such as label placement, affect usability and can be applied. They seems like such small details, but anyone who has designed a web form knows just how important these details are…and how much time can be spent debating them.

Design

	Universal Principles of Design: 125 Ways to Enhance Usability, Influence Perception, Increase Appeal, Make Better Design Decisions, and Teach through Design, William Lidwell & Kritina Holden & Jill Butler A comprehensive collection of general design principles and concepts that can be applied equally across the various design disciplines. It covers anything from Gestalt principles, to colours, and storytelling. If you want to add some theory behind how some design patterns work, this reference does a great job of explaining all the concepts with visual examples.
	Designing for Interactions, Dan Saffer A good general overview about what Interaction Design is, how it works and how it fits in to the overall design landscape from one of the better known Interaction Designers, Dan Saffer.
	Thoughts on Interaction Design, John Kolko An intellectual look at the emerging field Interaction Design and how it can make a difference. John Kolko is one of the more inspiring Interaction Designers out there. He ties design theory in to making a practical difference.  It provides some great challenges and food for thought for experienced IxDs.
	Envisioning Information – Edward Tufte Tufte is one of gurus of information design and visualisation. This beautiful book uses historical examples from all over the ages to explain the subtle nuances of communicating information when designing maps, diagrams, data sets, etc.
	101 Things I Learned in Architecture School, Matthew Frederick Some great design food for thought. UX design shares a large amount of knowledge, principles and practices with Architecture. There is a lot we can learn from this well-established discipline. Similar to the Universal Principles of Design above, this book captures some general principles that can be applied to lots of different areas.
	Getting it Right with Type: The Dos and Don’ts of Typography, Victoria Squire Good typography is a key element in any kind of design work. Having a good understanding of how it works is something that everyone can benefit from.

Strategy & Planning books

	Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers, Alexander Osterwalder & Yves Pigneur The Business Model Canvas is one of the most useful tools you can find to help drive and inform product strategy conversations.
	Subject To Change: Creating Great Products & Services for an Uncertain World, Peter Merholz, Todd Wilkens, Brandon Schauer, David Verba A great book on the changing nature of business and how to produce innovative products. Focused on the strategic side of business.
	Rework: Change The Way You Work Forever, Jason Fried & David Heinemeier Hansson This captures the essence of start-up culture and how to work effectively in small teams. For people working in large bureaucratic organisations this can seem like a fantasy-land utopian state, but a lot of the mindsets and approaches can be adopted regardless of where you work.
	Zag: The Number One Strategy of High-Performance Brands, Marty Neumeier If you need some inspiration about how to think outside the box and be different in your product strategy, this book helps outline how to embrace an innovative mindset.

Human Behaviors

Flow: The Psychology of Optimal Experience, Mihaly Csikszentmihalyi We all experience being in-the-zone, a.k.a. the flow. Some of us try to design for it, but few people really understand the psychology behind how it works. This captures the insights of someone who has dedicated years to understanding it.

Agile

	Agile Experience Design Lindsay Ratcliffe & Marc McNeill Another book that falls in the category of books that I’m glad someone took the time to write. Fellow ThoughtWorkers Lindsay and Marc have put pen to paper to capture the approach and techniques that we use to experience the benefits of going Agile.
	The Toyota Way, Jeffrey Liker One of the must reads for anyone looking to learn more about Lean and Agile practices.

Tools & Techniques

	Designing for the Digital Age: How to Create Human-Centered Products and Service, Kim Goodwin A great reference book and how to guide for the UX/Interaction Design process. It covers everything from project inceptions, through research, prototyping, and on to detailed interaction design. Not something you’ll read from cover to cover but great to be able to refer back to when you need to figure out/remember how to do something.
	Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers, Dave Gray & Sunni Brown & James Macanufo For anyone who runs a lot of workshops or activities this is a great resource. The games themselves are useful for inspiration, but it is worth reading just for the first chapter that explains the structure and mechanics of how games work.
	This is Service Design Thinking: Basics – Tools – Cases The first book to be written that is dedicated to Service Design, it gives a good overview of what it is all about, the tools and techniques used, and some useful resources/templates to help get started with it. It’s also a beautiful example of information design in itself.

Research methods

	Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics, Thomas Tullis, William Albert If you want to tighten up your research methodology and back up your findings with solid stats, this shows you how to do it.
	Observing the User Experience: A Practitioner’s Guide to User Research, Mike Kuniavsky A great capture and explanation of the tools and techniques in the UX research toolbox.
	Mental Models: Aligning Design Strategy with Human Behavior, Indi Young Mental models are one of my favourite tools for communicating research findings and human behaviours. A simple, but effective tool this book will show you to create them.

Sketching/Prototyping

	Sketching User Experiences: Getting the Design Right and the Right Design, Bill Buxton *most often recommended Bill Buxton of Microsoft fame outlines the philosophy behind sketching and prototyping products. He highlights that value of exploring ideas with sketching and prototypes before launching in to the more costly build phase. It’s also filled with great case studies.
	The Back of the Napkin: Solving Problems and Selling Ideas with Pictures, Dan Roam A great guide for anyone trying to improve the use of their sketching skills as a facilitator. It’s not so much a how to guide for drawing, but more a way to help visualize and explain problems.
	Prototyping: A Practitioner’s Guide, Todd Zaki Warfel A good overview of creating and using prototypes. It’s main focus is an in-depth review of the prototyping tools that were around at the time of it being published, full of great tips and techniques on how to use them.

Design Blogs that I read

Some good user experience/interaction design/information architecture/graphic design blogs that talk about tools, techniques, resources and challenges:

• Box and Arrows
• Smashing Magazine
• UX Matters 
• Johnny Holland Magazine 
• Core77 
• A List Apart 
• UX Magazine 
• 52 Weeks of UX 
• Wireframes Magazine 

Well known people’s blogs

Future Perfect – Jan Chipchase
Jan Chipchase was once described to me by one of his colleagues as the ‘Indiana Jones of the design world‘. He’s been conducting international ethnography research for many years now. His blog is generally a collection of photos and thoughts from all over the world. Great for remembering that there are other countries and cultures out there. He makes me jealous of his experiences, but grateful for being able to regularly sleep in my own bed.

Jacob Nielsen’s Alertbox
The blog from the self-styled ‘guru’ of Usability. Jacob Nielsen was one of the pioneers of web usability and has been preaching about his research findings and usability guidelines for years. While he can be criticised for focusing on a very narrow view of user experience and placing no value on design (his unchanged website design has been proof of this for years) he does still come up with some useful research based insights from time to time.

User Interface Engineering Brain Sparks
Another celebrity of Usability, Jared Spool has been blogging and talking at conferences about usability and interface design for years. This blog is a thinly veiled marketing vehicle for UIE conferences and seminars, interviewing industry experts about topics that they are about to present on. However, this doesn’t stop its articles and interviews from being worth listening to.

Good Experience
A blog from Mark Hurst who has been blogging about customer experience, user experience, human experience since before UX was called UX.

Ask ET
A discussion forum about Information Design, hosted by Edward Tufte, the guru Information Design.

Cooper Journal
A blog about design, business and the world we live in from the company that bears the name of Alan Cooper.

I’ll be talking about Finding time for the creative exploration process within Agile software delivery which I blogged about a while back.

It’s exciting to see Agile UX becoming a mainstream topic and being given it’s own conference. Plus it’ll be exciting for me personally, as it’ll be my first time talking at a conference.

Hopefully I’ll see you there.

There is of course a necessary overlap between the skills-sets in these roles, which is a good thing. And some individuals have a broader coverage of skills than others. However, people outside of these roles don’t always appreciate the specialist skills and focus that is required to work within them.

This as simply as I can describe the different skills required for each role:

• User Experience (UX) Designer = Research + Design
• UI Developer = Design + HTML/CSS/JS
• Application Developer = Back-End coding + HTML/CSS/JS etc.

As much as I’ve tried to avoid it, I just haven’t been able to prevent myself from creating a Venn diagram to visualise this.

These different combinations of skills bring with them a different perspective and focus on what each person does.

UX Designers combine their research and design skills together to understand the user needs and produce concepts/solutions/designs that people want to use. This requires a focus on human behaviours, psychology and understanding why people do what they do. It’s all the soft squishy, creative stuff on the right-side of the brain.  Most UXers can tell you what it should do and why it should do it, but can’t actually build something that works.

Application Developers (which is a very broad and hopefully inclusive term for your average technical skill set) build the underlying functionality which makes the product work. It’s all about code, logic and the left-side of the brain.  Often heard from Developers is “I can make it work, but it won’t look pretty“. Meaning that they can craft HTML that will technically work, but it may not create a very good impression for anyone who is influenced by the look of it (which means your average end user).

UI Developers fill the middle ground by combining both design sensibilities and technical skills together. They are skilled at making something both look good and function in a browser/device at the same time. They have the production skills to be able to produce visual designs in Photoshop and then turn them in to HTML code that deals with the wonders of browser compatibilities.  This requires in-depth understanding of how browser rendering engines behave to be able to implement a design for the web that renders correctly and get all those pesky pixels to line up perfectly.

Of course this is very much a generalisation and it is possible to find people who work effortlessly across all these different skills-sets. I need to make the caveat that every person has different strengths and weaknesses. My point here is about the commonalities that define UX Designers, rather than each individual’s unique differences.

There is an age-old discussion out there on should designers know how to code? which often ends up concluding that ideally, yes they should. However the kind of people who can effortlessly switch between focusing on code and user needs are a rarity. The mindset required for each is generally quite distinctly different. Most people just aren’t wired up to do both. At the very least, even if they can, switching between them in their day-to-day role on a project tends to hinder their ability to do either well.

Breaking down Design further

Of course this is very much a simplification of the four areas covered in this diagram Research, Design, HTML, & Back-End. With just one wave of a Venn diagram I have lumped an entire technology industry in to just one circle. 

At the risk of complicating the main point of this post, I do feel the need to break down the area of Design a little bit more as it’s the area that I feel most non-Designers struggle to understand the differences between the design disciplines, and the different the backgrounds that UXers come from.

Within the context of Software Development, I would argue that design is primarily all about Visual Design, Interaction Design & Information Design.

It has to be said that the line between these three design disciplines is very blurry and rarely possible to separate entirely (the best way I’ve seen them articulated is in Jesse James Garret’s JJG Elements of UX).

This is how I would expand my diagram and the roles to include them:

To further expand the distinction between the roles:

• UX Designers focus on the structure and layout of content, navigation and how users interact with them. These don’t normally (but can) try to be perfect from a visual perspective. The types of deliverables they produce include site-maps, user flows, prototypes and wireframes, which are more focussed on the underlying structure and purpose of the software.  The visual appearance does impact on these, but can be created as a separate layer that is applied over the top.
• UI Developers focus on the way the functionality is displayed and the fine detail of how users interact with the interface. They produce the visual comps and functioning front-end code. This is very much about polished final production quality outputs.

The other role that I added in to the expanded version of the diagram is the Graphic Designer. It’s worth calling out that there are specialists who tend to work solely in Photoshop to produce static visual comps. This starts to talk to the area of illustration, fine arts, print media and the more creative stuff. Traditionally within web design this was a separate role, but not so much any more. Within software design the majority of people tend to have developed technical skills to become a UI Designer/Dev.

The different disciplines within UX Design can be expanded further to paint a much more comprehensive picture. The best way I’ve seen it articulated was put together by Dan Saffer in his book Designing for Interaction. He represents the different disciplines of User Experience Design like this:

If you start thinking about designing experiences across different platforms, devices and contexts then you very quickly need to bring in Industrial Design, Architecture, etc. But that’s a blog post for another day.

What I find interesting about the whole discussion is that at university I studied a Bachelor of Social Science with a major in Applied Policy & Social Research.  Of which research techniques and statistical analysis were a core component. Yet as a practitioner working in (semi) related field, I’ve pretty much forgotten how to do a T-test – and yet this hasn’t created any problems.

What this highlights to me is the difference between UX Design and HCI. Or to put it another way, the gap between practitioners vs. academics. This isn’t meant as a rant for or against one or the other, it’s just a personal reflection on how I see the UX Design field is evolving to become more lightweight and lean.

What constitutes UX research and the way it is structured greatly depends on what the project is and what you are trying to achieve out of it. There are a multitude of different tools, techniques and approaches out there. For instance, evaluating a design by conducting usability testing to identify problems is a significantly different scenario from conducting field interviews to discover user needs in the first place, or again from getting statistically sound stats to make a business case about how you should proceed with a particular product/feature.

When planning research the first thing you should start with is asking: What do you want to know? Why do you want to know it? What is the project goal?

After that you need to ask questions like: Are you discovering or evaluating? What tasks/questions should be included within interview sessions? How many participants do you need? What data do you need to collect? This helps guide what type of methodology is suitable.

Then of course you need to consider: What is your time and budget? How closely the team is collaborating? How much documentation do you need to produce? Are your findings going to be challenged?

A lot of UXers put an emphasis on statistical analytics. I find this interesting, mainly because I’ve rarely had the chance to get to the numbers of participants needed to make it possible.  Looking back at my 10 years plus+ personal experience I have rarely engaged in anything other than qualitative research, with just some basic stats thrown in.  It’s always good to triangulate you’re findings from different data sources, but it’s not always feasible.

I’ve found this trend becoming stronger over time.  With most of my recent projects, I’ve worried less about a formal methodology, and focussed more just having an open and engaging conversation with the research subjects.

I see this as both a good and a bad habit. After some thought, here’s my justification/list of excuses of why this has been become the case:

• #1 = time. Traditionally I’ve had to start from the position of negotiating hard for any kind of user research to be factored in to a project in the first place. Let alone, being able to take the time to cover more participants. Based on practice I’ve learnt to become more and more lean (for both participants and outputs) so as not to hold up development much more than necessary. The biggest challenge I’ve usually found is to move away from an older waterfall mentality where UX research needs to be thorough and can become a hold up in the process. To me good design research can be done in a way that is iterative and just-in-time within development.  This approach wouldn’t be considered sound academic methodology, but it is highly effective for software development.
• Budget. Working as a consultant, it can be hard to convince clients to spend their precious money on comprehensive research, particularly when you know a lot of research can be done more efficiently if it’s not going to be submitted for peer review.
• Archaic technology. Unfortunately, I’ve been conditioned not to expect that tracking tags will be implemented properly to allow accurate traffic reports to be produced.  This is changing thankfully, but there are still too many legacy systems out there that can’t give meaningful analytics on users behaviours.
• I want to know Why, not just What. I’ve always started with researching the qualitative goal of finding out why people behave why they do. Probing further in to how many people behave that way doesn’t usually happen as understanding why proves to be enough of an insight.
• Usability issues don’t need to be statistically valid to exist. Other than confirming that someone isn’t an outlier, if 2-3 people have a problem with something then it exists as a problem. Usually that is all I need to find out with a design – what problems exist with it. When you’re busy iterating a design, the ball is in your court as a designer to find a solution for it.
• A background in websites, not software or physical devices. The level of fine-tuning of performance that can be achieved by statistical analysis is traditionally rarely a priority on the web. Unless you work on a site that gets such high traffic as Google, Amazon, BBC the return on investment for more thorough research hasn’t been there. The traditional focus has been more on issues such as implementing global style guides and redesigns, rather than refining them. But then maybe I just haven’t stayed at the one place long enough to get to that. Alternatively, if you’re about to start mass producing a physical gadget, it’s worth taking the time to fine tune it a little.
• My own laziness. Producing results that will hold up to academic rigor is time-consuming hard work. For whatever reason, I have been able to get away without putting in the hard yards to cover the participants and do the statistical analysis. While I have no doubt I could improve research techniques (and have been trying to of late), it is a result of my experience. Chicken or Egg? Maybe either/both.

As part of this conversation a fellow ThoughtWorker shared this design spectrum.  It’s a great way to articulate the different approaches that can be taken.

I guess I tend to dwell on the intuition-driven end. It’s good to get some perspective.

Now, I’m going to go home and rearrange my reading list so that Measuring the User Experience and Observing the User Experience  are on top of the pile.

I find the deck that we use to be a very handy tool, both for planning a project, but also just to formalise and explain the UX activities that we use which can often be somewhat abstract to people who’ve never done them before.

Unfortunately, as much as I’d like to, I can’t share the ThoughtWorks Inception cards themselves. Essentially they are tool which contains all the various activities, both UX and Technical, that allows us to map out the steps/activities we’ll take within a project. The concept as a tool is nothing new, but the content is considered to be our special sauce as it were.

A while back I invested in physical copies of a whole lot of these while I was looking in to defining UX methodology frameworks. Too be honest, I haven’t used any of these in anger during an actual project, but they provided lots of food for thought about what what I would put in a set of my own if I found the time to create them. I also love owning a physical set of these. Not only does it help to give more weight to some of the UX things we do, some of them are beautiful tactile objects I just love to play with (particularly the Oblique Strategies which come in a nice embossed box).

Roughly, the following decks fall in to three different categories:

• Research Techniques
• Design Activities
• Design Inspiration Challenges

SILK Method Deck

The SILK method deck is a handy collection of methods, principles and prompt cards, which can be used by project teams, designers, project managers, social science researchers, community and economic development experts alike.
http://socialinnovation.typepad.com/silk/silk-method-deck.html

Design with Intent: 101 Patterns for Influencing Behavior Through Design

The intention is that the cards are useful at the idea generation stage of the design process, helping designers, clients and – perhaps most importantly – potential users themselves explore behaviour change concepts from a number of disciplines, and think about how they might relate to the problem at hand.
http://architectures.danlockton.co.uk/2010/04/10/design-with-intent-toolkit-1-0-now-online/

Oblique Strategies

In 1975, Peter Schmidt and Brian Eno created the original pack of Oblique Strategies cards, through thinking about approaches to their own work as artist and musician. This deck contains over one hundred “worthwhile dilemmas.” Each card presents a question, dilemma, or new way of thinking about the work you are doing. The cards provide a number of options for thinking of problems from different angles.
http://enoshop.co.uk/oblique.asp

IDEO Method Cards

IDEO Method Cards is a collection of 51 cards representing diverse ways that design teams can understand the people they are designing for. They are used to make a number of different methods accessible to all members of a design team, to explain how and when the methods are best used, and to demonstrate how they have been applied to real design projects.
http://www.ideo.com/work/method-cards

nForm UX Method Cards

The sets first came out in 2007 at the IA Summit. Jess McMullin created a deck of 16 cards that show methods, deliverables, and ideas that practitioners can use to design great user experiences.
http://nform.com/tradingcards/

Mental Models

In the midst of a busy project it’s all too easy to forget the nuances that distinguish great products. Mental Notes brings together 50 insights from psychology into an easy reference and brainstorming tool. Each card describes one insight into human behavior and suggests ways to apply this to the design of Web sites, Web apps,and software applications.
http://getmentalnotes.com/

Design Thinking Bootcamp

The guide outlines each mode of a human-centered design process, and describes a number of methods which may support your design thinking throughout the process.
http://dschool.typepad.com/news/2010/12/2010-bootcamp-bootleg-is-here.html

Gamestorming (Technically this is a book and not a et of method cards but it achieves the same end)

We’re hardwired to play games. We play them for fun. We play them in our social interactions. We play them at work. That last one is tricky. “Games” and “work” don’t seem like a natural pairing. Their coupling in the workplace either implies goofing off (the fun variant) or office politics (the not-so-fun type). The authors of Gamestorming, have a different perspective. They contend that an embrace and understanding of game mechanics can yield benefits in many work environments, particularly those where old hierarchical models are no longer applicable, like the creatively driven knowledge work of today’s cutting edge industries.

http://www.gogamestorm.com/

More reading
Here’s an article outlining some of these – http://uxmag.com/design/ux-ideas-in-the-cards

To do this you need to break out of the mindset of UX generated designs being a ‘final deliverable’ and instead view them as a ‘communication tool’, which facilitate a step in the process rather than being an end point.

Prototypes in the world of UX

A prototype is ‘working’ interactive version of a concept that anyone can try, understand, and see how it would work. They provide a proof of concept that can communicate the solution in a concrete and tangible way. A prototype can be anything from a piece of paper folded a particular way, through to a clickable and polished simulation of a product. The most common UX prototypes are a usually series of static pages linked together.

Their key benefit is that they are low-cost to produce (compared to production code) and can be tested with real users to ensure that the concept and value proposition meets the target audiences’ needs. They can be iterated and improved quickly to get the concept right before more costly development begins.

Prototypes are a communication tool

It is important to consider prototypes (especially lo-fi ones) as a way of communicating a concept, not a final deliverable that is handed over. They never showcase the complete working functionality and usually require some form a narrative to be told when testing/presenting them.

Rather than trying to replicate the entire end-end functionality (that would make them the finished product), prototypes focus on demonstrating the key user journeys through the product, telling a narrative of what the user would experience and how the interactions would work.

With this narrative, they can be a very powerful tool, without it they can become confusing. They can’t just be thrown over the wall to a Dev to build. They need to be part of a conversation about what the experience should be. They work at their best in a collaborative environment.

I see them as a key step in moving from a Waterfall to an more Agile UX approach where there isn’t a hard handover point between design and development, but instead an ongoing conversation and collaboration.

Prototypes vs Functioning Code

There is always a healthy tension between how much effort should be put in to producing prototypes in non-production tools as apposed to just jumping in to coding up a real world working version.

I believe that the sooner that you get to code the better. It is after all the actual medium in which the product will live. And you can never truly test the actual real experience until you see how it will work for real. As much as I love playing around with paper and post-it notes, they are only a stepping-stone to get to the real coded version. And once you get to code iterating and refinement becomes far more efficient.

However, more often than not projects jump into code too soon, before they have tested, validated and tweaked the underlying value proposition.  Once code has been written these concepts become far harder and more costly to change.

As soon as code has been written it becomes an asset, making it far harder to throw away. In the early stages of creating a new product concept or just playing around with a new piece of functionality, lo-fi prototyping tools provide a great to play with ideas and explore different approaches, before one gets locked and set in to IT concrete.

Prototypes vs Wireframes

There is a gray area between what is a prototype vs wireframe. Although they are both created using the same tools and can use the same page content, there is an important distinction between the two:

An example of a wireframe describing and annotating what the experience will be. A prototype would demostrate how this would work in interactively which just can't be demostrated on this static page.

• Wireframes focus on comprehensively capturing the page content and structure.
• Prototypes aim to demonstrate the interactivity and journey through a product.

Wireframes function more as a requirements document, which can be used for getting stakeholder sign-off and then be passed on to Devs to build from.  Despite being more comprehensive, they are far from the best way to showcase the experience.  Prototypes are able to demonstrate interactively and visually what the experience will be like, whereas wireframes can only describe the experience. This is not to say that wireframes don’t have a place or aren’t required, but they have a different purpose.

Choosing a tool

Prototypes can be made using many different tools, all of which have their various benefits. These are some of the common tools used for designing user experiences:

The general dilemma when choosing a prototyping tool is which level of fidelity to work in. The general pros/cons are:

The choice of prototyping tool selected should be based on the level of user experience that is being addressed.

If the product solution is new and the underlying concept/proposition is still being developed, then a lo-fi option is always best to begin with. The deliberately sketchy nature of lo-fi tools removes any focus on detailed page design and instead puts focus on the value the solution provides to users. It instead focuses on what should we build, not what will it look like.

A lo-fi sketchy styple prototype made in Balsamiq. This was made early in the process to test the concept before much time had been put in to design..

A hi-fi visually poished prototype of the same page, made in Omnigraffle. This was made later in the process after rounds of stakeholder input and usability tesing.

Once the solution has been confirmed as the right idea to progress with, higher-fidelity prototypes will allow for more detailed level testing which can iron out any interaction design and usability issues.

Recommended reading:

• Sketching User Experiences: Getting the Design Right and the Right Design, Bill Buxton 
• Prototyping, Todd Zaki Warfel