An email from on high hits your inbox: the company is kicking off an initiative to "radically improve" the effectiveness and efficiency of its nationwide sales force.
Nothing new here, you think. This sort of thing sweeps over the land every few years, like locusts.
But as you drag the message into your Deleted folder, something new catches the eye. Your design team is being asked to carry out the first step of the initiative: conducting a research project to "gather requirements" for how to make the organization more effective.
Aside from the fact that requirements are defined and not "gathered" (one pictures wine bottles hanging from grapevines), it's surprisingly level-headed to turn to interaction designers to examine organizational needs and propose solutions. Most of the time, it's business analysts and technology specialists who are tapped for these assignments. Analysts collect information about what makes the business tick; technologists, meanwhile, build and/or choose tools that work within a given infrastructure. But while the work of analysts and technologists is necessary, it is not sufficient. That's because they are rarely trained (much less asked) to describe usage contexts, identify goals, or design tools that satisfy people while also meeting the objectives of organizations. The result? Too often it's a new flavor of the same old thing, just more expensive this time around.
Now that your team has been tasked with an organizational design initiative it's up to you to pull it off without a hitch.
Time to start drafting a plan.
Get the right people on the job
The job of interaction designers is to provide pleasure and power to people through the design of products, services, tools, and processes that satisfy their goals. With the discipline of interaction design still in its infancy, some people believe the medium in which we work is pixels. But this is manifestly untrue. On the way to coming up with a design of an artifact such as a sales tool or an infusion pump, we must examine, and often change, the nature of roles, processes, and workflows. True, many of our recommendations are ultimately manifested in software displays and controls with which people interact. But by simply locating a widget on this screen rather than that one, we are profoundly, if not subtly, altering people's perceptions of their work...and often the outcomes as well.
Activities such as describing roles, values, priorities,
business processes, workflow models, domain object models,
toolsets, business rules, and the like are the bread-and-butter
of interaction designers. Sure, you need to collaborate
with others to get this work doneparticularly
the pick and shovel work, as well as change managementbut
interaction designers are uniquely skilled at synthesizing
complex data, resolving contending points of view, and
Measure the right things to define success
Often designers are asked to begin their work with activities such as task analysis and eye-ball tracking studies. However interesting the data yielded by such research, it is time-consuming and often misleading. Partly this is a matter of confusing tasks with goals, while ignoring context. Assigning much meaning to quantitative behavioral studies can be a little like assuming that the guy with the drill in his hand wants to do harm to the woman lying there in the chair. Sure, he might be a madman. But more likely he's a dentist and she's his patient.
Focusing on such measurements is most dangerous when your organizational change team lacks people with design skills. You carry out a task analysis that records how people use CD players, but it will only tell about how people use CD players. It will give no insight into what people like about music. The result of such an effort? Perhaps the design of a better CD player but you're never going to come up with iPod. You just can't get there from here.
So then why do so many people put stock in these methods? I daresay it's because eyeball movement can be tracked and measured. Which is to say, if it can be counted, it must be important. And if the conclusions of the study lead your efforts astray, you can blame the data, leaving your judgment unquestioned.
Moreover, many business and technology managers simply don't believe in the existence of someone with the skills and insight necessary to take a qualitative and creative approach to defining complex problems and designing appropriate solutions. And so they content themselves with incremental process improvements, the unofficial slogan of which is: Change is good so long as it resembles what we're already doing. But an organizational change initiative staffed, in part, by interaction designers can adopt a more productive slogan: Change is good so long as it satisfies the goals of people and the objectives of the organization.
This is no pedantic distinction. The difference between something designed around tasks and something designed to serve human goals is the difference between breaking ahead of the pack and biting the dust of the lead dogs.
Capture what's happening now, then articulate optimal processes
By now, we're all supposed to know that you have to record the baseline before changing everything. Otherwise, how are you supposed to know what fruit your efforts will bear? A great place to start in this case is by interviewing and observing sales folks and the people with whom they interact. You figure out what gets them up in the morning and what keeps them up at night. You find out how they make decisions and how they help others do the same. All of which is to say, you determine the processes, roles, and goals that comprise the organization, and the tools and information sales people use. These interviewsplus some observationwill give you a good understanding of the current state of affairs, and also reveal why people behave the way they do.
Let's take a simple example: say that your research uncovers that sales people are supposed to download a template for collecting information on each new sales contact. Great idea except that nobody's going to use that template unless it works within their context and satisfies their goals (or at least doesn't thwart their efforts). After all, sales people want the sale. That's why they're called sales people. They care little, if at all, about the organizational efficiencies gained by everyone else using an identical template.
Once equipped with insight into people and their organizations, it's time to apply your design judgment. Sometimes that's going to result in better software; just as often, though, it might result in a better workflow. The point is, one can't be considered in isolation from the other. But what business is it of a designer to weigh in on process?
Improving the processes that people are doing is exactly
the sort of thing that interaction designers do best.
In fact, certain kinds of organizational design aren't
merely analogical to the design of interactive products:
they are the same thing. Sure, designing the
perfect mechanical pencil is very different from drawing
up a streamlined org chart. But the reach of an ordinary
pencil is limited by the length of the arm wielding
it, so there's little relationship between the process
for its design and the design of an organization. But
what happens when technology extends our reach beyond
the breadth of our desks? When this happens, the line
between product and process blurs, making it necessary
for the design of tools to conform not only to the shape
of the hands of those using them, but to the shape of
the organizations for which they work. That is why any
initiative aimed at improving an organization will benefit
from the skills and insights of those whose job it is
to design interactive products and services.
Create user personas and organizational archetypes
Once you've done your research, what do you do with your data? The methods used to describe system participants in an organizational change initiative are little different from those used to divine the needs of potential users of interactive products. Most importantly, it's vital to distill your findings into a set of personas that represent the population. You may spend more time than usual stepping them through current processes, with the not-unreasonable assumption that these processes shall persist unless otherwise shown to be inappropriate. Then you step your personas through scenarios that come out of their contexts and goals, while also taking into account likely technical constraints and critical business imperatives. It is from these scenarios that you formulate an inventory of user requirements, then make recommendations for meeting those requirements.
As mentioned above, it is particularly important to take into account the shape and objectives of the organization for which your personas work. That's where organizational personas come in. Like user personas, organizational archetypes are models based upon your research and defined by the patterns you identify. They differ, of course, in that they don't represent people, but rather the environments in which people attempt to achieve their goals. They express mundane things such as annual billings, numbers of employees, divisional relationships, business processes, infrastructure, sales targets, and geographic reach. But they also must express the values of the organization, the management philosophy, the prevalent work ethic of employees, and the over-arching objectives of the organization. The creation and application of organizational archetypes ensure that your user personas are not working in a vacuum, which means that what you ultimately design will make sense.
Stick to your guns
What happens next? The buy or build question must be answered. What's important here is to adhere to your principles and allow personas to guide the efforts of the entire organization.
Equipped with the requirements of users and organizations, it is important to set up collaboration sessions with business analysts, technologists and executives to work out how to satisfy persona goals while also meeting organizational objectives. In some cases a new technology solution can be bought off the shelf. But how do you ensure it won't spawn bigger problems than you're trying to solve? One way is to conduct thought experiments and run your personas through the use of the new tool or system, taking into account their contexts and goals along the way. To the extent the new product satisfies goals and objectives, that's great! But to the extent it can't, plans must be drawn up to satisfy the unmet goals and objectives, or at least to ameliorate the effects of the shortfall.
Sometimes off-the-shelf solutions just can't cut the
mustard, and you must build your way out of the problem.
In the case of new construction, use your personas to
motivate a design that satisfies their needs while still
being feasible and viable; of course, you need to use
your design judgment to guide your hand in selecting
the best possible solution, just as you would in a traditional
product design effort.
Separate design from construction
In big, expensive organizational change initiatives, a conflict of interest often arises between the specification of a solution and its implementation. This can happen, for instance, when a technology integrator has several hundred hungry developers and partners who get sorely tempted to specify a design that plays to their technical strengths. But the beauty of an interaction designer's point of view is that we're platform agnostic: if the solution requires a new ERP system, all right but if better processes can be realized by handing out more pencils and notepads, all the better! An interaction designer's approach must bear this in mind, providing level-headed insight to executives and precise direction to developers, so that the interests of the business and users are kept foremost in everyone's mind.
In the end, opportunities are what we make of them, not what is offered us. Just as identifying the goals of users is the first step to the best product design, the best way to work with well-meaning but ill-informed executives is to help them see the difference between what they say they want and what they really need.