Skip to main content

Interaction Design: the Neglected Skill

Your product development organization has a big, gaping hole in it. (Be prepared to feel defensive as you continue reading.)

One of the most important roles in product development is the role of interaction designer. An interaction designer designs how the users will interact with the product and conceptualize the tasks they perform. He decides whether, for example, the user interface will be command driven, object oriented (clicking on objects then specifying what to do with them), or wizard based. The interaction designer decides the individual steps in the use cases.

Every company has one or more people that play the interaction designer role. Usually, those people have little or no expertise in interaction design. Sadly, they typically don't even realize how unqualified they are.

Let's see who typically plays the role at companies.
  • Engineer. An engineer is an expert on building what is designed. Yes, an engineer may know how to design the internal structure of the hardware or software, but such skills don't guarantee any expertise in interaction design.
  • SME. A subject matter expert is an expert on the concepts in the domain. What about such expertise entails any knowledge of what it takes to maximize a product's usability? In fact, SMEs often have a skewed perception of usability, as they are expert users, not typical users.
  • UI designer. User interface designers know how to lay out a screen. They know the best place to put the buttons, what size font to use, whether to use a drop-down menu or a list, and how to make it all look sharp. But interaction and sequencing is a different matter.
  • Product manager. A properly-cast product manager is an expert on the problems, users, and buyers in the market. Understanding users is important, even essential, but it doesn't by itself entail any expertise in designing a product to be usable to them. A product manager frames the usability metrics, but doesn't necessarily know how to achieve them.

It's certainly possible that a person playing one of these roles just happens to possess user interaction design skills. And in a healthy, productive organization, some people are flexible and play multiple roles. But realize that, to the extent people playing these roles are qualified user interaction designers, it is a coincidence.


Mat said…
You are absolutely right.

There are many good applications that effectively meet the functional requirements necessary to provide value to customers. However, they could be great, and command a stronger market share, if more effort was applied in the area of Usability and Interaction Design.

Why aren't these areas considered a differentiator by more software companies, and funded more regularly? In some companies, this is likely one of those arguably key positions that gets lost between departments.

Interaction design appears to be taking off a bit more in the online consumer space. For example, the iPhone has driven the development of many online "applications" that conform to the existing interaction design of the iPhone and therefore increase the ease of use for consumers.
Cindy said…
It's not just a potential differentiator - it IS a money-loser for most companies.

Poor interaction design and poor end-to-end execution cause customers to delay installations and to put more demand on your support teams and QA staff. Those barely-satisfied customers are not good reference accounts.

The tricky part is that it's not a band-aid solution. You don't get much gain from throwing some interaction design in after the fact (or by hiring a junior person and having them report TO prod management.) Empowered conflict and involvement from the start is key.
Unknown said…
IA is one of those roles that adds a a ton of value to an organization and its products.

That said, a lot of organizations don't have them, and even in those that do, they are frequently overallocated.

For those reasons, product managers are often called upon to be amateur IA's -- either in the rough draft stage or perhaps play the role entirely, for some or all projects. For that reason, it's a good idea to get some background in the basics and perhaps even some formal training.

Some good resources here: IA Links from the University of Minnesota, Duluth and here: The Information Architecture Institute.

I'm not suggesting it's a substitute for having access to a full-time IA, but it's the next best thing.

Moreover, as a product manager if you have a grounding in the basics of IA, you will find you can have better conversations with IAs you work with, just as having a basic grounding in code or marketing can help in working with people in those roles.
Unknown said…
BTW I just realized that on my reply I was conflating the terms "information architecture" and "interaction design." My mistake - they are not the same thing.

That said, the resources on IA are still useful, ID professionals usually have a good grounding in IA, and it's useful for a product manager to have some knowledge of the basics of both IA and ID.
Joe said…
Nice comments and nice post.

I would encourage you to hire interaction designers to do the work. Check out to engage with the more-than-20K members of the Interaction Design Association. You just missed the IxDA conference in February, but you can go next year to Dublin ;)

Also check out and for information architecture information, resources and ideas. Consider attending the Information Architecture Summit in Denver this month:

IxD and IA are key components of user experience design. UX includes but is not synonymous with user interface design as well.

UX is about researching actual users as people, not as market segments. UX is about discovering user goals and then defining tools that meet those goals...not shoehorning users into meeting business goals.
Unknown said…
I agree completely with this, Roger. I work hard at trying to make sure people understand that design and function are only half the challenge of the site or application they are developing. If the Interaction Design has not been considered properly, it leaves people confused, frustrated and, in the end, cause them to leave with a bad taste in their mouth.

A hurdle I find is that content/product owners (the person that owns the final deliverable - eg the client) has to be sold on the benefits of something so abstract as how a person uses the product. Part of the challenge is that, unless you work in a research and design company where this is the norm, it has not been the norm to do these studies. The budget owner can see this as an unnecessary expenditure. However, doing the study shows the weak points and strong points of the product and can help to determine if it should be preserved, pivoted, or dropped, and in the end can save much wasted money.

One of the best books that walks the walk while talking the talk is "Don't Make Them Think". Psychology weighs heavily into how and if a person will stick around to use the product.
Roger L. Cauvin said…
Darren, thanks for the comment! Yes, there are:

1. The problems the product solves.
2. The look and feel and UI aesthetics of the product.
3. The internal design and architecture of the product.

Unfortunately, many people don't understand that none of these things are interaction design. Consequently, they aren't likely to hire someone with expertise in it or dedicate the resources to evaluate and improve it.

I have Steve Krug's Don't Make Me Think on my bookshelf, but I'm embarrassed to admit I haven't read it. On the other hand, I'm a lowly product manager. I don't pretend I'll ever be an expert on interaction design :-)

Popular posts from this blog

Why Spreadsheets Suck for Prioritizing

The Goal As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way. What Should We Prioritize? The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri  makes an excellent case for a " problem roadmap ", and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize - and in what situations - is interesting and important but beyond the scope of this blog entry. A Sad but Familiar Story If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet. I've done it. Some of the mos

Is Customer Development Pseudoscience?

The “Science” of Lean Startup Lean startup practitioners embrace the scientific method, seeking the "truth" about what business model and strategy will lead to product success. We do so by: Formulating hypotheses Crafting and running experiments to test them Learning from the experiments Iteratively feeding our learnings back into revised hypotheses Sounds pretty scientific, at least in spirit, doesn't it? Yet this process actually neglects a key ingredient in the scientists' mode of operation. To identify what’s missing, let’s examine “customer development”. Customer Development Steve Blank is one of the pioneers of the lean startup movement. He introduced into the lean startup lexicon the term “customer development”. Customer development consists of sessions and interactions with customers to test hypotheses. For example, a product manager might interview a prospect, asking if she agrees with the product manager’s hypotheses about the problem