Mythic Design

by:   |  Posted on

When I agreed to teach a twelve-week course on user experience design, I did what anyone of us would do: I went to find something to copy. I trolled the articles and syllabi I could find online, and I was horrified. Sometime in the years between Jesse James Garrett’s lovely diagram and his incendiary demand that a room full of information architects, content strategists, and interaction designers rebrand themselves as user experience designers, user experience design had grown small. Jesse’s diagram starts with strategy and finishes with skin. His elements of user experience include deciding what to build, and how it looks. Yet the user experience designers I found were the wireframe people.

The wireframe people are designers who don’t design. They don’t make mental models, or do card sorts, or task analysis. They don’t write specs, and they certainly don’t do graphic design! They carefully do a collection of wireframes they then hand to “the designer” who hands it to the engineer. And the engineer, if he’s lucky, has a product manager who did all the interaction design work in the specs. And if he’s less lucky, he does it himself. No wonder many engineers view everyone except the graphic designer as essentially useless. Too often, they are. The wireframes people often call themselves user experience designers.

And forget stealing syllabi! Everywhere I looked classes taught Omnigraffle and touted the wonders of wireframes. No wonder the world was filling up with wireframe people.

So, to paraphrase the Grinch–who I was feeling like–“If I can’t find a user experience designer, I’ll make one instead!” I had a template in my mind of what I thought a user experience designer should look like. I had seen a new generation of designer I liked and hired every time I could.

They were medium-agnostic, code-fluent, and user-centered. They didn’t draw hard boundaries between information architecture and interaction design, and they flowed easily from task analysis into interface. When they did make wireframes, it was on whiteboards in conversations with engineers or as sketches in notebooks to clear their heads. I think of them as Mythic Designers because they would have been called unicorns by the specialists.

But even if these designers are rare, they do exist, just as family practice doctors still do in a world of cardiovascular surgeons and neurologists. These generalists do everything pretty darn well. They make good sites. They might not be the best people to call on if you had to build a Photoshop or a New York Times; complex interaction or massive content stores deserve the special skills of interaction design and information architecture. But if you are a startup, and you can hire one person, you want a real user experience designer. Just as when you don’t feel very good, you just want a doctor who can help.

But I was naive. You can’t make someone capable of designing a user’s experience in twelve weeks. I almost killed my poor students as I pressed five hours of lecture on interaction design into two, pounding them with conceptual models and use cases, activity-object models and task analysis. I knew I was teaching a foundations class and I would do nothing justice, but I kept trying. They wanted to learn Omnigraffle, I said no. They wanted to do wireframes, I told them wait. A student said, “I have never gone this long without designing anything,” and I despaired. They had designed task flows, use cases, site maps, conceptual models, and the basic social structure of their projects; and they thought they had designed nothing?

And then she said, “I’m so glad. We never get time to get our heads around our projects.”

And I got hope. I relented. My TA is going to run a workshop on Omni. I’ll teach them the fundamentals of interface design next week, in the guise of wireframes. Perhaps I’ll even start teaching them one way of doing something instead of three.

It has made me think that maybe the wireframe people wanted to do good design. And maybe they were given so little time to work, it was all they could do to choose between a multiple select list and radio buttons. And maybe they just needed to be taught some thinking tools and classic techniques. Perhaps what they really needed to be taught was to have faith in themselves, so they would demand the time it takes to make something worth making.

Ten years ago, they’d have been called web designers. In a sane world, we would have called them product designers. They chose their own name, user experience designers. And we old farts who have been designing forever need to help them, so they all can be called Mythic.

Whither “User Experience Design”?

by:   |  Posted on

Like a lot of folks, I find the term “user experience design” awkward and unsatisfying, at once vague and grandiose, and not accurately descriptive of what I do. Too often it seems like a term untethered, in search of something — anything — we might use it to name. And yet I often call myself a UX designer, and have done for the last few years, because at the moment it seems to communicate what I do more effectively to more people than any other term I can find.

Obviously I don’t stand alone in finding the term useful, or at least useful enough. Yet we find ourselves endlessly discussing this and and other terms for what we do … trying to describe what we do … disagreeing vigorously … and at the same time complaining about getting mired in an argument about semantics. Can’t we just get on with the work?

I don’t think we can. We cannot get past this argument about language just yet because I don’t think we really have an argument about language. We have an argument about what we do, a genuine and profound disagreement.

Looking at where the term “user experience design” comes from, and how we actually use it, I have a proposal for what we can take it to mean: design which includes interaction design but is not only interaction design.

People who think of interaction design as just one among many UX specialties may consider that a surprising overextension of that specialty’s relevance; I hope to show why it makes sense.

Trouble with the definition, not the word

I don’t much care which words we ultimately choose. Yes, it would help to use language which no one could mistake or confuse, but we cannot seem to find that and don’t strictly need it anyway. Consider the ugliness and inappropriateness of the term “industrial design.” We understand it not because it suits what industrial designers do, but because we already understand what industrial designers do and can attach the name to that generally understood meaning.

In “user experience design,” we don’t have that. We lack a clear meaning to which we can attach the term. Until we find one, the grumbling over names will continue.

Grandiose UXD

Some people like the grand implications of the term “user experience design.” They include anything where one plans what experience people will have, including not just websites but interior decoration and customer service scripts and theme park rides and kitchen knives.

I feel uncomfortable with the language of “user experience design” because I don’t think we need a name to describe all of those things. At that point, why not just “design”?

Looking back at how we came to talk about UXD in the first place, that large world of design problems didn’t give rise to talk of “user experience design.” The web did.

The web gave us UXD

The term “user experience design” came as a response to the shock wave created by the emergence of the web. For most people in the field, “user experience design” means, in practice, “design for the web … and other stuff like it.” So what is the web like?

Some people with a background in graphic design tend to think of web design as visual design plus a bunch of other Design Stuff. For a long time, a lot of web designers made a binary distinction between visual design and information architecture, effectively defining IA as “all the Design Stuff for the web which isn’t visual design.” These days, most define IA more crisply than that, distinguishing between information architecture as the organization of content and “interaction design” as … well … that gets a little tricky.

For some web designers, I suspect “interaction design” represents the frontier of web design as IA once did; having accounted for visual design and information architecture, “interaction design” means, in practice, the design on the web which ain’t either of those. Others have a more specific conception of what constitutes “interaction design.”

Interaction design

Over in the software development universe, people have long discussed “usability engineering” and “human factors” and “user interface design” and a host of other names for the same essential work. All of those terms have their problems: philosophical, rhetorical, political. You can locate me in the era and tradition I spring from by knowing that, in circles where I can expect people will understand me, I still prefer to call myself an interaction designer rather than a UX designer because I consider it a more usefully precise term.

When one encounters a computer, or a device, or any other system which has software in it, one enters into a dialogue with that system, a cycle of action and reaction. This includes both cycles of action between individuals and the system itself, and also cycles between different people as mediated by the system. Inter-action: action between people and systems, action between people and people. Systems containing software involve categorically more complex interactions than anything else we make, which gives those systems a unique character that calls for a distinct design discipline. Hence “interaction design.”

Back in the late ’90s the term “interaction design” got tangled up rhetorically because traditional advertising and design agencies used the term “interactive media” to describe the brochure-ware they made for the web.

More recently, many people have taken “interaction design” to mean only the pick-and-shovel work of wireframing and specifying workflows, not the fundamental product or service definition which lies behind the specific interaction behaviors.

Once upon a time I wanted “interaction design” to become the term which included all of this work defining new interactive systems. Things didn’t go that way.

Disciplinary distinctions

Interaction design. Information architecture. Visual design. Information design. Social interaction design. Service design. We have people who find these disciplinary distinctions very useful, believing that they represent well-defined types of work with reasonably well-developed methods. We have people who see talking too much about these distinctions as territorialism and semantic games that get in the way of just doing the work. Some among those have a deep skepticism that these distinctions mean much at all: compared to the classical disciplines of graphic design, industrial design, et cetera, we do not — and perhaps can not — have well-established methodologies for the new problems which designers face today. They talk in terms of a kind of open-ended design sensibility and developing an eclectic toolkit of specific techniques.

We should not minimize the differences between these philosophies. When we do, the disagreement displaces itself into discussions of language. Rather than ask what “user experience design” really means — a question with no answer — we should ask instead what problem we use it to talk about.

“User experience design” creates an uneasy truce

The term “experience design,” originally proposed by people who rejected disciplinary distinctions, has acted to paper over the disagreement.

These early advocates saw “experience design” as a way to name a new era in which the old disciplinary distinctions between design problems had broken down and become less relevant. They talked excitedly about UX design in its grandiose sense.

Then Jesse James Garrett drew his famous diagram of “The Elements of User Experience,” name-checking several different classes of design problems and suggesting a way of looking at their relationships, writing “user experience” in large letters on the diagram as a name for the whole. People who valued disciplinary distinctions could look at the diagram and see them represented there. People who wanted to transcend disciplines could look at the diagram and see the implication that each lived as part of a greater whole, incomplete on its own. So that diagram exemplified conversations which brokered an implicit truce under the banner of “user experience design.”

But we still need to understand and talk about This Thing That We Do, and we still do not agree about it. If UXD means “Designing Stuff like the web” we have to ask what we mean by “like the web.”

Interactive systems, not just the web

The 800-pound gorilla that is the web confuses our thinking. Web-ness per se did not produce the need which gave birth to the term “user experience design.” It didn’t come from people making simple websites with static pages, it came from people making web applications. And now we see it adopted by people making desktop software and mobile apps and more. What do those have in common? The network? Static websites involved the network … and we also see people talking about UX design for stand-alone desktop computer applications. So no, the network does not unify these UXD domains.

Software ties these things together. The Thing The Web Is Like is software, and in fact that statement says it backward. Better to say many things derive their nature from software, for example the web. What makes software special? What makes it different from the artifacts created with industrial design? From the images created with graphic design? From websites of static pages?


More than just interaction design

One might call this focus on interactivity chauvinism on my part, since I come from interaction design.

Let me underline that I do not claim that interaction design constitutes the most important component of all UXD. Let us recognize service design and information architecture and visual design and social interaction design and all the other specific design disciplines we employ in solving UX design problems. Indeed, let us notice that in many cases other design disciplines outweigh the importance of interaction design in solving a UXD problem.

One may have a big retailer’s website and mainly need information architecture to organize the vast set of pages and visual design to make the pages appealing and aligned with the brand, with just a little bit of interaction design for the search and purchasing tools. One may have a member service process for an HMO which involves sophisticated service design and classical graphic design for communicating to members and just a little bit of interaction design for things like appointment setting tools.

I don’t want to make interaction design dominant over UX design but I do want to name it as essential to UX design. The presence of interaction design usefully defines “user experience design.” The term “user experience design” did not emerge from an encounter with the need for service design, information architecture, visual design, social interaction design, or any of the other problems we talk about in the UX design world. It emerged from the encounter with complex software behaviors and the interaction design challenges they present.

It makes no sense to ask what “user experience design” really means; it means whatever we use it to mean. We can ask what we need it to mean and how we already use it. I submit that we need a term for “designing systems that include interaction design”. And we already use “user experience design” to mean that now.

If we could agree on that, I might stop feeling so bad about calling myself a “user experience designer”.

The Past and Future of Experience Design

by:   |  Posted on

Ten years ago, when I wrote The Making of a Discipline: The Making of a Title, 2002, there was a big debate on: Is experience design about online and mobile interfaces or is it something more? Forward-thinking initiatives, like the AIGA’s Advance for Design, began the conversation at the center of the convergence of the media, technology, and business worlds. Started by Clement Mok and Terry Swack, and supported by Ric Grefe, this group of people met periodically for several years to talk about the changes in the above industries and how to both manage and communicate them. (See: AIGA Experience Design – Past, Present and Future ) Even then, the term “experience design” was controversial and, while it became the name of the professional group that evolved out of this effort–AIGA Experience Design, the term was dangerously close to being limited to designing digital products such as websites and mobile applications.

There has been a reluctance for designers to embrace the idea of experience and I’m not sure why. Every single person involved with the Advance for Design and AIGA ED was someone who sought-out and appreciated experiences in his or her life, whether in theater and entertainment, quality customer service, or any type of real life event. Yet, many didn’t feel comfortable taking on the idea that we were creating total experiences in a professional context (as opposed to digital interfaces and media only). I remember near knock-down, drag-out fights online and in person over whether experiences like great meals, spectacular events like Cirque du Soleil, or retail experiments like Target’s pop-up shops could teach interaction and visual designers lessons in making better experiences (and whether these physical-world experiences, too, belonged under the umbrella of experience design).

To tell the truth, this desire to limit experience design to the digital world always puzzled me, especially given the rapid rise of experience dominating the branding profession (resulting in the, now ubiquitous, term brand experience) and the retail and hospitality industries (today, we call this service design). Brand professionals woke up to the fact that branding was more than the application of a corporate or brand identity. Before interactive media reminded them that brands had been interactive all along, most of the work in brand strategy, design, and management was focused on identity standards and packaging design. Interactive media forced the conversation that reinvigorated this entire profession (in addition to all media and business) and recast many of these professionals as visionaries and strategists, when before they were mostly regarded as “design Nazis.”

It just seemed ludicrous that experience could only live in the narrow world of digital media when it was already so vibrant in all other media.

There was another debate at the time, as well (and maybe this describes the reluctance to embrace experience design I referred to earlier), one that seemed even more ridiculous: Can you design experiences for people? Many in the community argued that there was no way that we could design (read: control) experiences for such a wide variety of people. By this, I understood that they meant that we couldn’t design experiences that others would move through in the exact way that we imagined, and that we could not evoke personal memories in order to trigger emotional and deeper reactions in order to feel something we intended. And, if this was to be the definition of delivering experiences, perhaps they were right. Or considering the movie Ratatouille, if a rat can, maybe we can too.

At the same time this conversation was going on, Martha Stewart was building an empire by helping people create better, more meaningful weddings and dinner parties. Weren’t her customers learning something about creating experiences for others? When we went to theaters or great restaurants, were we ready to proclaim that 1) these weren’t experiences or 2) we couldn’t teach people to make moving theater or meaningful dining? Plenty of people were saying the same thing about websites. The film and culinary worlds would have laughed at our reluctance (had we bothered to consult them and bring them into our community). Perhaps they would have branded us cowards.

I believe the term (and industry) of experience design narrowly dodged a bullet that almost killed it in 2001 or 2002, collapsing under the weight of its own self-importance. It was a big fish in a small pond. For the most part, the only people calling themselves experience designers back then were in the digital fields. Even though we worked with clients and colleagues who were engineers, branders, business strategists, marketers, and chief officers of everything, we were afraid to color outside our own little box of the Web.

Two important things happened at the turn of the century; the dot-crash and the rise of mobile. Perhaps if the Web had continued to rule, the term “experience design” would have probably faded into interface design. This is useful and important work, certainly, but how can button placing compare to shaping an experience that might inspire joy, giddiness, and empowerment? But instead we’ve grown in our power and insight into User Experience Professionals… to the point when a major professional organization renamed itself.

Humans have always created experiences for others: i.e. birthday parties, weddings, films, theater, art, speeches, hospitality, and more. Whether they were deliberately designed as experiences or not, they all delivered experiences. When the experience isn’t considered but works nonetheless, we chalk it up to intuition or good luck. Or we could end up with a bad experience. That’s not a desirable, or professional, way to work in the world.

Considering experience as we design is not that new. Louis Cheskin, probably the first experiential marketer, was researching experiences (including emotions and core meanings) back in the 60s. Walter Dorwin Teague, probably the first experience designer, was designing experiences across media despite never being trained to do so (if you can get a copy of his book, Design This Day, you can read how and why).

From Shedroff's excellent SXSW presentation on scifi's influence on designIt’s also arrogant to believe that we can’t learn from theater or retail or any other human domain how to improve the things we design and deliver. In my own professional experience, I’ve learned lessons from my colleagues and friends in medicine, sports, music, and especially theater. I’ve learned valuable lessons about interaction design from improv, biology, and even science fiction. I’ve learned about color, lighting, and music from, yes, Cirque du Soleil. I’ve learned about designing emotionally, and developing meaningful experiences from psychology. I’ve learned about systems design and stakeholders from sustainability. In fact, in the world of sustainable systems, we learn from nature itself.

Lately, I’ve been learning about how to develop and deliver better experiences more effectively over a larger timeline from the music composition and gaming worlds. I don’t understand why it was once deemed illegitimate to look to these sources for ideas, inspiration, and useful lessons. But, perhaps it’s moot now, as it no longer seems to be an issue and new generations of designers simply aren’t interested in this controversy.

So let’s move on. Let’s have more discussions about where we’re going. Experience design seems pretty stable, both in its scope and practice. We’re constantly adding to the knowledge and developing new tools to express the development and delivery of experiences to all involved with their creation. We’ve come a long way in ten years, sure, but every day environmental and biological sciences push forward our understanding of human behavior and the world we live in. This means we have new discoveries of how to design amazing experience still ahead of us . Designers need to learn more about designing sustainably, humanistically, and systemically. We need to further refine our techniques for design and customer research, enlarging our understanding of people past emotions and into values and meaning. We shouldn’t be afraid to go in these directions. Designing new experiences in new ways has a higher risk of failure, but also a higher risk of reward in greater impact and behavioral change.

Lastly, we need to better understand business language, issues, and concerns. To have the influence we think we should, we need to enlarge the solutions we create so that they can operate effectively in the economic and political systems of business. Experience isn’t just something that gets imagined and designed. It gets funded, delivered, and managed. This is one of the reasons I earned my own MBA and then started a wholly new business program for those interested in leading innovation from the inside. Experience design is just one more system we need to understand to work professionally and to successfully develop and deliver better products, services, events, and environments.

The future of experience design has never held more promise. But, to fulfill this promise, we have to explore, learn, and work passionately and confidently—even courageously, at times—in new domains. The things we create aren’t usually any less ephemeral than the experiences they deliver (how many websites or campaigns or apps or events have you created in your career that are no longer available?). What lasts, at least in the minds and reactions of our customers, are the experiences around these things. Ultimately, this is also where we derive our own greatest satisfaction in our work. It will be what makes us smile when we think of a project we worked on, years from now, and instead of focusing on how we created it or how much we earned; we will fondly look back on the experiences they created for people.

Leaping Into Indie UX

by:   |  Posted on

Show Time: 33 minutes 40 seconds

Download mp3 (audio only)
Download m4a (with visuals, requires iTunes, Quicktime, or similar)


Podcast Summary

In this episode Chris Baum speaks with Donna Spencer, Lynne Polischuik, Justin Davis and Erin Jo Richey at the 2012 IA Summit about their interactive panel discussion Taking the Plunge: Diving Into Indie UX. They share practical and personal considerations of being an indie designer, including how to to get over the fear of making the jump, where and how to find clients, managing the business side of design and what it’s like to work alone.


“When you first start this you are really insulated…when I looked back it in the first six months to a year I didn’t make any money! When you’re in that initial phase you’re really excited… I think if you looked at it objectively you’d never do it.”

“I spent three years working my butt off to have all of the buffers in place… if there’s no work there’s no backup second income. It took a good couple of years to get enough money in the bank… where I could finally start to relax and say no to work knowing other things would come up and not kill me.”

“I got pushed out of the nest with a reasonable size contract.. and I was OK for a couple of years but I look back now on projects I took on that now I never would have taken on… taking on the wrong clients, taking on the wrong projects… I got to a point recently last Fall where I asked am I happy is this where I want to be?”

“I have been an independent for just over a year now… I had joined the agency that would come in as an analyst and then transition to an Information Architect. We decided that they didn’t want to take the agency in the direction of UX or IA and we talked about the role within the company… I didn’t want to focus on the same types of marketing … I did get laid off but I didn’t have a backup plan put in place.”


Thanks to “Vitamin Talent”: and Morgan Kaufmann’s “It’s Our Research”: for sponsoring this podcast.

And thanks to “ASIS&T”: for their support of the “IA Summit”: and this podcast.

How to Win Friends and Influence People Remotely

by:   |  Posted on

Living in Australia and working with team members based in the US and India, discovering ways of being more effective in my job, has become a bit of a hobby. However my situation is not unique. Knowledge workers are increasingly required to work in a distributed manner – in some cases this is working specific weekdays from home, in other cases it involves close interaction with team members spread across continents. Please note this is a rapidly changing area, even in the time between writing this article and its appearance on B&A many things have changed.

Outsourcing (mainly to India and China) and reductions in travel spending due to the recession has lead to more and more distributed teaming. Add to this the reduction in cost and increased availability of broadband, working from home, or moving to Hawaii is increasingly an option both requested by employees and agreed to by employers (in my case Surfers Paradise).

Once remotely located a designers ability to interact with other team members and effect change are funneled through the telecommunication mediums that the team uses to communicate. This article lists the available mediums and analyzes their respective strengths and weaknesses and provides suggestions for their effective use.

Real Time Voice

We have three main types of telephone service: landline telephone service, mobile, and VOIP. Working out which to use, when is not as straight forward as you would think.

Landline phone

A landline telephone in concert with a conference calling system forms the backbone of a distributed workers ability to communicate with team members in real time.

While many thought the introduction of mobile and VOIP would reduce the importance of landlines, in many ways the opposite has been true. Mobile disappoints as a medium for clear communication, and wide adoption of asymmetric broadband systems has in many cases hamstringed VOIP to be as a complete replacement for landlines.

A mobile phone connection has less audio fidelity than a landline, and it has a habit of dropping out or breaking up at the most inopportune moments. In one case in India, mobile providers limit conversations to 60 minutes – requiring tedious re-login to calls that spill over the hour. Added to this, the temptation for calls to be taken in inappropriate places – bars, restaurants, the shopping mall etc. – is too much to resist.


VOIP services on the other hand are a mixed bag. Sometimes the audio fidelity can be of almost CD quality. On the other hand intermittent breaking up of the audio stream and the occasional dropped line can make them more unreliable even than mobile connections.

In my experience, current standard residential DSL and Cable IP services (at least in Australia) do not provide enough upstream bandwidth to allow both a VOIP and web conference sessions to run concurrently without some congestion issues. Of course if you are on the receiving end of a presentation it is not so much of an issue. However when you are the presenter (when it is critical that you communicate clearly), the bandwidth associated with your presentation and your voice stream invariably results in your voice breaking up giving others on the call a bad experience.

Conference Calling Tips

  • Make it a rule not to use your mobile for conference calls unless it is unavoidable, and then make sure you pick an appropriate place to take the call. Defer your turn to present – if at all possible – to when you are close to a landline.
  • Stay off your VOIP line when your presenting unless you have wide (1 megabit or greater) upstream bandwidth
  • Before the call – be sure to provide a agenda for all conference calls
  • Web conferencing – if a web conference is going to be part of the call include the connection details along with the agenda
  • After the call – be sure to send out minutes by email to provide a written reference of call results.
  • It makes sense to invite all call attendees to a group chat session. This can add significant value to the conference call by:
    • providing transparency as to who is currently on the call
    • cueing upcoming presenters
    • managing questions

Asynchronous text

The value of offline text communication is unquestioned. To date this type of communication has occurred primarily using email services, but a relatively new kind of service called “groups” is becoming more popular among distributed teams – for good reason.



  • Ubiquitous – everybody has and knows how to use it
  • Mature – email clients both desktop and web based are feature rich


  • Overuse – important messages get lost amongst the less important
  • Spam – filtering sometimes removes important messages
  • Attached Files – not a good storage solution and file sizes are limited
  • Address book – requires send to, cc and bcc to be managed manually



  • Membership – access to content and automated notifications is limited to group members
  • Suite of service scoped by project– depending on the provider a group offers an array of useful services:
  • threaded messaging, polling, calendar, file archive and link manager
  • One place to go – by centralizing all offline communications a single repository is now available for members to access all recorded data associated with a project
  • Updates – Users can decide what areas of the group they wish to receive notification of updates on and how they are delivered (each update, once a day, once a week etc.)


  • Relatively unknown – groups of all the mediums discussed in this paper have the smallest user base
  • Member management overhead – this is not required if email is used as the primary offline communication tool
  • Usage enforcement overhead- for a group to be effective its usage needs to be enforced

Email while a very useful tool for general communication, is increasingly less effective for teams working closely. Important messages are being overlooked in increasingly large inbox or in some cases removed by aggressive filtering.

Groups can add value to project teams by centralizing all offline communications and automating the notification of updates. Well known implementations include: Yahoo Groups, Google Groups, Basecamp, and Microsoft SharePoint. It must be said that while groups are great for distributed teams they are only effective if strictly enforced as the primary offline communication medium. In situations where members are mixing communications up between email and the project group their value is significantly reduced.

Offline Text Tips

  • Assign a group master at the beginning of each project who’s tasks will be to:
    • create and name the group
    • create and manage team member enrollments
    • create and manage file archive and link folder structures
    • enforce group usage
    • moderate message threads
  • Use standard email subject schema (Project Name : Message Context : Action Description). This allows your team members to more efficiently pick which of your communications they should read.
  • Write conclusions and actions at the top of the message. Don’t bury important content deep inside or at the end of a long message.
  • Keep the airways clear. Email chains on frivolous topics clog inboxes – do not contribute to them if you can resist it.

Real Time Text

Real time text — or chat —is becoming more recognized as a useful business tool. However with the good comes the bad.


  • Less intrusive – more immediate than sending email but less intrusive than a telephone call. Chat is an excellent way to informally communicate with an individual team member.
  • Ubiquitous – almost everybody is familiar with one or more of the popular chat clients
  • Team status – if everybody in the team is on the same chat client it can provide a single place to view the “online” status of your team


  • Distracting – overuse by individuals can detract from work focus
  • Service dependence – while consolidation is occurring, there are still a number of firewalled chat services.

When not over used chat represents an excellent medium to promote informal communication between team members. Chat has been described as the virtual equivalent of the water cooler conversation. This kind of communication can promote innovation as well as go a long way to improve bonds between distributed team members.

Real Time Text Tips

  • Stay logged in – make it a point to log into to your chat client when working
  • Status indicator – always keep your status indicator current, giving your team immediate transparency to your current accessibility
  • Manage your contacts – be sure to create logical folder groupings for all of your chat contacts. This will give context when contacts you don’t often converse with reach out to you.
  • Don’t use file transfer – stay away from chat based file transfers they are slow and unreliable. Use the project group or email instead.

Web Conferencing

Web conferencing, has gone from a nice to have, to a must have for many organizations. In fact in the case of usability research it is the now the norm for user testing of product prototypes. It is not long ago when web conferences were special events organized for clients. Nowadays most calls that involve design issues have a web conferencing session. This is true even with only two parties on the call.


  • Visual stimulus – when integrated with a conference call, a web conference can show presentations, mockups, and other documents.
  • Other services – Commonly bundled services include: polling, white board, agenda, meeting minutes, chat, and meeting audio/screen recording.


  • Single sign-on – as is often the case separate authentication is required to enter the web conferencing system. Very few systems integrate phone, web and group functionality, current systems often require users to login multiple times.
  • Browser dependencies – many web conferencing systems require specific platforms and browsers
  • Bandwidth intensive – presentations rich in graphic/photographic material can over tax bandwidth resources causing audio and visual lag between presenter and viewers.
  • No standard interface – it seems every web conferencing system takes a unique approach to its user interface, making it difficult for users to transition between different systems
  • Screen size dependencies – some systems do not cater well to different screen resolutions between conference presenter and viewers.
  • Expensive – web conferencing systems are expensive to subscribe to, buy, and maintain for individuals.
  • However this is changing rapidly with Powerpoint to flash conversion tools and built-in screen share facilities such as those found in Skype and iChat.

Web conferencing is a major boon to distributed teams. As the market for these services matures we will see big improvements such as integrated video cam capture, audio recording, speech to text by current vendors as well as the emergence of new extensions to chat and VOIP clients which traditionally have been free.

Video Conferencing

In the past, video conferencing required expensive dedicated systems. Web based video streaming and integration with popular chat and VOIP services has started to change this. However to date the use of real time video as a business communication tool has been low.


  • Visual cues – in a one to many situation a head and shoulder video stream of the presenter can provide viewers visual cues missed in conference calls
  • Relationship building –in a one to one situation being able to see the person you are interacting with increases you’re ability to communicate and bond faster


  • Bandwidth dependencies – video streams are bandwidth intensive
  • Client dependencies – many of these services are tied to chat/VOIP providers that require specific platforms and browsers
  • Small user base/Low take-up – the value add of person to person video in a design context is still tenuous. This however may change when functionality arrives to enable three or more video streams to be viewed concurrently.
  • Immature culture – the fledgling nature of this type of communication means there is very little culture in acceptable behavior.

Video Conferencing Tips

  • How you look influences peoples perception. As such how you light your face, what you wear, and the background behind you are all factors that should be considered when using real time video for business purposes.

Real time video brings marginal value to distributed teams. At this time it could be described as a nice to have, especially in situations where bandwidth is scarce. In the future it may become more important especially if integrated into web conferencing systems where the presenter’s video stream is included in the web conference stream.