Goals bridge your current and future state. The trick is to differentiate goals and objectives, the direction and the feature.
Last March at the IA Summit, Christina Wodtke grabbed myself and Livia Labate for a quick discussion about how information architects can better interface with the business. The interview is up at Boxes and Arrows.
Information architecture, like business analysis and enterprise architecture, is a discipline of framing and alignment that ensures an organization’s parts work together.
On the IA Institute members's list, Christina Wodtke asked about the difference between information architecture and information retrieval. Margie Coles had the answer: wayfaring.
You can see similar suggestion in the shift from task-centered design to goal-directed design, and from goal-directed design to message-driven design. The ACM Ubiquity article, "Why features don't matter anymore: the new laws of digital technology", approaches the same topic. (Message is how I define the the other, oft-missing, part of the mental model.)
Via Gene Smith, the gallery page for the NID Gallery uses an interesting interface navigated with your mouse's scroll wheel. Very intuitive and easy to use.
When you move your mouse towards one wheel or the other (towards people or works), that wheel grows larger and the other wheel shrinks, optimizing the workspace based on the user's preferred mode of navigation.
Enlarging the wheel provides great feedback and makes the individual wheels easier to use, but having the mouse indicate focus can cause problems. I noticed when I moved the mouse out of the way to look at something, the system interpreted this move as choosing one wheel or the other.
Lesson: sometimes the mouse indicates user focus; other times it's in the way.
Innovation is a quality of any product. When people speak about innovation, they really mean successful innovation.
This year's most important concept: relevance.
Relevance is everything.
You measure success by how much an innovation improves the relevance of a product for the user.
It's taken me some time, but finally, a loose, fuzzy, foggy thought crystallized for me and explains why I've been so preoccupied with business literature.
Design Thinking, Big UX, and Strategic IA predicate their necessity on their positive impact on an organization's performance. But no one's actually connected Design to success within an organization's ecosystem.
I have a friend that says "when in Rome, hump a Roman". I've always enjoyed his witticism, partly because it better describes exactly what Romans do, and what you should do if you really want to... enjoy... Roman culture.
You have to get dirty, and you have to get dirty the way the Romans do.
For enterprise IA, big UX, and design thinking innovation peddlers, getting dirty means you speak the language of business, and not just a few trendy acronyms. You should be able to point to commonly recognized performance indicators and draw a clear, bright line from Design's process.
Better management processes are the most efficient ways to improve an organization's performance, so how does design thinking facilitate better management processes?
I'm still clarifying my thoughts, but design thinking seems to impact management in three clear areas:
Design thinking helps leadership clarify and refine organizational goals; Design thinking crystallizes vision and culture.
Design thinking helps organizations understand their competitive advantages and unique operational strengths; Design thinking crystallizes strategy and process.
Design thinking helps organizations innovate execution and fulfillment; Design thinking crystallizes tactics and products.
(You'll note I'm tying back to MIG's trailmarker.)
But where's that bright line? It's still fuzzy. I feel like design thinking is more connected to management processes. I feel like I understand what I do a little better, and how it improves an organization (why I do it), but the direct link, the smoking gun, the statistically quantifiable data points, the quarry's blood trail is still ephemeral.
But less so. Not only am I in Rome, finally, but I'm speaking Latin, and I've got some pick-up lines.
Some suggest the rise of cocreation reflects some new quality of the emerging age (of creativity, of dreams, of imagination). (From Co-creating unique value with customers):
The traditional system of company-centric value creation (that has served us so well over the past 100 years) is becoming obsolete. Leaders now need a new frame of reference for value creation. In the emergent economy, competition will center on personalized co-creation experiences, resulting in value that is truly unique to each individual.
However, co-creation is not a new frame of reference. Cocreation is the fundamental function of culture. What is new is the speed and the fidelity at which cocreation can occur. Response systems allowing co-creation are a natural facility of human social networks, but technology has increased the speed with which individual customers can respond, and the speed with which creators can iterate and publish to the network.
The quality of iteration is also better because the fidelity with which the response and iteration can be transmitted is higher. By contrast, in the 1860s, if you live in Portland and purchased a rifle built in Kentucky, then disagreements you and other wide-flung consumers might have could conceivably make their way back to the creator, but it would take a long time. Likewise, it'd be next to impossible for the creator to immediately retool. More likely, changes requested by consumers would make their way into the design of the next item.
This delay is probably true (for now) for all physical objects. In fact, you can probably corrolate both quality and frequency of iteration against an object's cost of production.
Using the 1860s example above, if you disliked a song you heard, and your dislikes made their way back East to some minstrel who sang the song, then it's possible the song could change the very next time it was sung.
Regardless of silly examples, culture guarantees cocreation. Culture ensures cocreation even if time required to communicate responses and/or iterations can take longer than one generation.
That's kind of cool.
(Related thoughts in another post here: "Making things and telling stories: two ways we share experience")
Dan Klyn has a great new blog up and running, Wildly Appropriate, that discusses a bit about information architecture. Refreshingly, (at least for me) he spends some time talking about online commerce.
We've been throwing around bencharking as a way to communicate the value of user experience in a concrete manner. "When Benchmarks Don't Work", an article from Working Knowledge, suggests benchmarks may not always be the best way to go (and sometimes may be the worst).
Benchmarking certainly has its virtues. Comparing production time or the cost of a standard process to that of peer companies can yield important insights about your own efficiencies—and ultimately, competitiveness. But benchmarking also has its limits. When you ignore the differentiated output that internal support or shared services groups provide, such straight-across cost or numeric comparisons become meaningless.
Typical task flows illustrate the user’s behaviour as they flow through a process, but they do a lousy job showing the behaviour’s context.
Once a user participates in an event, the user evaluates their expectations of the event with their realisation of the event. This point, where the user tempers their expectations with their realisations, we call this point experience.
However, before the user will participate in an event, three factors guide their participation:
What does the user want?
How do they try to achieve that want? What’s their course of action?
What do they expect to happen?
These actions happen in a chronological sequence: one, two, three.
The user has an idea about something they want or need.
They have an idea about a course of action, and
They have an expectation that this course of action will let them fulfill their want or need.
I find it useful to envision this as a conversation.
The user has an idea for something they want. This is their goal. Since this is an idea they have, we’ll illustrate this as a lightbulb.
In a conversation, they think of something they can say that will get them closer to this thing they want. I call this “message,” so we’ll use a dialogue bubble to represent this.
Finally, they have an expectation of what will happen. I’ll use a stack of coins to illustrate what the user expects to receive.
An expectation can’t be formulated without a message (course of action), and the message (course of action) can’t be formulated without the initial goal. We can illustrate this by expressing our sequence of events as a simple equation:
The goal, message, and expectation constitute the user’s mental model. All of this takes place in the user’s mind, so we’ll finish things up by placing it all inside a thought-bubble above our humble little user’s head (his name is Ulysses Xavier).
The user’s mental model is an important aspect of user-centered design. But user-centered design’s chief conceit is that it’s not about users, but context, and not only the context of use, but the user’s mental context.
The user’s mental model describes the mental context, but we still don’t have the full picture. The mental model operates in context with both the event the user participates in (a conversation, driving a car, browsing a website) and the user’s personal information space (see Dan Brown’s diagram of personal information spaces). The personal information space is a nebulous cloud of facts, tidbits, and rules the user leverages to choose goals, devise messages (courses of action), and formulate expectations.