This month we’ve reviewed books on many different topics. We move from sustainable design to undercover UX and iPhone design.

Undercover User Experience Design

Type: practical
Edited by: James Box / Cennydd Bowles
Publishers: New Riders
ISBN: 978-0321719904
Details: 192 pages, paperback

Get the book

According to it’s cover this book will learn you ‘how to do great UX work with tiny budgets, no time and limited support’. In about 180 pages it will introduce you to the world of UX design and tries to can help you create better products in a company that has never even heard of the term UX.

The moment you open the book you get all sorts of practical tips and methods to create better products. There are a total of seven chapters: ‘exploring the problem’, ‘generating ideas’, ‘making it real’, ‘refining your solution’, ‘working with’ and ‘where next’. Each chapter shortly introduces the theme and gives you mainly hands-on advice on how to do stuff. This ranges from the creation of low cost personas to making good sketches and doing simple usability testing. The explanations are very clear and to-the-point, don’t expect extensive explanations, variations and cases to dive into a subject.

All this is really interesting for people who are new to the field or who want to introduce UX into their organization. All the information in the book isn’t new, it has been collected and written in a very accessible way. The thing I found most interesting was the ‘generating ideas’ chapter and the explanation on how you should deal with different disciplines in a company. In that part of the book you can feel the true experience of the writers, where they show that you shouldnt just work from your UX point of view, but should also understand where the other people (programmers, designers, CEOs, marketers, etc) come from and how you could best work with thim.

As a conclusion I would say this is a very interesting read for people who are new to the field. It gives a short and simple explanation on every step of the process and great tips on how to do your job. For experienced UX designers there shouldn’t be any surprises in the book.

Product Design in the Sustainable Era

Type: case studies
Edited by: Dalcacio Reis / Julius Wiedemann
Publishers: Taschen
ISBN: 978-3-8365-2093-5
Details: 440 pages, flexicover

Get the book

Over the past years sustainable design has been a hot topic. As designers we want to have to have the feeling we design for the good of the planet. In this book Taschen has tried to create a good overview of the different products and initiatives worldwide to create a more environmentally friendly world. This has resulted in a beautifully designed book full of cases ranging from cradle-to-cradle shoes to new ways of generating energy.

I found it a very inspiring book, but at the same time it shows the hype around sustainable design. There are many great examples that would inspire every designer, but the book also contains several examples that have nothing to do with the core beliefs behind sustainable design. In any case it’s a good overview of the current status of sustainable design.

The Internet Case Study Book

Type: case studies
Edited by: Rob Ford / Julius Wiedemann
Publishers: Taschen
ISBN: 978-3-8365-1895-6
Details: 384 pages, hardcover

Get the book

Usually I’m not a big fan of books that show collections of websites. Most of the times the examples are already outdated a week before the book goes to print. But for some reason I kept turning pages in this one. In total ‘The Internet Case Study Book’ has 60 different cases in four different categories: campaigns, e-commerce, promotional, social media and corporate. Each case has four short paragraphs describing the brief, the challenge, the solution and finally the result. This simple approach really helps to get a quick overview of the project and to get inspired for your own projects. I must admit that sometimes I felt the descriptions were a bit short (and personally I always want to know what went wrong), but still it’s a great overview with inspiring examples. If you want to buy the book do so within half a year, otherwise the cases are too old.

Designing the iPhone User Experience

Type: practical
Edited by: Suzanne Ginsburgy
Publishers: Addison-Wesley
ISBN: 978-0321699435
Details: 336 pages, paperback

Get the book

In the book ‘Designing the iPhone User Experience’ Suzanne Ginsburg explains in an easy way how to design intuitive, easy, powerful and useful apps for the IPhone. The purpose of this book is to provide a clear foundation to interaction and visual designers when starting to design iPhone apps. But also for developers the book is interesting to get an understanding of user needs, planning, visualization and usability-testing skills.

Suzanne describes a user-centered approach to sketching and prototyping. The following subjects are treated; overview of the iPhone hardware and iOS application styles, step-by-step advice on how to conduct upfront user research, tips for analyzing user research and evaluating the competition and an explanation how to develop and refine your app concept.

The book is clearly written and provides many interesting examples and case studies – interviews with superb iPhone designers and developers, providing first-hand insights into the thought processes behind their apps.

It is a pity that the parts about user research, generating ideas, prototyping and usability testing are very general. As almost everybody that will this book, has already been in design processes, the principles explained are most probably already known to them. What is interesting though, is what aspects differentiate this topic for the iPhone app in specific. This interesting, relatively ‘new’, context of the iPhone could be elaborated more. Moreover, the summaries at the end of each chapter are not very substantial. So reading the summary, doesn’t provide you the knowledge of the chapter.

(review Designing the iPhone User Experience by Rose-Anne Dottinga)

Because of a trip to Seoul, South Korea my UX clippings are a few days later. But that doesn’t make them less interesting.

• With fast developments in the mobile world, there were again quite some reflections this week on the role of mobile devices in our lives. Smartphones are the new drug of choice, writes CNN. They actually tap into one of the same pathways in the brain that make slot machines so addictive.
• Wired instead looks at the future of smartphones. They are particularly interested in what is happening in interface innovation at Nokia Research, as this reveals some intriguing possibilities on how we will interact with our devices in the future. Nokia as we know has problems. Smartphone problems. Software problems. American problems.
• Gizmodo is convinced that to fully understand what’s wrong [with Nokia], we’ve got to understand what’s been right, or to put in another way, what’s distracted Nokia. Meet the most popular phone in the world.
• Finally Intel is exploring what future everyday use could arise from their recently launched context-aware computing concept.

Broader reflections this week were on the pitfalls of socially responsible design (in Metropolis Magazine), the psychology of complexity (in Rotman Magazine), and the upcoming design power of South Korea (by myself, Mark Vanderbeeken).

Agile has a relatively short history in the broader view of software development. Integration of User Experience into Agile has an even shorter history with relatively few stories of overwhelming success. Over the last eighteen months, we at TheLadders have had some successes—and some failures—in our foray into a post-waterfall way of developing elegant, efficient and sophisticated consumer-facing software. This is our story.

Who we are. What we do.

TheLadders is an online subscription job service that helps professionals, recruiters, and employers connect to fill positions that earn $100,000 or more. Our execution team consists of product managers, developers and user experience practitioners. The UX folks fall into three disciplines: interaction design, visual design, and copywriting. The UX team’s work spans both pre-paywall acquisition and conversion marketing (e.g., banner ads, landing pages, email campaigns, etc.) as well as post-paywall product design (e.g., job search, applying to jobs, finding candidates, etc.).

Prior to undertaking the transition to Agile, the UX team was a shared service—in essence a pool of resources assigned to projects based on bandwidth and capacity to whichever business line had the next need. We worked in a traditional waterfall style with three- to nine-month release cycles, big upfront design, late-stage user testing and validation. We produced very thick functional and design specifications destined for explicit handoffs to a development and quality assurance team. We were happy with this, in that we didn’t know any better. This is the way we’d always worked, and with little to no knowledge of the Agile movement we were meeting our commitments to the business.

And then, one day, it happened.

In a unilateral move, the development organization announced that we were switching to an Agile software development approach. There was no discussion with the other disciplines and no guidance about how the UX team would integrate into this new way of building products. All of this was beside the point since Agile was sold into the organization with promises of better products, faster releases to market, tighter validation with our customers and the ability to pivot the organization on a dime. Who could argue with that?

The expectation of the UX team was that we’d “figure it out” as we went along but the myths, stories and case studies available for learning were not very promising. Initial, surface-level research into the topic revealed that while many people had implemented solid starting points, there didn’t seem to be a single organization that felt it had truly found a way to marry the iterative Agile process with the needs and outputs of a user experience practice.

The deeper we dug into the practices espoused in the Agile Manifesto, the clearer it became that our comfortable “design phase” was going to change dramatically. That realization triggered a flood of new questions:

• How do we set expectations about the work we will now generate?
• Will it be of high enough quality for the business and for us?
• As you slice projects down into iterations, how do you maintain focus on the bigger vision?
• How do you keep the development teams busy each iteration?
• Will the business accept lighter product iterations, and, if they don’t, who will be blamed?

Getting out in front of the change.

Google was the first tool we reached for. Search after search led to the same handful of resources (Jeff Patton, Desiree Sy, Salesforce and Citrix case studies) who all preached a similar approach of staggered sprints and visual display of the stories being developed (storymapping). Google also returned many stories of failure and, worse, vitriol towards designing in an Agile environment. Awesome.

Not deterred, we expanded our research to interviewing actual people who had attempted to do this. Folks from Citrix, Salesforce, AOL, Liquidnet and Wireless Generation all lent their opinions and experiences into our thinking. These were companies who were actively practicing Agile with their entire teams and, in most case, were far larger than us. If they were doing it with some measure of success, there was no reason little-old-us couldn’t, too.

Finally, we brought in Allistair Cockburn. His name is on the Agile Manifesto! If anyone had answers to our questions, it was him. While he did provide some insight, the questions he asked us revealed larger organizational issues that clouded the relatively focused task of integrating Agile and UX. Ultimately, Allistair’s visit helped us determine effective starting points for these efforts.

All of this research gave us what felt like enough raw material to put together a plan.

Our first attempt: just get it all done in 2 weeks.

What do you get when you take a process that used to take 9 months and try to cram it into 2 weeks? The short answer is frustration.

We kept the same processes, hand-offs and deliverables in place while adding in the concept of a 2-week sprint and daily stand-up meetings. We made the project sizes smaller but were still working sequentially. We failed to integrate the most important aspect of Agile—philosophy. We went straight for the tactics without considering why we were doing them. Our thinking didn’t change and hence there was no improvement in our collaboration or communication. The teams remained siloed in thinking and behavior. All we’d actually done was make deadlines shorter.

We did away with functional specs (and the interaction designers rejoiced!) and used the story card to replace them. The cards lived on boards and very quickly these boards began carrying the weight of the now-outlawed specs.

One of our Scrum team’s iteration board showing story cards, prioritization, activities, resource allocation and progress in the sprint.

Task designations on the iteration board. Example: Uc = Use Case, Tc = Test Case, Ia = Information Architecture, etc.

Further close-up reveals avatars indicating who is working on each card. Check marks indicate which activities have been completed.

They functioned as requirements documents (story cards), project plans (prioritization), resource allocation (avatars on boards to show who’s working on what) and status indicators (pins, colors, checkmarks, etc). The scope of supporting all of these elements quickly outgrew what one or two boards could handle and the number of boards multiplied (some would say to a ridiculous amount).

Wireframes also began to pick up some of the heavy lifting specs had left behind. In an effort to ensure all interaction rules were documented (partially egged on by developers uncomfortable without that level of detail) the interaction designers created annotations on the wireframes themselves that were often dense enough to obscure the experience being described.

Example of wireframe where the annotations were so heavy, the experience being depicted began to get obscured.

In an effort to keep track of the big picture (and combat the small-scale visioning of creating slices), we created a high-level vision document (essentially a sitemap or workflow) to serve as the barometer against which each change was measured. It also allowed us to keep the context of the smaller changes we were making in mind (relative to the big picture).

Example of a Vision Document (essentially a site map) showing the project slices within a broader context.

This failed.

No one owned it initially and since the process was driven by the development team (they were the only ones with any kind of Agile experience) the UX team didn’t feel empowered to defend such a document. In addition, due to the shared service nature, there was no loyalty to a particular business line or project since the assigned UX team members were just the “designers du jour.” It is nearly impossible to own the holistic theme when you may be abandoning it at the end of the two week cycle.

All roads lead to pain ....

Despite all of this upfront research, preparation, conversation, and insight, our first attempt at integrating UX into Agile yielded the diagram below. This was created by the UX team after a UX-only retrospective where we detailed all the challenges we were facing in this new world. All paths in the flow lead to the center of the diagram reading “[agile] creates a NEGATIVE ENVIRONMENT that FOSTERS FAILURE and generates LOW MORALE.” It is safe to say our first attempt was a failure.

Our second attempt: introduce two secret weapons

If we were going to get things working smoothly, it seemed clear that we needed more time to do our work. To buy us this time, we created and implemented a suite-wide style guide. The purpose of the style guide was to:

• Define a set of re-usable components once.
• Create a centralized, easily-accessible asset library for designers and developers.
• Provide a living document which designers and developers could develop as the site matured and evolved.
• Reduce the time developers needed to create repetitive elements (forms, buttons, UI elements, etc.).
• Reduce the number of design cycles by allowing designers to focus on the core experience while relegating the repeated patterns to style guide assets.

With the style guide in place, the UX team no longer had to worry about designing, defining and defending standard UI patterns. Instead, we could take the precious time we had in each sprint and focus on the core interaction problems.

A fringe benefit of the style guide was that now, in essence, everyone (including developers) was a designer. It leveled the playing field for many projects by allowing those not versed in interaction design to use the pattern library and create acceptable outcomes. Also, by providing fully designed elements, the style guide allowed interaction designers who were not strong visual designers to create polished, final-design-level wireframes. Developers also could create experiences without input from the UX team.

This tactic did indeed buy us the time we needed, but for some members of the team, it was too high of a price to pay. Making everyone a designer devalued the skills and expertise the team was bringing to the table. The way we mitigated this concern was by placing the most complex interaction problems within the UX team and “outsourcing” the simple ones to resources outside the team.

To gain even more time, we moved quickly into prototyping our designs. The team had transitioned fully to Adobe’s Fireworks product because of its strong prototyping features. While the code we were creating was throw-away code, illustrating the experience by showin rather than telling allowed us to ditch the heavily-annotated wireframes, facilitate better estimation at sprint planning meetings and have something to compare the working code to when it was ready for user acceptance testing.

Verdict? Win times two!

Our third attempt: put everything in line

Right now, you may be thinking, “Wait! You forgot about usability testing!” In the past we’d wait until close to the end of the cycle to test with users. With Agile we had to do something more frequent and less formal. Based on repeated attempts we ended up with this formula:

• Bring in no more than 3 participants each time.
• Test every other week (in a 2-week sprint situation) on the same day at the same time.
• Show the participants whateveris ready (this includes paper sketches all the way to working code).
• Schedule the session midway in the sprint leaving enough time to react to the findings.
• Invite EVERYONE to this standing session (don’t be surprised when they actually show up).
• Use the testing to “clear the boulders” out of the interaction (after 3 participants, it is clear what they are).
• Use the remaining time in the sprint to iterate on the design and validate with users again, two weeks later.

This has proven very successful. Recruiting for the testing is done via an external vendor, but everything else is run on site. Developers, product managers and executives regularly drop in to view the sessions (which buys implicit approval for the design tweaks UX makes), and the quality of the product at the end of each iteration is improved.

Speaking of approvals, we had to build those in to this new process as well. In the past, drive-by and email reviews were the strategies of choice. With the time-boxed nature of sprints, that approach just didn’t work.

We implemented two design reviews per iteration. The initial review is held midway through the sprint and serves to align the execution team with their product owners and project sponsors on the general direction of the proposed experience. The second review, scheduled two days before the end of the sprint, is meant as a final review. The design has to be 95% of the way “there” before the work could proceed to development. If it is not agreed to be 95% done, the project is pushed out another sprint, and the UX team spends another two weeks refining the design. In between the first and second designs, ad hoc reviews could be held if the designer felt there was a need for more fine-grain alignment.

For the design review meetings to fulfill their goals, attendance is critical. We hold design reviews at the same time on the same day every week, and the reviews are mandatory for all stakeholders. We also made sure everyone understood—and agreed—that missing a review meant implicit approval of the design. Attendance has been and continues to be strong.

Putting testing and design reviews in-line was a huge success for our teams. The design reviews provide designers with much-needed mileposts to strive toward while buying more UX design time through streamlined processes.

Verdict? Another win!

Our fourth attempt: bring everyone together and then separate

Collaboration was still missing from our scrum teams’ chemistry. Communication, we theorized, would come naturally if we could increase the level of collaboration. In addition, collaboration breeds alignment and a sense of ownership which in turn leads to less resistance and greater productivity.

We turned to the “design studio” technique for help.

Ripped off and bastardized from architecture school ,the design studio puts a cross-functional team together in one room and focuses on three activities:

• Sketch
  – within the confines of a forced timebox each participant has to sketch (literally, with a pencil and paper) a finite number of ideas on how to solve the given problem
• Present
  – then, each participant has to present each one of these ideas to the broader team and speak to its merits
• Critique
  – the other participants in the room proceed to critique each presentation based on merit and problem-solving efficacy (not on its fine art qualities)

This process is repeated three times, with each round increasing the fidelity of each sketch. Finally, one large sketch is presented with the highest amount of detail possible within the timeframe.

The benefits of this technique are manifold, but the most critical one is a sense of ownership and alignment from the cross-functional team. After participating in this session, everyone will see their “fingerprints” in the designs created later by the UX team. This feeling of ownership brings greater team alignment, as everyone understands the reasoning behind the design. In addition, should criticism be leveled at the design, the UX team has cross-functional support for the approach.

In addition, the UX team leaves the session with dozens of raw ideas to work through, evolve and incorporate into a final experience. This is much more productive than starting from a blank canvas.

Bringing together the cross-functional team to collaborate made one thing very obvious to us—the rest of the disciplines had dedicated resources to each project, while the UX team was still a mercenary squad going wherever the need was greatest. It became clear that we had to dedicate UX practitioners to each of our projects.

This change, while risking burnout on specific types of work, has proven tremendously successful. Camaraderie, communication and collaboration with UX—which never would have happened in our shared services environment—now flourishes and thrives. Spending time with the same folks every day working on the same problems binds teams together. Bonding breeds trust, and trust is core to Agile success.

Where we are today: habits are evolving. Slowly.

Years of training have taught designers to keep the kimono closed until the design is ready to be reviewed. This bought time AND control. Under Agile, designers need to be more open about what they’re designing and why, and they must be ready to show work much earlier than before. This is a tough change for designers to make.

We haven’t fully bought in to all of these changes quite yet. The team still feels that our new way of working dilutes the work, rushes it, and reduces quality. In addition, as mentioned earlier, it reduces the team’s perceived uniqueness and value they bring as trained designers to the organization’s success.

Collaboration is also tough because design is inherently a hero-based discipline. Everybody wants to be the person who designed the iPod or the creative genius behind Mint.com’s oft-lauded UI. Design awards get handed out to individuals, not teams—especially if a lot of a designer’s career has been within agencies.

Agile, on the other hand, is distinctly anti-hero. It’s about the team—first and foremost. For UX designers to integrate into Agile teams, the hero dream has to be left behind.

Another pivot point in the process where UX is currently struggling is the decision of what is a minimally viable product versus a minimally desirable product. We’ve been struggling with who defines what we release, when we release and what role UX plays in that decision. Currently, development decides in some situations, product management in others, the business in yet others. Our UX team needs to assert itself and influence these decisions to defend the brand and experience of the company. TheLadders is not a nascent startup that can afford to risk its existing brand awareness and values with the release of minimally viable feature sets. These feature sets can be light but must adhere to (or exceed) the experience to which our paying member base has grown accustomed.

Finally, in an effort to move beyond the staggered sprint model, we’ve begun experimenting with parallel pathing design and development. In these scenarios, UX and development start at the same time with the same end date. Designers are paired closely with developers and, instead of reviewing design deliverables, actual working code is reviewed each week. This tight collaboration reduces many of the dependencies described above but requires much more flexibility on the part of the designers, developers and most importantly business and product owners.

Our first attempt at this failed since we attempted to hold design reviews for UX work while development was ongoing. The reviews changed the path of the experience dramatically enough to warrant a pause in the work development was doing. Our next few efforts aim to subvert this process by reviewing working code—which has solid UX input. These efforts have been more successful due to the team’s comfort and trust working through staggered sprints together. We’re holding code/design reviews every two days on these efforts to review the experience, as it will appear to our users, and provide feedback on that experience (code, design, ux) – not an approximation of it as in the past.

Conclusion (for now)

We dove into Agile with hardly any knowledge. We’ve learned a lot through failure and iteration. The most salient learning here is not one of process but of philosophy. In order to truly become more agile (lower case on purpose) we must change the way we think about User Experience Design within the context of product development. If we can move away from our ingrained hero-based mentality and embrace more collaborative, open and shared product development models we’ll all be more successful—and ultimately, so will the businesses we support. The first step is communication, but the ultimate goal is trust.

The first step is communication, but the ultimate goal is trust.

This can’t be achieved out of the gate—it is the fruit of repeated tests and trials with your team through which you grow, bond and evolve into a high-performance, highly agile team.

Each week Mark brings us the latest UX news from around the world wide web. This week his focus was on cultural contexts and the Internet of Things.

Culture and context

We at Experientia often argue that UX design goes far beyond the interaction between people and a device or service, and that  user-centred design cannot do without an understanding of culture and context. This week’s updates delve into the matter more:

• In response to questions from Amy Knox on the difference between US and European user experience, Søren Muus (creative director at FatDUX and co-initiator of the European Centre for User Experience) recently posted on the mail list of the Information Architecture Institute some interesting ideas on the matter.
• A contingent of Stanford University d.school students recently returned from Kenya, where they spent two weeks working with Nokia Research Africa, and the University of Nairobi, developing health-related mobile applications.
• “Creativity, Cost-Cutting & Keeping it Simple: what the Developing World can teach us about Technology” is the long title of a short feature story by Anna Leach on Shiny Shiny, a gadget blog.
• The French Ministry of Foreign and European Affairs and the International Telecommunication Union (ITU) have jointly published the report entitled “Innovative ways of appropriating mobile telephony in Africa“, describing how development is happening “from the bottom up” and an entire economy, both formal and informal in nature, has come into being to meet people’s needs.

Internet of Things

The other main topic coming up this week was the Internet of Things, where the issues of debate now increasingly centre on mobile integration, human involvement and buy-in, and information visualisation:

• Hunter Whitney concentrated on the importance of information visualisation in his article on public health for UX Magazine;
• Boston University‘s participation in the $2 million Smart Neighborhood project to make a Boston neighborhood more energy efficient focuses on ways to get people on board and participate in what they hope will be a “living laboratory”; and
• The Internet of Things was also a hot topic during the Device Design Day that Kicker Studio organised on 20 August in San Francisco. Make sure to check out the videos of the talks by Mike Kuniavsky (“Information as a material”) and Julian Bleecker (“Design fiction goes from props to prototypes”).

Something that’s fascinated me about online metrics since I started working in online (quite a long time ago in internet terms) is their immediacy. In fact, it’s their instancy… this real-time sense you get from actually watching people move in and out of a website or email or mobile platform—that really mesmerises. The numbers create a kind of certainty about the clicks, impressions, traffic volume… and based on those numbers we believe we can know what worked (or didn’t work). On the basis of these metrics we do more or less of the same.

As fascinating and addictive as these numbers are, it bothers me that these are the kind of metrics clients and agencies use to back-up ideas and shore up budget planning. Where’s the context? What do the numbers mean?

There’s a clear correlation between the media metrics that took hold of the advertising world in the 1980s, and the kind of metrics used to demonstrate online currency during efficacy during the 1990s. Media metrics, essentially measuring ‘eyeballs,’ or audience volumes, was the established bedrock of media-buying principles. Cost-per-thousand and audience testing entirely centred on brands asking “What do you think of me?”

In those days, when volume and mass ruled, the loudest, most ubiquitous voices were majestic, and the creatives that delivered ‘me-to-you’ messages were governed and controlled by the number crunchers on Madison Avenue and Charlotte Street. Audiences weren’t people – they were traded commodities. Come the turn of the millennium, the sheer cacophony of branded messages started to repel those same audiences, who began to zone out the noise and make their own media and brand choices. Audiences, markets—people!—got message-weary just around the time the internet got domestic.

Unfortunately, early players in the Internet business essentially copied the same kind of media metrics approach but applied it to an entirely different kind of media. You can see the logic… audience volume became the easiest way to describe effectiveness to budget-carrying agencies and a client demographic that felt technologically remote from this new media platform. Anyway – in comparison to the audience mega-transport ships of traditional broadcast and print media, all the Internet had to offer was little more than a landing-raft, in those days!

So, back to the metrics and why they bother me. Online you can measure everything. In fact, you can measure so much, you may drown in numbers before you get a chance to ask what any of them mean.

For instance, I can know how many people come to my website, where they come from, and which and how many of my pages they visit; I can know if they’re unique visitors or returners, and if they dwell for short or long periods; I know what they click on my page—I can even find out if they’re clicking in places that aren’t links. I can know if they’ve started to do something and then stopped, if they complete it, how long it took, and where they go next. I can measure when traffic numbers go up or down, and identify sad and lonely corners where no-one ever goes. I can see which search terms bring people to my site, and I can optimise the content and metadata to capture more of those people. And I can create the most detailed and beautiful charts that carry all these pieces of information back to my colleagues and clients and their bosses. Job done?

No. Traffic numbers are just that. Summaries of individual measures. Anyone can sit alongside a motorway and count cars, know if they’re travelling North or South, what models they are, how fast they’re going… Finding out why they’re on the road, what their journey’s for, and whether the route works? Well, that’s a bit harder, and such is the problem with online metrics and analytics. The appetite to invest in getting to know audiences / users – actually asking people what they want and then verifying their answers—is still pretty small.

CDA are content strategists, and we’ve been trying to figure out what makes good online content for a few years now. Aside from the rules around structure, language, and tone, and how to manage these aspects in the creation and publishing processes we’ve established, increasingly our conclusion is it’s all about context. At its simplest level, the question we want answered is: Is this content relevant and useful for the purpose of someone’s visit?

The plethora of metrics at the end of a mouse click, and more lately, Google Analytic’s richer analysis capabilities, make it possible (with expert input) to correlate different number sets and make experienced guesses at what traffic figures mean. Other bespoke systems such as WebTrends and ComScore let us run specific reports, but there’s still the sense we’re measuring the direction and colour of the traffic—not finding out why it’s on the road so we can build a better route.

The missing factor is a real-life user experience woven into the mix. I want to know if the content a site owner invests in is the content someone wants or needs to complete a task.

I want to know if the content we’re being asked to create is the content people have any interest in at all, or if it’s wasting my client’s budget. I want reliable evidence—from my audience or users—that the content we recommend to a client is worth his money. I want my client to be able to plan and budget his content requirements in the same way he plans and budgets all his business resources and expenditure.

And most of all, I want to understand the different contexts of a user visit, so we can recommend and create flexible content that meets each user’s context of interest.

Tall order?

Well, some while ago we developed the idea of CUT (Content Usefulness Toolkit). In outline, it’s a methodology of common sense.

First of all, CUT makes a big assumption. CUT assumes people respond positively to useful online content. But what’s useful for you may not be useful for me. What’s useful to users in a grocery ecommerce environment may not be useful to users on a recruitment website, or to a corporate site building an international brand. Getting the latest news may be useful on an investment site. Signing up for a daily tip via mobile may be useful for someone on a dieting site. So usefulness itself has to be understood, which is why the starting point with CUT is to find out what’s useful in the broadest context of the property.

And here’s a note: usefulness is not usability. Usability tests whether people can complete tasks within a planned or built structure. Usefulness is about understanding a need and targeting it with content that delivers. I’m seeing evidence the two are often confused.

Step 1: In our scoping model you can see that understanding usefulness within the context of a specific proposition is the critical driver for everything else. And understanding is achieved by talking to people—not by looking at traffic metrics (as beautiful as they can be made to look). Their role is later in the process. This concept is not new. We conceive and design virtually any new product to meet needs and solve problems. Ask any NPD professional.

CDA’s CUT (content Usefulness Toolkit) | identifies content for development or culling - CDA Ltd © 2008

Step 2: Now that we possess a greater understanding of what people find useful, we can plan or audit the content with an informed critical capacity.

Step3: Now we can begin to get smart with our metrics. With much greater insight into our audience, we can set a metrics plan that measures whether or not user traffic responds well to the content planned around our audience’s stated expectations of something useful.

Another note: be very careful with metrics, for example, how you consider ‘bounce’ numbers. There’s a school of thought that supports the negative interpretation that you’ve not engaged a bounced visitor. But consider how a bounce could record a very satisfied user: He had a question that was perfectly answered by the content of the page and immediately bounced off happy. It’s all in the context. If that page was a clear ‘how-to’ explanation of how to fix a leaky tap, for example, then you could well have a very satisfied visitor very quickly. If the page was the first of a 5-step registration, then it could indicate the process was unclear or not what your visitor was seeking.

So, understand what you’re measuring. This means setting your analytics goals to measure traffic behaviours based on what people have said they do or don’t expect to find useful. These goals are your indicators of content success or failure—but they’re only indicators.

Step 4: During Step 4, we ask the audience again. We use an online questionnaire to find out if people got what they wanted or not, based on their reason for being on the site in the first place. We ask why they were there, and ask them to rate their experience.

These quantitative responses, combined with our traffic metrics, pattern out to give clear targets for content development or even culling. The responses drive the strategic content direction and, critically, indicate budget allocation. They give content—the stuff that people come to access, the stuff that doesn’t just happen but which takes considerable planning and skill to get right—an operational and measurable foundation.

CDA are already working the methodology with several live sites. It’s helping make sense of existing metrics. It’s providing a framework that’s informing our recommendations and helping clients take a fresh view of the metrics they capture and use to make decisions about where to make investments.

Early, but exciting days—this is a nascent development but one we’re building into an essential business tool.

The process of publishing content, particularly when it includes content destined for the web, continues to be a mysterious process for corporate stakeholders, and sometimes for those involved in the process of publishing.

The simplest of project plans I’ve ever been given came from a program coordinator, circa 1995, and looked like this:

This was woefully inadequate from a production perspective. But from her perspective, the writing, which happened in her department, and the publishing, which to her meant getting the content before the eyeballs of her audience, were the only two important aspects to the publishing process, and the only two steps on her radar.

When the publishing team adjusted the process, it looked something like this:

Their process focuses on a set of production tasks, with the assumption that the process began with writing and ended with publishing. And in a way, it did—the published content remained static when print was the primary medium.

In 2010, the process looks quite different. Publishing content is a cyclical, iterative process that looks more like this:

Publishing to print is no longer the default setting for content. The Web is the main medium. Content gets converged, integrated, componentized, recombined, and syndicated. The content visible to users is the tip of the iceberg. A complex system supports the delivery of content, from infrastructure through user experience, and a host of post-publishing decisions close the loop, either to a new iteration or a content sunset.

The term “closing the loop” generally refers to a step in a cycle or process, used to assess effectiveness. It is not a final step, but rather a step that bridges the end of a process and the beginning of the next iteration. For content, closing the loop means considering content at every step through the conception, creation, management, and distribution of content – in other words, throughout the entire lifecycle of content.

Enter the Content Lifecycle

Recognizing a content lifecycle means recognizing that the business of creating and publishing content follows a recognizable, predictable, repeatable process. While the sub-processes may be subject to variations between content genres, as well as situation-specific variations, the overall process is consistent and stable. The content lifecycle describes an organic system, and is system-agnostic.

As the process of developing, managing, and publishing content becomes more complex, the descriptions of the various lifecycle stages include aspects of managing content through a CMS (content management system).

The saying “if you don’t know where you’re going, any path will take you there” is definitely a caution that applies to the management of content throughout its lifecycle. The success of a lifecycle is directly related to the effort put into planning the content strategy.  The various components and intersections of content have become too complicated to begin implementing, and hoping to connect the dots later on. When constructing a house, a builder works from a set of plans that specifies not only the structural dimensions, but also the heating, ventilation, and plumbing. By comparison, a content strategist creates the blueprint by which designers, writers, and developers can build a successful model for delivering content.

After all, the content lifecycle exists whether content is managed manually, with some assistance of technology, or highly automated through technology. The definition of a content lifecycle is about content, front and center. The definition assumes content is recognized as a corporate information asset, and requires the same level of custodial care as other corporate assets. The content lifecycle is about more than getting content to work within a content management system; in the bigger picture, the content lifecycle is about implementing a strategy to follow a repeatable system that governs the management of the content, throughout its lifecycle.

The content lifecycle covers four macro stages: the strategic analysis, the content collection, management of the content, and publishing, which includes publication and post-publication activities. The lifecycle is in effect whether the content is controlled within a management system or not, whether it gets translated or not, whether it gets deleted at the end of its life or revised and re-used.  The analysis quadrant comprises the content strategy. The other three quadrants are more tactical in nature, focusing on the implementation of the content strategy. Assigning the activities and decisions throughout the lifecycle would create an iterative process that looks something like this:

Analysis

In the analysis phase, the content lifecycle is concerned with the strategic aspects of content. A content strategist (or business analyst or information architect or writer) examines the need for various types of content within the context of both the business and the content consumers.

The analysis has a bearing on how the content strategy is implemented in the other quadrants of the content lifecycle.

Typical artifacts for this phase

• User research:
  > Personas – Identify major groups of content consumers and the content they would consume
  > Scenarios – Elaborate on when and how content is used
• Requirements:
  > Gap analysis – Determines content readiness and editorial and technical gaps
  > Requirements matrix – Organizes business and technical requirements in summary form
  > Process models – Express future-state content-related business processes during the content lifecycle
• Governance:
  > Governance chart – Establishes responsibility for content types and processes throughout the content lifecycle
  > Budget – Establishes budget authority and delineates budget sources for areas such as technology implementation and upgrades, content operations, and translations within the organization
• Content analysis:
  > Content inventory – Determines the on-hand inventory of content
  > Content audit – Analyzes the state of content quality and content deficiencies including missing or inaccurate content
  > Metadata taxonomy – Categorizes content by subject and creates an index
  > Content models – Codify content structure and components for each content type, and include conformance to any applicable standards
  > Content architecture – Organizes use of content types across all output platforms, such as publications, websites, handheld devices, or other systems
  > Wireframes – Organize display of content types for each output platform
  > Delivery design – Establishes the publishing pipeline for each output platform

Collection

Content collection includes garnering content for use within the framework set out in the analysis phase. Collection may be through

• Content development, which is creating content or editing other people’s content.
• Content ingestion, which is syndicating content from other sources or incorporating localized content.
• A hybrid of content ingestion and content convergence, such as
  > Integrating product descriptions from an outside organization with prices from a costing system.
  > Bringing together editorial content and user-generated content together in one display.

Typical artifacts for this phase

• Content design:
  > Topic maps – Create a “table of contents” that maps out content relationships
  > Localization plan – Establishes how and when localized content is produced and delivered, and examines the ramifications of localization on display and delivery methods
  > Customization and personalization maps – Determine derivation of content components and rules for inclusion or exclusion of components to create contextualized content
• Content development:
  > Style Guide – Establishes editorial rules for vocabulary, grammar, brand management, and language during content development
  > Standards – Ensure that content conforms to international standards that affect content delivery and reusability
  > Layout templates – Determine where various content and content types are displayed within a print page or electronic screen display
  > Content – Text, audio, graphic, video, or other human-usable media, including the metadata to render it findable

Management

The management quadrant is concerned with the efficient and effective use of content. In organizations using technology to automate the management of content, the management aspect assumes use of a CMS of some sort. In organizations with smaller amounts of content, little need for workflow control, and virtually no single-sourcing requirements, manual management is possible. However, in large enterprises, there is too much content, and there are too many variations of content output, to manage the content without some sort of system to automate whatever functions can be automated.

The content configuration potential is enormous, and builds on the information gathered during the analysis and collection phases. The solutions will be highly situational, and revolve around the inputs and outputs, required content variables, complexity of the publishing pipeline, and technologies in play. The most basic questions are around adoption of standards and technologies, and determining components, content granularity, and how far up or down the publishing pipeline to implement specific techniques.

Typical artifacts for this phase

• Production workflow:
  > Content business rules – Determine content workflow according to business requirements
  > Content workflow maps – Document content production processes
  > Data models – Plan data structure

Publish

The publishing quadrant deals with aspects of content that happen when content is delivered to its output platform and used in a variety of ways. Publishing the content is only a point in the first lifecycle iteration; there are post-publishing considerations such as re-use and retention policies that require attention.

Typical artifacts for this phase

• Publishing workflow:
  > Publishing pipeline models – Document the inclusions of content components for publishing automation
  > Transformation guidelines – Set out the transformation scripts that migrate content between formats, such as XSLTs
  > Review policies – Govern the workflow and responsibility for content review and the mechanism for re-use, as-is or revisions
  > Retention policies – Govern the sunsetting, archiving, and deletion of content.

Feel the Content Lifecycle Excitement

The notion of a content lifecycle is comforting to anyone involved in content. It creates order from chaos, predictability for content production and maintenance, and a mental model to explain content to others.

Not only is it comforting, it’s exciting for design, development, and business stakeholders. Business runs on predictable, repeatable processes, and content lifecycle adds content to the roster of replicable models. For designers and developers, content lifecycle is a tool and an extension of the user-centered design process. For businesses, a content lifecycle is a model in which content can be quantified and ROI measured—exciting stuff, indeed.

Most exciting of all, the content lifecycle helps users get the content they need, when and how they need it—the holy grail of their content search.

Apply the Content Lifecycle

While all content has a lifecycle, not all lifecycles are created equal. A given site may present several content genres—marketing, technical, legal, and so on—each with its own lifecycle, and variations on those lifecycle within content types. Some content, such as a privacy disclaimer, is used once and gets reviewed on a regular schedule. Other content gets aggregated from multiple databases for presentation as an integrated unit—for example, product descriptions sent by vendors, pricing from an ERP system, and a publishing cycle with multiple dependencies, from promotional schedules to geo-boundaries. In the world of technical content, an entirely different set of tensions inform the content lifecycle. Conditional processing, re-use maps, and publishing pipelines are of paramount importance. Nevertheless, in whichever camp the content fits, recognizing a content lifecycle exists is the first step to making the lifecycle clear—and to making the most of your content.

Many a scientific study has been commissioned and conducted exploring the fascinatingly complex cognitive process we go through when we read. One long-standing theory, first proposed in 1886, centered around the idea of rapid pattern recognition and recall—known as the word shape recognition model[1]. It was believed that repeatedly exposing our eyes to the pattern or shape a single word would form enabled us to quickly recognise and recall it from memory. Further weight was lent to this theory when it was proved that letters could be more accurately recognised in the context of a word than in isolation—known as the word superiority effect[1].

Figure 1 – Parallel letter recognition model | Adapted from http://en.wikipedia.org/wiki/File:Word_superiority_effect.svg

For example, we’re more adept at recognising the letter C in the context of the word “content” than in the context of something unfathomable as “ncotetn”[2]. This was successfully counter-argued when, in 1977, it was demonstrated that even a word that, by way of a recognisable structure and phonetics, appears to be an actual word in a certain language “pread” could be recognised faster than its jumbled counterpart “erpda”. This proved that the word superiority effect wasn’t caused by the shape of the word, but rather the existence of regular and familiar letter combinations[2]. In fact, it’s this model of parallel letter recognition (see Figure 1) that most psychologists now widely accept as the most accurate.[2] Rather than recognising patterns we’ll simultaneously decode the features (lines and curves) of a word’s individual letters before rapidly matching the exact position and order of each letter against words we already recognise.

The use of increasingly sophisticated eye-tacking software has greatly improved our understanding of the short, rapid movements, or saccades, our eyes make as we read. Imagine one such step as a pseudo-Venn diagram (Figure 2), with two blurred sets overlapping with one another to create a third crystal-clear central area. It’s this center-most point, called the fovea, where our intensified attempts at word recognition take place, with the blurred area immediately to the right beginning the process of gathering information about upcoming words.

Figure 2 – One step in the series of short, rapid movements our eyes make when changing focus from one word to another

Create comfortable reading conditions

Of course, not everyone approaches reading in the same way. Plenty of methods exist, from subvocalization, when an all-too-familiar voice in our head helpfully relays what we’ve decoded[3]; to speed reading, when our ability to fill in the missing information using context and identify words without having to focus on every letter, is tested to the extreme[3]. But no matter which method we use for decoding text on a printed page, computer screen, or handheld device, we’ll spend much of our mental energy capacity trying to comprehend what we’ve read[4]. Whether we’re successful—or, more accurately, satisfied —with our interpretation will largely depend on our:

• grasp of the content’s language and cultural origin
• familiarity with the subject matter
• ability to retain information, which can be adversely affected by factors such as location, lighting, and fatigue
• motivation to scale the learning curve.

To encourage user comprehension of our own written web content we’ll try to create conditions conducive to comfortable reading. We’ll ensure there’s sufficient contrast between foreground and background colors, try not to marry too many different styles on individual pages, and avoid centrally aligned and fully justified text for consistent word spacing. Where applicable, we’ll also make use of visual aids to enhance contextual understanding. Those visual aids may include images, illustrations, charts, audio, and video, and can be used in a supporting role or as a direct alternative to text.

Of course, the conditions we create will not always be suitable for everyone. Users with certain requirements may need, or choose, to wrestle back control over the way text content is rendered. Font substitutions along with alterations to the size, space, alignment, and color can all be achieved with visual reading assistants, such as screen magnifiers[5], personal style sheets, or more recent innovations such as arc90’s readability bookmarklet (Figure 3) and the new Safari Reader.

Figure 3 – The Readability bookmarklet allows users to remove the clutter around the content they’re reading

Define or avoid industry-specific terminology

As well as readability prepares the ground for comprehension, readability can’t necessarily guarantee comprehension. If our web content requires a successful marriage between the text’s readability and the user’s prior knowledge of and interest in the subject matter, then what if the content’s language is strongly associated with a particular discipline or technology area? Such content, while perfectly readable and comprehensible to those with close ties to that subject area, can prove problematic, with attempts to deduce meaning potentially compromised by a series of unrecognisable words, phrases, and acronyms.

One solution is a website-specific glossary of terms. A glossary can provide not only a comprehensive definition of each term or phrase, but also sufficient additional material to enable the user to understand that term’s contextual importance. Safe within the confines of our own particular profession or technical field, we often rely on a short-handed vocabulary of uncommon or specialised terms in a bid to save time, space, and energy when communicating with similarly experienced and informed individuals. But while this colloquial lexicon may be appropriate for most members of our intended audience, the use of such terms on a public-facing website or system may present obstacles for non-specialist readers, beloved first-time visitors, or people with learning disabilities.

Clearly mindful of this, the online shoe and clothing shop Zappos.com has provided a glossary page (Figure 4) that lists expansions for the commonly used terms, acronyms, and abbreviations used throughout the Zappos.com website. For the people entrenched in this industry – including those tasked with planning, creating, delivering, and maintaining content for the website and other media channels – the use of such terms and their precise meaning could be taken for granted when, to a cross section of your users, the terms may mean a multitude of different things entirely. As much as it effectively lifts the lid on the language of the industry, Zappos.com’s glossary of terms gives the user the added confidence that the sum result of his interactions, which may be ordering and receiving a new pair of shoes, will meet his now “educated” preconceptions. The glossary also allows Zappos.com a certain degree of freedom to use the terms on the website instead of having to find an alternative, and possibly longer, way of clarification – or trust that the user will carry out his own investigations whilst at the critical point of purchase.

Figure 4 – Zappos.com’s glossary helps the user learn industry-specific terms and phrases

Offer pronunciations where meaning depends on it

Certain learning disabilities, such as Dyslexia, can make it more difficult to understand figurative language: where the departure from literal meaning cannot always be interpreted without familiarity with the overall context or until acquiring more information about it. This challenge is never more evident than when attempting to cross into unfamiliar cultural and linguistic boundaries. Let’s face it; the English language is rather unforgiving at times. We have several heteronyms (words that are spelled the same but have different pronunciations and meanings), such as the words lead (to guide/dense metal) and wound (injury/to encircle). Oftentimes, the meaning of such words or characters can be confidently determined from the context of the sentence or from the subject matter itself. However, for more complex or ambiguous sentences, or for some languages, the meaning behind a word or phrase cannot be easily determined, or determined at all, without first knowing the pronunciation[6].

Glossaries can also provide users with the information required to pronounce certain terms. Comhaltas Ceoltóirí Éireann (Gathering of Musicians of Ireland) is a non-profit group involved in the preservation and promotion of traditional Irish music. As the group’s website and organisation frequently use Irish language terms, the group has made the pronunciation of each word, with text and audio delivery, available via a separate glossary page (Figure 5). It’s this auditory approach to aiding comprehension that would also greatly benefit some people with Dyslexia, who don’t always attribute the main cause or factor to vision but rather to phonology (how the person converts what he sees into the sound units that make up a single word)[7]. To understand pronunciations, some people with Dyslexia benefit from the synthesised voice output from a screen reader, which they use whilst decoding text content on the web, or when using a software application.

Comhaltas Ceoltóirí Éireann's glossary includes the ability to listen to pronunciations

But on occasions when a sentence is read aloud and the screen reader reads a word using the wrong pronunciation, the result may be a greater number of different interpretations and conclusions for a partially sighted or blind user who relies on this assistive technology for reading on the web. Depending on a website’s audience, and in particular for non-native English speakers, there may need to be additional information on the pronunciation of certain words or phrases. In such cases, a separate glossary page,  like the example shown on Comhaltas Ceoltóirí Éireann’s website, or an inline pronunciation applied to the first occurrence within a single web page make for ideal supporting material.

Don’t leave some of your audience behind

If simplicity, as Plain English advocate Alan Siegel defines it, is a means to achieve clarity, transparency, and empathy[8], then in addition to employing the clearest and simplest written language appropriate for the type of content we’re delivering and the audience to whom we’re delivering it, we should also:

• explain procedures with step-by-step guides and flow charts
• provide definitions and expansions when the subject-matter, language, or culture warrants them
• summarise visual information such as the data, trends, and implications of charts and graphs.

Does providing this supporting material mean a web content strategy is flawed? No, quite the opposite. Even a technically sound website that allows its users to access its content by way of sight, sound, and touch (via assistive technology such as a refreshable Braille device[9]) cannot be considered usable let alone accessible if no one is able to accurately judge the functionality, purpose, and, to an extent, limitations of its content.

Never before have we had so much control and choice over how our web content is delivered and displayed. One minute we could be using a mobile device while sat in a noisy, crowded train carriage and the next we’re using a desktop computer in the more tranquil surroundings of our own home; two reading conditions that call for different levels of concentration and yet we’re often trying to consume the same written web content in order to complete the same interactions. The challenge we’re increasingly faced with is providing an experience befitting of these different conditions. We need to design interactions that respond to context; thinking as carefully about where our users will be when they need us and their likely state of mind just as much as we ever have about who they are. But regardless of ambient conditions any successful web-based interactions will always hinge on the user’s comprehension and interpretation of what, why, and how.

References

1. http://en.wikipedia.org/wiki/Word_superiority_effect
2. http://www.microsoft.com/typography/ctfonts/wordrecognition.aspx
3. http://en.wikipedia.org/wiki/Reading_(process)#Methods
4. http://www.w3.org/TR/2008/WD-UNDERSTANDING-WCAG20-20081103/meaning-supplements.html
5. http://www.doit.wisc.edu/accessibility/video/screen_magnification.asp
6. http://www.w3.org/TR/UNDERSTANDING-WCAG20/meaning-pronunciation.html
7. http://en.wikipedia.org/wiki/Dyslexia
8. http://www.ted.com/talks/lang/eng/alan_siegel_let_s_simplify_legal_jargon.html
9. http://www.dingoaccess.com/accessibility/refreshable-braille-and-the-web/

You’ve probably heard the saying “too many cooks spoil the broth.”  It implies that having lots of people involved in the production of any one outcome isn’t a good thing. The same can be said for managing large websites. In fact, “too many authors spoil the content” is a much more pertinent issue in today’s digital world. Unfortunately it’s one that’s hard to escape.

Think about where you work

In your organization, who writes your web content? Do you have a dedicated team of authors? Are they centralized, or are they spread out everywhere?

Regardless of where they sit, if you have a large website, you more than likely have many people writing content for it. You may have divisions or departments managing different sections—such as the corporate blog, product information, customer service, knowledge base, or promotional pages. Or it may take a lot of input from different subject matter experts to develop content in the first place. In either case, it can be challenging to continually produce quality content.

So what do you do?

Here are three practical ways to make things easier:

1. Create a usable style guide

In the same way site content must be useful and relevant to your visitors, so should a style guide be useful and relevant to your authors.

Don’t turn into a boring ogre who jealously guards a monolithic style guide that no one wants to use.

The bigger the style guide, the more daunting and confusing it becomes. Don’t get caught up including every possible style consideration you can think of. Instead, keep it smart, keep it simple, and include things like:

• The site’s personality and subsequent tone. Is it funny, cheeky, conservative or social?
• The correct way to spell and punctuate your organization’s name (give examples).
• The spelling and correct titles of your management team.
• How you punctuate headings and titles (choose either sentence case or title case and stick with it).
• Your stand on capitals—when it’s OK to use them for (names, divisions, headings, project names, and products).
• Other punctuation tips such as the use of apostrophes, bullets, and acronyms.
• How to write descriptive links with anchor text.
• How to link to documents or downloads, and abbreviations for common downloads.
• Clear links to other resources like the CMS user guide, metadata standards, and governance model.

Stop the bickering about style and punctuation preferences by getting the guide signed off by senior management. There will always be different opinions—don’t waste energy being the referee if you don’t have to.

There are also some fantastic (existing!) style guides available online or in bookstores. You don’t need to re-invent the wheel—choose a guide that closely reflects your organization’s style, and use it in conjunction with a cheat sheet that can be pinned to the wall of every contributor for easy reference.

2. Encourage learning and collaboration

Whether you’ve got a team sitting together or contributors scattered across the country—it’s important to unify authors so they are motivated to develop quality content.

When you have multiple authors, you also have multiple backgrounds, multiple strengths, and multiple weaknesses. The key challenge is to ensure that the strengths are shared and the weaknesses overcome:

• Get authors excited about why they are developing content in the first place. Connect the dots between business goals, website goals, and authors’ personal content goals. People learn best with examples so develop case studies to showcase success stories.
• Create a collaboration space on the intranet so authors have easy access to each other and any documentation they need to do their job—such as the latest style guide, CMS documentation, processes and forms. The space shouldn’t be closed off from others in the organization. Give it high visibility to help promote web content style and standards for everyone.
• Use the collaboration space as a learning centre, too. Add webinars, podcasts and links to content forums. If someone attends training, ask him to present or provide feedback to the group so that everyone benefits.
• Any new author who joins the organization must be trained not only in how to use the CMS, but also in writing for the web, usability, and metrics. Buddy him up with another author so he has a mentor to guide him through the process.
• Promote the notion of why instead of what. Why should the content go here, rather than what content should go here. This approach improves quality and encourages authors to be accountable for what is produced.
• Show how web content fits in with the overall communication material of the organization. If the web team sits within a dedicated web or IT area, ensure there is some sort of liaison or relationship built with the marketing area so that key messages are reflected across all communication activities.

3. Use an author-friendly CMS

It sounds obvious, but a content management system (CMS) should actively enable quality content to be produced.

Don’t get me wrong; using a CMS to manage your website is smart. You just have to understand that it won’t solve all your content worries. You have to put thought into what you want your CMS to do, and how you want it to do it.

You want a system that is easy to use from the authors’ point of view. Here are some things to consider:

• The greatest web writer isn’t necessarily the greatest information architect, so as a rule don’t let authors make structural changes to the site.
• Make it simple to keep content up-to-date by avoiding complex approval workflows for your content. It’s much better to have a simple process that everyone uses well, than a complex beast that authors do their best to avoid. Also, be wary of creating bottlenecks in your approval processes. Yes, you may need a senior manager to approve content at some point along the way—but if that requirement is going to clog up her inbox with requests, think of a better way to do it.
• Keep it easy for authors to stick with the style guide when entering content. Enforce mandatory components where you can.
• And finally…include a spell check. Sounds crazy, but I once worked on a project where a spell check in the CMS was an optional extra!

With a little planning, it is possible to have great content on a site with many contributors. Dust off your style guide, keep everyone connected, and make sure your CMS is working for you and not against you.

What have your experiences been?

I get this question a lot: How do content strategists work with IAs/designers/writers? Truthfully, they often don’t. But, they can and they should.

Not only should they work together, they should do away with the typical web project process that leaves content until last, resulting in a mad scramble. People don’t muck up web projects. Bad processes do.

Right? We define the problems, design something we think will fix them, and start building what we designed. Just before we launch the sucker, we populate the CMS with one of three types of content:

• Existing content from brochures and fact sheets haphazardly mapped to pages and components;
• Existing content from the old website that hasn’t been reviewed or edited;
• Brand new content from a copywriter who doesn’t know the purpose of the site, the audience, or whether the source content is reliable.

Boo. At that point it’s too late. And that’s when the wheels come off. But, a process that includes content strategy can help.

Here’s how:

PROBLEM #1: Great ideas, no content

I think it’s fair to say those of us who work on websites are idealistic types. We want to create the best websites ever known to the internet-using public. But, that trips us up sometimes.

As a former web writer, this scenario happened to me more than once: I got a site map and a link to the old website and an in-box full of brochures, fact sheets, and PowerPoint presentations, and was asked to write all the pages on the site. Everything was dandy, for a while. I wasn’t quite sure what source content applied to what pages, but I could deal with that.

But then, I got to some pages with no existing source content. I called my client, who said, “Oh, well, yeah, we don’t have anything for that. So, just do some research, and come up with something.”

Wrong answer. For a couple reasons:

• It takes longer and costs more to research and write content from scratch.  Most project budgets don’t make room for the additional time or cost.
• Writers can’t be expected to know which random online sources they find are credible, current, or appropriate.

A Content Strategy Solution
We’re fortunate at Brain Traffic. Our IAs are content strategists. So, we think about IA a little differently, perhaps. Here are a few content strategeristic solutions that can help with problem no. 1:

• Think hard about whether the pages you include on your site map contribute to meeting user and business goals. One way is to create a core purpose statement that guides your content choices.
• Once you’ve determined that the pages you want to include actually do “fit”, make sure writers have the source content they need to create new content. If they don’t, make sure the people who control the budget know that no source content means more time and money.
• Help your writers out by telling them what source content applies to what pages. If there’s no source content , provide possible sources they can use to write content that supports the site strategy (Those sources might be people).

PROBLEM #2: The content broke my design

I can imagine few things more frustrating than designing the perfect business-goal-driven, user-need-focused, aesthetically pleasing website and having the content make it look like crap. Yet, that kind of thing happens all the time.

Why? Because designers don’t usually know what kind and how much content their design needs to support. So, they have to guess. Or, they ask their client, who says, “We’ll plug the content in once you finish the design.”

That approach leads to oohs and ahs when the design is presented, and hisses and moans when the content is “plugged in” a day or so before launch. One of two things happen next:

• The site launches with crappy content that makes an awesome design look like vomit
• The launch is delayed to re-work the design to support the content or re-work the content to fit the design

A Content Strategy Solution
During the time I was writing this article, a client’s website launched. Client websites launch all the time. But on this particular website, the designer and content strategist worked nose-to-nose. And, the site was awesome. Here’s how it went down:

1. At the very beginning, when asking the really important questions—like what are the business objectives, who is this site for, what do those people need, and what political landmines should we be aware of—we were both in the room. Listening. Asking. Conferring. Together.
2. As my colleagues and I worked together to organize the content and surface the repeatable patterns that would make up the site, we kept the designer in the loop and asked her what she thought.
3. Before the designer started concepting, we asked our client to sign off on the information architecture, wireframes, and page outlines, to make sure all content had been accounted for and all design template needs were documented
4. While the designer was concepting based on wireframes, with specific content priorities noted and estimates of content length, the content strategist and writer wrote copy to show in the designs.
5. The designer presented concepts with content that realistically represented how the site would look live.
6. Not once did the client come back to me and say anything resembling, “This page kinda broke the design.”

PROBLEM #3: We thought you were creating the content

A few weeks ago, I was having drinks with a fellow content strategy enthusiast who works for an agency that specializes in web development. She told me about a project that had raised some red flags related to the content. When she’d brought up her concern—that the client thought the agency was creating the content—the project team brushed her aside, saying “Why would the client think we create the content? That’s their job.”

I’ll tell you why. Denial. No one wants to take responsibility for the content. People don’t know how much time writing content will take, so they have no idea how to plan accordingly.

So, what happened next? To be honest, I’m not sure. I bought her a drink and we changed the subject. But, there was probably a long discussion about why “content is not my job,” followed by a scrambling for resources, a revised project plan that pushed the launch out weeks, if not months, and a resulting website that looked and functioned great, but contained content that didn’t meet user needs or support business goals.

A Content Strategy Solution
I won’t comment on the fact that a website was being built before anyone knew what content it needed to support. What I will comment on is the simple idea that no matter whose job it is to create the content, all of us who work on the interwebs bear some responsibility for it.

Here are some things a content strategy does to help:

• Tells you how many people and how long it will take to create content to launch your website—based on things like page counts, a content creation workflow, and staff time.
• Helps you prioritize your content efforts so you focus resources on the stuff that will influence your most important audiences and help you achieve your business goals
• Gives you a plan for maintaining your content after launch so your website doesn’t become an overgrown graveyard of irrelevant content.

And here are some things developers and programmers can do. Okay. It’s only one thing: Demand actual content before you start building a website. Tell your clients that’s your process. It’ll force them to get granular about content early on. If they look scared, send them to a content strategist.

PROBLEM 4: Underpants on the outside

I like to say underpants in a professional setting. It makes me giggle. Ok, back to business. I tend to use the underpants analogy to talk about two scenarios:

1. A company’s website is organized the way the company is organized, but not the way the site’s users think about the content.
2. It’s apparent from a quick glance at a homepage that departments and executives are fighting with the web team for prime space on the home page, without considering users’ needs or what will drive business results.

Imma talk about the second one. When that happens, you end up with a lot of junk nobody cares about—or, if they do care about it, they’ll never know because they don’t know it’s for them. That’s when they hit the back button and make their way to the next link in Google’s search results. Lost opportunities abound—sales not made, relationships not built, brand not recognized. Dang.

A Content Strategy Solution
Here’s the cool thing about content strategy. It doesn’t just tell you what content should go on your site, but it answers a whole bunch of other important questions:

• Why should it go there? Or, how will it help you achieve your business goals?
• Where should it go? Or, how should it be organized so people can find it?
• What format should it be in? Or, what’s the most effective way to communicate it?
• How will it get there? Or, what are the people resources, tools, and workflow needed to make it all happen?
• How much should there be? Or, what can we realistically produce and maintain?
• How do we decide? Or, who is involved in content decisions and what are the guidelines we use to make them?

These questions get answered through a bunch of combinations of content strategy deliverables—ranging from editorial specifications and calendars to sitemaps and wireframes to web content style guidelines to messaging hierarchies to full blown governance plans and policies.

Why do you need them? So that you can direct content efforts rather than take orders from whomever thinks their content is most important that week. They give you the power to say no.

The moral of the story: if it’s broken, fix it

Have you heard of my friend Jonathan Kahn’s blog Lucid Plot? It’s  smart. One of my favorite smart things it has said is this:

“If your lack of content strategy is hurting the user experience, it’s time to throw out your design process and start over.”
(From Embrace Content Strategy: Throw Out Your Design Process)

It’s nobody’s fault that the people building websites back in the 1990s borrowed from the only processes they were familiar with. Print. Advertising. Software Development. But, it is our responsibility to acknowledge that those processes don’t work and come up with something better.

In almost every situation, a good process starts with content.

We love content strategy. Why? Because content strategy solves problems. Lots of problems. And during this week five leading content strategists from four countries will tackle a different set of challenges, just for you.

So what type of articles can you expect? Let’s check out what each day will bring:

Monday: Problems with Owning and Organizing Content

Today, Meghan Casey of Brain Traffic explains how content strategy fixes immediate problems from breaking designs to showing your corporate “underpants.”

“I get this question a lot: How do content strategists work with IAs/designers/writers? Truthfully, they often don’t. But, they can and they should. Not only should they work together, they should do away with the typical web project process that leaves content until last, resulting in a mad scramble. People don’t muck up web projects. Bad processes do.”

Tuesday: Problems with Creating Consistent Content

On Tuesday, Sally Bagshaw of Snappy Sentences shares how to create good content consistently, even when you have many cooks in your content kitchen.

“You’ve probably heard the saying “too many cooks spoil the broth.”  It implies that having lots of people involved in the production of any one outcome isn’t a good thing. The same can be said for managing large websites. In fact, “too many authors spoil the content” is a much more pertinent issue in today’s digital world. Unfortunately it’s one that’s hard to escape.”

Wednesday: Problems with Understanding Content

On Wednesday, Richard Ingram of ingserv explains how content strategy solves the problem of accessible but incomprehensible content, a critical consideration for universal design.

“The process of publishing content, particularly when it includes content destined for the web, continues to be a mysterious process for corporate stakeholders, and sometimes for those involved in the process of publishing.”

Thursday: Problems with Strategic Planning for Content

On Thursday, Rahel Bailie of Intentional Design addresses the problem of underplanning for content by walking us through the content lifecycle.

Friday: Problems with Evaluating Content

On Friday, Clare O’Brien of CDA helps us understand what the numbers mean with her contextual approach to content evaluation.

“Something that’s fascinated me about online metrics since I started working in online (quite a long time ago in internet terms) is their immediacy. In fact, it’s their instancy… this real-time sense you get from actually watching people move in and out of a website or email or mobile platform—that really mesmerises. The numbers create a kind of certainty about the clicks, impressions, traffic volume… and based on those numbers we believe we can know what worked (or didn’t work). On the basis of these metrics we do more or less of the same.”

Special thanks to Jeroen van Geel for inviting this useful and international look at content strategy.