Letter to a Content Strategist
Summary: In which I attempt to clarify content strategy by doing it in terms I understand: my own.
Content strategy is the the kind of thing that loses clarity when I try to look at it directly. I can glimpse it out of the corner of my eye, but attempt to stare it down, it hops away. (You know, the rabbits are just emerging in my neighborhood, so maybe that’s what I’m talking about.)
Information Architects and Content Strategists: Like kids in a sandbox. Kids that don't throw sand at each other.
Anyway, for the last couple years, I kept thinking to myself, if I just take a couple hours to sit and think about this, I’ll be able to nail it down. (Not talking about rabbits any more.) I’m frustrated with the characterization of content strategy as “good writing” or “operational issues.” They are unnecessarily limiting, even if taken in the context of the web. I know there’s a design component here, a newly emergent set of challenges that comes with preparing information to be delivered online.
Content Strategy is Design
Content strategists are designers, just like I am. And like me, the information architect, the “stuff” content strategists design is somewhat more abstract, somewhat less defined than a couple million pixels. But, aside from the composition of content, content strategists haven’t (to my satisfaction anyway) defined what it is they design, what’s the output of their work.
I’m not sure I could do that for my profession either. It took me a decade to be able to say, “Information architects design structures.”
But what I can do is tell you what I need. I can tell you how I’d like to work with a content strategist as co-designers. I need you, Content Strategist Person, to tell me the following 10 things about content:
- Range of priorities: The range of priorities within a given content type. For example, is every press release going to be equally important (or unimportant), or is there a big spread between the most important and the least important press release?
- Algorithmic prioritization: Whether the relative priority among its peers can be determined by a rule, or if a human needs to decide. That is, given a set of five press releases, is there a rule I can reliably apply that will prioritize them? (For example: release date.)
- Inherent prioritization: Whether there is an inherent prioritization between content types. That is, is every press release going to be more important than every white paper?
- Plans for growth: The organization’s plans for growing or changing the content.
- Level of effort: The complexity of the production process for each content type. Which content is hard to produce? Which content is easy to produce? Which content can I count on to always be up-to-date? Which content should be prioritized when it appears, and otherwise remain in the background?
- Metadata authoring: The organization’s capacity for applying metadata, and what’s realistic in terms of populating a metadata framework. We’ll have lots of good ideas on how to link content together, but those ideas probably won’t work unless we understand the organization’s ability to tag the content.
- Metadata parameters: Parameters for different metadata fields. As we’re designing wireframes, let’s be smart about how much text we need to display.
- User needs: The need for transparency to the users about some of the underlying structures. How much do users care about content type? Help me distinguish administrative metadata from metadata that actually contributes to findability.
- Users needs (2): How the content fits into user scenarios. Is this transient content (stuff just to get them just to the next step) or destination content? How will people use the content once they find it? What are you doing to align the content with requirements specified in personas or elsewhere?
- Sample content: Finally, if you want me to put sample content in my wireframes, I’m totally game. Just give me the sample content.
Ultimately, my job is to design structures. These are structures that establish navigation pathways, search frameworks, and business rules for governing how to display information. In order to design those things, I need insight into what you want the content to be, how you want it to behave, and what structures will let the content thrive.
My Promise to You
Far be it for me to make demands without promising something in return. That’s thirteen years of marriage talking. (Who says our personal lives can’t affect our professional ones?)
What I promise to do for you:
- Collaborate with you to establish a content model: a network of categories that classifies content by its function or structure. It’s easier to talk about content by its type, and content type should refer to a predictable format that enables it to fit into a structure.
- Design structures that provide useful and meaningful ways to find content. You can already tell that I think of content as a living, breathing organism with a life independent of the structures I design. I hope that the structures I design align with that behavior, providing an ecosystem that doesn’t get in the way of the content.
- Collaborate with you on determining a metadata framework. Content describes content, I know that. I can think laterally about the content as it uses metadata to draw relationships between it and other information on the site. I help explain the relationships I’d like to see between content to aid in findability and to teach users about the range of content available on the site.
- Communicate the different ways in which I intend to chunk the content. When I say “chunking” I mean the different ways I can expose a composition in the interface. Sometimes I just want the title and author. Other times I need title and blurb. But sites are getting more complicated: more opportunities to chunk, and more things to chunk up. I can boil these opportunities down and create a structure to facilitate the display of content in a variety of situations and scenarios.
- Establish flexible templates to accommodate the nuances of content. As simple as it is to make generalizations about content types, every composition is a different challenge. The templates provide a reasonable starting point, but we need to design them to provide some flexibility, allowing each article or story or posting to
That’s only five things, but I’ve got obligations to my visual designer, project manager, and usability guy.
So, what do you think? Can we work together? What else can you do for me? And what can I do for you?
Much affection,
Dan
A Taxonomy of Constraints
Image from Flickr user @alphageek, licensed under Creative Commons
Maybe it’s just the projects I’m working on, but I feel like I’m using the word “constraints” a lot.
(That sounded a lot more bitter than I intended.)
It’s a word we’ve been throwing around, but experience shows there’s considerable nuance to it. Shining a light on these constraints may help us better understand the boundaries in which we must operate, and help us spell out the requirements for a project.
Nathan is working on an essay about design standards, and he’s taking a more thorough look at how designers and organizations should relate to them. Standards may be a way of dealing with constraints, or a constraint in and of themselves, but there are other pieces to the framework that bear spelling out.
What is a constraint?
Constraints are inputs into the design process that make designers are focused on solving the right problem. The design process depends on exploration and iteration, two things that can take designers further away from appropriately solving the right problem. Constraints allow us to evaluate the output of our design process to make sure we achieved our objectives.
What I’m most interested in, though, is a taxonomy of constraints. What are the specific things that establish boundaries and provide a means for validating design?
User research
Designers who subscribe to user-centered design philosophy prioritize user research perhaps above all others. In short, user research yields a set of expectations–what users would like the product to do. As we produce design ideas, we can compare the idea to user needs. Doesn’t address a need? The idea dies.
Project objectives
Most of my work these days involves designing web sites to meet a specific business objective. Sometimes it’s hard for me to relate the business objective to any other constraints, but that’s the nature of the organizations I’m working for. The project is a small piece of a larger machine. Depending on the piece and the machine, failure of the part may or may not mean failure of the whole. Regardless, these constraints can sometimes seem arbitrary as they serve some abstract objective and not a concrete requirement driven by users.
Project parameters
As much as we don’t like to admit it, there are external (and again, seemingly arbitrary forces) that scaffold the design process. Most explicitly, these are deadlines that confine the range of activities we can perform in order to conceptualize and flesh out a design. Less explicitly, these may be the whims of project stakeholders and other team dynamics.
Technical implementation
Though technologists are fond of saying “We can make it do anything,” the truth is that most design work happens in the context of existing systems. These existing systems come with capabilities and configurations that make some design ideas more feasible than others. The sometimes unsaid extension to the technologists’ mantra is “We can make it do anything with sufficient time and budget.”
Operational implementation
Just as the technology provides a context for a design idea, so too does the organization that will support it. There are people behind every technology, having to provide support in everything from customer help to content updates. Without the infrastructure from an operational perspective, some design ideas will not be successful. To thrive, a design must acknowledge the organization that will support and maintain the final product.
Industry standards
Otherwise knowns as “best practices,” these conventions emerge after withstanding the test of time. Used widely on other web sites, such standards become constraints in so far as they establish a baseline from which other design decisions extend.
Organizational standards
This is where Nathan’s essay will come in. Establishing standards specific to the organization is a complex process with numerous benefits. Suffice it to say that from the designer’s perspective, standards provide a range of starting points for solving problems. Positioning and integration into the design process is crucial: done poorly, these constraints come across as creativity-killers.
Design principles
A good team will summarize their direction in a single theme or collection of bullet points. This direction is specific: “make it easy to use” gets eliminated as a principle pretty quickly, for example, because it isn’t specific to the project and is common to all our projects. Instead, design principles are specific and meaningful to the team working on the project. They are means for making design decisions.
They are, in a sense, a super-set of all other constraints. I didn’t really think about this until now, but teams compose design principles when they want to boil down everything they’ve learned from all the other constraints.
Constraints are good
I don’t know if this–design decisions within a framework of constraints–is the right way to look at design. I can’t imagine Steve Jobs making a list of constraints before sketching out the Next Big Thing. On the other hand, design doesn’t end with a concept. Myriad other choices go into realizing a vision like the iPod. No doubt constraints play a role in mediating these other decisions.
Here’s the thing: I like constraints. They define a design problem. They help me understand what success is. They let me collaborate efficiently with other team members who share an awareness of the project’s boundaries.
Further exploration
Some ideas on exploring constraints further:
- Prioritization: What process do we use to prioritize constraints? Is there a Maslow’s hierarchy for constraints that implies which things are most basic and which are less necessary?
- Distinguishing from requirements: What’s the difference between requirements and constraints? In short, requirements state the problem and constraints are a tool to help me solve the problem. Can the distinction be more nuanced than that?
- Managing conflicts: How do project teams deal with conflicting constraints? Presumably these conflicts are ironed-out at the beginning of the process, but in practical terms, I suspect this does not happen formally until the conflicts arise.
The Well-Structured Email
Summary: Don’t send business colleagues a Wall of Prose. A well-structured email can get you faster responses. This post includes a few tips.
As @periodicdesign might tell you, I’m on a rampage. Having gotten way too many messages with 3-4 paragraphs of dense prose, I decided enough was enough. “Crafting these messages,” I said, “need to have the same care as a client deliverable.”
Unfortunately, I work from home in my basement, so no one heard me. So, I assembled a few tips and sent those around in — you guessed it — a well-structured email. Everyone at EightShapes is now trying their hand at improving the legibility of their email.
General Principles
Email should communicate three things:
- Action: The message should make it clear what I need to do.
- Issue: The message should describe the key issue or problem.
- Data: The message should provide any necessary background information.
Email Structuring Tips
To communicate Action, Issue, and Data, messages should:
Use headers to delineate sections
I use boldface headers throughout the message to distinguish different elements. Typical headers include “Action”, “Summary”, “Background.” I also try to make my headers as specific as possible. While this means that every email might be structured differently, it’s more important to communicate the gist of the message from the headers.
Start with the action item
The first sentence in every message is the main action I expect from the recipient. It’s phrased as either a question or an imperative (“review the attached document”). I try to make the action as specific as possible such that the recipient doesn’t have to read the rest of the message if they’re pressed for time. Examples:
Action: Prospective Client X has a project starting in 3 months time, lasting 6 weeks. We have a prior relationship. Pursue?
Action: We have 20 hours left in the budget for Project ABC. Please consult with client to align remaining funds with scope.
Include deadline
When do you need the action done? Highlight the deadline.
Make recommendation
If appropriate, I include my recommendation or thoughts. Again, I keep this as succinct and as specific as possible. Example:
Dan’s Recommendation: Complete wireframe for screen X and await feedback from client before starting visual design.
For some reason, I always include my name. I think it saves the recipient a step: “Who’s this message from again…?”
Summarize message
Sometimes, I need to include a lot of information in the message. Rather than eliminate information, I’ll summarize the situation. I tend to use 4-5 sentences of prose for this, since I’m trying to paint a picture. This summary appears toward the beginning of the message (between the action and the bulk of the email), labeled “summary”, and lacking some specifics.
Whether people read it or not, it’s a useful exercise for me to make sure I can relate the situation succinctly.
Use bullets for sub-topics
Bullets are the bane of slide presentations, but very useful for email. After a new header, I’ll break the topic down into its key points. My bullets tend to have a leading phrase in boldface that provides an overview of the point. Example:
Client has concerns about direction
- Heavy-handed menus: The navigation mechanisms encroach too much on the content area.
- Progressive disclosure: The interactive elements revealing hidden information are not apparent.
Anticipate needed information
For prospective clients, my business partner likes to know three pieces of information. Whatever else I put in my message to him about a prospect, I also put those three pieces of information.
The best way to do that is to look at the action item and think, “What would I need to know in order to answer this question myself.” If you can think of a data point, but don’t actually have it in-hand, be sure to highlight that in the message. Example:
Mid-sized project likely good match
- Starts: Not sure. Assume ASAP.
- Duration: 4-6 months
- Scale: Not sure of exact budget but likely comparable to Project ABC.
Two more things
- I also put key phrases in boldface to make them stand out.
- I like to enumerate attachments so people know exactly what they’re getting.
The Future of Email
I’m experimenting with using more color to communicate overall disposition of email. I’m also thinking about ways to make email more visual. Unfortunately, it’s rare that a quick sketch (after scanning and attaching to the message) is faster than just writing.
Structured Email: What’s the Real Return?
It would be hard for me to quantify the value of well-structured email. I don’t mean that it would be hard to measure, I just mean that it would be hard for me, personally, to measure. Mostly because I’m lazy.
And it’s because I’m lazy that I’m confident more structured email is helping. I’m responding to more messages, and gleaning the overall gist of a message is much faster. I anticipate a few other benefits:
- I search email a LOT to find stuff. I hate tagging/labeling/classifying/foldering messages. I just archive everything. With better structure, I anticipate search will be more effective.
- Referring to old email will become much more efficient. Scanning a well-structured message will likely yield that elusive piece of information much faster.
- All of us do email every day. Forcing ourselves to be structured about it might mean that we get in the habit of doing it, and that habit may find its way into other aspects of our professional lives. Imagine highly structured meeting minutes, project plans, and client deliverables!
You might worry that a structure is a creative-killer. This is perhaps a topic for a separate blog post. Suffice it to say that creating a well-structured email is a design problem in and of itself, one that requires careful thought and sensitivity to your users.
What do you do to write more structured emails?
Eight Principles of Information Architecture
For the last few years, I’ve been informally codifying some universal principles that guide my work as an information architect. They’re not guidelines or patterns… just some things that ring true and that help inform my designs.
These principles were the topic of my short session at this year’s IA Summit (taking place in the arid, strangely quiet Phoenix, Arizona). I’ve posted the slides to SlideShare (also embedded below), and the speaker’s notes are intact. For those interested in the process that got me to the slides, you can download a PDF of the outline I prepared.
Decision-Based Design
[Reprinted from my old blog, dated October 2005]
One of the major conclusions of my work in content management theory is that systems designed to enforce decisions will fail. Consider a workflow system that forces users through the same process, regardless of circumstances. Invariably, situations arise where the basic workflow doesn’t hold — authors are absent from work, editors don’t have the right expertise to review a document, the content demands a new structure. Yet the majority of content management systems — indeed, most business systems — prevent humans from accommodating these scenarios because they are confined by the rules imposed by the computer.
I realized that computers should stick with what they’re good at — serving up information — and humans should be allowed to do what they’re good at — making decisions about day-to-day situations.
- Focus the system on providing information to users to support the decisions they need to make.
- Trust users to make good decisions if given the right information.
- Avoid enforcing business rules, which may change with each new situation.
- Evaluate requirements based on the extent to which they support decision-making.
Coincidentally, I have begun work on a new system that is ripe for applying this philosophy. This project has a couple things going for it:
- The tech lead and I met informally a few weeks ago, and it was clear that he and I see eye-to-eye on this approach. He lamented the existing system as inflexible, indicating that the users have been extremely frustrated that it’s not designed to match their thought process. They’ve had to develop some work-arounds to accommodate situations that are not as extraordinary as they first thought.
- The system is meant to support a process with more-or-less clear inputs (submissions from customers), outputs (approval or denial of submissions), and milestones (specific dates are determined at the outset). These clear-cut bookends make it easy to imagine the process in this way.
- The system has pretty clear roles: a lead (the person who makes the decision about the customer submission) and a reviewer (the person who does the initial review of the submission and makes a recommendation). Because of these clear roles, we could structure our conversations around the different people making different decisions.
(The purpose of the project is to support a process for reviewing submissions from this organization’s customers and providing some kind of response.)
We’re still in the early stages of the project, but so far it seems to be working well. The project manager, tech lead and analysts have been enthusiastic to play with these new techniques, for which I’m most grateful. The design team seems to know that I won’t let them down, and they’ve been positive about my lines of questioning, so I seem to be getting at information that will help inform the design. Here’s what we’ve done so far:
Decision Lists
Instead of compiling all our observations into a list of requirements, we brainstormed a list of decisions our users have to make during the course of the process. These decisions were expressed in the form of questions like, “How many reviewers will we need?” Though the answer varies with each situation, they pretty much always have to answer this question.
As the brainstorming progressed, we sorted the decisions in more or less chronological order and categorized them in different events. For each event, we indicated who the key decision-maker was and the scope of the decisions — what the decisions applied to, whether that be the entire project, one of the customer submissions, or one element from one of the customer submissions. Most importantly, we began listing the inputs — the information that the users need to make the decisions.
The outcome of this process was a table that listed every decision our users have to make during this process. I also captured some of our outstanding questions about the process, so we could clarify with users at a later date. Some observations from this exercise:
- Different people answer the same questions differently. The best example is the assignment of reviewers to customer submissions. Some leads do this arbitrarily while others apply a thoughtful approach. It told us that we couldn’t use the system to enforce any particular method.
- Some decisions are repeated. Since our users are looking at a collection of items, they need to ask the same questions about each item. Sometimes they can make these decisions in bulk — about a number of items at once — and in other instances, they can only make them one at a time.
- Some people have to answer the same question based on different inputs. Leads and reviewers all have to decide how they’re going to priortize the customer submissions, but they use different criteria to make this decision.
Most of the data for this exercise came from the team’s existing knowledge. Obviously, first-hand user research is preferable, but at this point infeasible.
Sorting Decisions into Screens
Admittedly, after we came up with this list, I wasn’t sure how I would use it. Everyone got into the process of creating the list, but I hadn’t though much further ahead. I was used to personas — a flury of activity yielding deliverables that sat on the shelf.
After a requirements meeting with the client, we held a post mortem and the project manager indicated that we were starting to come up on the design deadline. I suggested a brainstorming meeting, but wasn’t entirely sure how I would facilitate it. At first I thought about an exercise I saw Marc Rettig demonstrate where he’d taken all the system features, put them on stickies, and organize them into related groups. It then occurred to me that I could do the same thing with our list of decisions.
I printed each decision out on a card and we did an internal card sort. There were a couple principles guiding the card sort:
- Two cards went together if they were related decisions — decisions about the same kind of thing or made virtually simultaneously. For example, two decisions considered related were, “Do we have enough people assigned to the project?” and “What method will we use to assign people to customer submissions?”
- Two cards went together if they were decisions that could be supported by the same information.
During the process, we elaborated on the kinds of information the users would need in order to make the decisions. We also realized that although we’d separated some decisions by events in the listing exercise (above), they really went together. In other instances, we divided a single event into multiple groups of decisions — one event ended up as three groups of decisions.
To facilitate the activity, we imagined each group a “screen”, such that a user should be able to make all the decisions in the pile without having to click away. In other words, one screen in the application should be able to support all the information required to make all the decisions in the pile of cards. This is how I set up the exercise for the team, and thought it made sense because we were trying to group like decisions. In the back of our minds we knew that this initial take may be totally off base, but it did help move the discussion along.
The feedback on this exercise was very positive. It allowed us to envision the user experience without getting caught up in screen design — even at a basic level. I didn’t stand at a white board and sketch rectangles. It was refreshing.
Decision-focused Wireframes
Even my wireframes look different. I’ve only just started, but for the first time my IA decisions have real traceability. In addition to functional annotations, the wireframes include the decisions that the screen needs to support. I’m taking a crack at ranking the decisions based on our card-sorting conversation. Each wireframe, therefore, includes a list of decisions that the user should be able to make when looking at the screen and which of those decisions is most crucial.
The wireframe itself is shaping up like my page description diagrams — a list of content in priority order. By including the list of decisions, I’m showing my work: the most important information on the screen corresponds with the most important decisions users have to make.
Next steps
It’s hard to say at this point whether this approach is worthwhile, and the success of the wireframes will be a big part of that. The challenge for me will be to get out of the high level and focus on the details. (Though a decision-based approach does force this by putting crucial information front-and-center in the design process.) There are a few other things that we’ll need to work out:
- Interaction models: At this point, we haven’t thought about the transaction side of the application. In a sense, this approach is more bottom-up: we’re looking at the screens we need to design to support various decisions, but not how those screens should relate to each other. At this point, it’s conceived as a linear process, but clearly it’s more complex than that.
- Same screen, different users: The way these requirements shake out, it’s very focused on individual user types. Clearly, the same screen may be used by different users, even though they’re making different kinds of decisions. I’m not sure how I’ll resolve this.
- Validation: The current situation at the client makes genuine user research difficult, so I’m not entirely sure how we’ll validate the design. Like I said, the source of this information has been the team itself, who has done extensive requirements gathering. This isn’t a case of excluding the users because our team are decent surrogates, but it is still a bit of a vacuum.
- Extension of method: Will this method be useful for other projects? Only time will tell.
Despite these reservations, I’m really pleased with how this approach is working. For years I’ve wondered how to adapt the requirements process to the needs of an information architect. Conventional requirements (”The system shall…”) have always felt inadequate to capture user needs for our purposes. Personas are too high-level, too difficult to apply directly to requirements. Use cases are too time-intensive. For the first time, I feel like I have a useful mechanism for capturing IA requirements.
Workshops in September
I’m teaching two workshops in September, and it’s not too late to sign up!
Creating and Using Concept Models
Hosted by TriUPA
Research Triangle Park, North Carolina
September 8, 2009 9am-5pm
Details and registration
The ideal tool for thinking through and designing structures for today’s web sites, concept models have become extremely popular artifacts. Creating them, and getting your team members to buy into them, can vary from challenging to really challenging.
Instead of representing individual web pages, concept models describe structures that are more appropriate for planning complex navigation strategies and working with content management systems. Their flexibility means you can apply them in a variety of circumstances and use them to describe different kinds of structures.
I’ve revamped this workshop from the ground-up, after getting lots of great feedback over the last couple of years. The content focuses more on pragmatic issues and now includes a section on translating concept models into wireframes. I’ve also created two sample models that will form the basis of our discussion.
Creating and Using Flow Charts
The Mansion at Strathmore (Bethesda, MD)
September 25, 2009 1pm-5pm
Details and registration
This is the next workshop in EightShapes’ monthly series. I’m especially excited about this one because I haven’t taught a workshop dedicated to flow charts, only as part of a larger workshop on deliverables.
Our clients are increasingly asking for flow charts (again!) since they’re crucial to planning and describing overall experiences. There are also a couple interesting variations which we’ll cover as well (storyboards, more focused on narrative; and wireflows, flow charts that integrate wireframes).
Early bird pricing (US$195!) lasts another couple weeks, so register now before the price goes up!
Hope to see you at one or both of these!
My second poster from the 2005 IA Summit, and another one I’m particularly proud of. In the mid-2000s, during the renovation of our house, I became interested in audio systems. As an IA, I was curious about how people who expect their entire music collection to follow them around could navigate the library with a small interface. That led to getting a few different whole-house audio products to try, and subsequently this poster.
In 2005, I presented this poster at the IA Summit, on different techniques for representing data and content in wireframes. By request, I’ve posted it here.
Difficult Conversations: Taking Things Too Far
Michael Scott is (or was, if you’ve been following The Office this season) the branch manager for a mid-sized paper company in Scranton, Pennsylvania. He and his branch are successful despite themselves, and corporate headquarters asks him to do a northeast roadshow to other branches, to explain the secret of his success. (Corporate is constantly surprised by the performance of the Scranton office, for reasons that will become clear in a moment.) For the roadshow, they make only one provision: He is to avoid the office in Nashua, New Hampshire.
From The Office: Michael and Holly
Last season, Michael fell in love with his office’s new HR manager, Holly. When the powers that be found out, they relocated her to Nashua, anticipating (not without reason) serious repercussions from the office romance. Months later on the road trip, Michael’s traveling companion, the receptionist and office manager Pam, talks about finding closure on an old romance of her own. Michael becomes convinced a trip to Nashua will help him get closure on his relationship with Holly.
Upon arriving at the office in Nashua, Michael and Pam learn not only that Holly is out sick that day, but also that she has started a relationship with someone in that branch. The effect on Michael was evident, an even balance of humor, discomfort and compassion that is the show’s calling card.
Michael decides to conduct the training anyway. It is, no surprise, an unmitigated disaster. He hasn’t even uttered half a sentence before he passively aggressively picks on Holly’s current flame. Needless to say, before long he retreats, leaving Pam to finish the training (along with all of Michael’s slightly inappropriate and extremely unconventional training props, like a real chain saw).
This is merely one example of many that illustrate Michael’s complete ignorance of basic social conventions. Each week The Office treats us to insights about basic human behavior, especially in a professional context. Michael’s exaggerated behaviors shows us what happens when you take best practices for dealing with office dynamics too far.
As part of our Difficult Conversations workshop, Chris brainstormed four pieces of advice. We use these to kick off the workshop because they are, on the surface, some basic tips for improving our skills in managing difficult situations. At a deeper level, however, they are yardsticks by which to measure our own behaviors.
- Be Positive: Focusing on what can happen and what’s working in a situation preserves the forward momentum of the project.
- Engage Your Audience: Making colleagues essential to the process curtails potentially adversarial situations stemming from a perceived lack of ownership.
- Empathize: Putting yourself in your colleagues’ shoes can help put their comments and behaviors in a larger context.
- Lighten Up: While still taking the project seriously, it’s possible not to take yourself too seriously, jeopardizing progress by letting your ego get in the way.
In adapting this workshop to a short lecture, I wanted to help participants understand that it’s important to strike a balance with each of these best practices. To that end, I identified the extreme for each of them, surfacing what it meant to take each of them too far:
- Be Positive: ignoring potentially adverse situations or issues
- Engage Your Audience: losing the focus of the project in favor of coddling colleagues
- Empathize: getting too personal
- Lighten Up: making a joke out of everything
In looking at these extremes, I saw Michael Scott, the logical exaggeration of all the things we try to do to smooth over office politics. The reason why The Office is a successful sitcom, besides the sympathetic characters and good writing, is that it’s grounded in reality. Michael’s behaviors aren’t alien to us. They’re sourced from ideals we strive for. The ideal, though, isn’t an extreme: it’s a balance.
The Story Behind EightShapes Monthly Workshops
From the get-go, Nathan and I knew that training and education would be a major part of EightShapes’ offerings. We anticipated offering private training to our clients in our techniques and expertise. We also aspired to build a multi-day conference attracting participants from all over the world. With Adaptive Path no longer offering UX Week in Washington, DC, we perceived an enormous opportunity to create an event that served our local community while providing content worthy of a national or global conference.
What we did not anticipate was a global financial meltdown. Believe me, if we had, we definitely would have told you about it.
Before the mess, we put on a successful, sold-out, one-day workshop in August 2008. It was small, but participants seemed happy and satisfied. We priced the full-day workshop about $200 less than a full-day pre-conference workshop costs at the IA Summit. We probably could have charged more, but we wanted to gauge interest, format, venue, logistics, etc.
At the beginning of 2009, I sat down to plan the EightShapes conference. At that point, it was clear that people were doing business differently. On the consulting side, we saw our clients going through budget cuts, and it was taking longer to close new customers. We heard about friends getting laid off. We started a drinking game around using the words “limit travel” during project planning calls.
We ran a survey to gauge interest in content and different formats. Respondents indicated that they would be up for a two- or three-day conference. We got to planning a multi-day event that mixed workshops with regular sessions.
Then came the conferences, the usual ones we attended every year–Interaction and IA Summit. Though Interaction was larger than last year, I know it took some effort to get the numbers up. Attendance at the IA Summit was almost half what it was last year. My pre-conference sessions, with participants usually numbering in the dozens, were considerably more intimate. The evidence suggested that the big conferences weren’t doing as well–businesses both small and large were watching expenses.
So, we decided to go in the other direction. Fortunate that we work in a community with a large UX presence, and one that craves education, we based our new approach on three things:
- Small
- Inexpensive
- Practical
We had kicked around the idea of a monthly workshop series before, and now dusted the idea off since it seemed like a good fit for the current climate. (If you’re following along, you’ll note idea has been kicked, dusted, and fitted.) The new format meant we could focus our marketing to the DC UX community, explore new venues, and keep costs down by eliminating typical conference niceties. At the same time, with a smaller group, we could preserve some of the creature comforts without adding too much cost. Here’s how the concept netted out:
- Venue: Cool library room at the mansion at Strathmore, an elegant arts venue in suburban DC
- Cost: $188
- Size: 12 people max
So, without further ado, the EightShapes Monthly Workshop Series, and our first workshop, reprised from the IA Summit at about $200 cheaper, Modeling Concepts.
If you’re in the DC area, I hope you’ll join us!
