Creating Content Based on Customer Scenarios

 

CIDM

August 2007


Creating Content Based on Customer Scenarios


CIDMIconNewsletterSamantha J.W. Robertson, Microsoft Corporation

Introduction

I’m part of a team that creates content for IT professionals working with SharePoint Products and Technologies. At the Best Practices Conference in the fall of 2006, I described the work that my team has been doing with customer scenarios: creating, refining, and using scenarios to scope and target the content that we create for our products. This article provides an overview of that work and also talks about how we are adapting this approach going forward.

Wanted: A New Approach to Planning

Traditional content planning involves activities like the following:

  • listing all the product’s features
  • listing all the tasks you expect users to perform
  • listing the topics you’ll need to write to address all the features and tasks
  • scheduling the writing of those topics

Our product set has hundreds of features that can be used for radically different purposes, depending on the customer goal. Our first attempt at traditional content planning left us with a giant task list, an even bigger topic list, and no idea how we could address all of them.

In addition, we had received a lot of feedback from the IT audience that our traditional content lacked focus around our audience’s needs and goals. They wanted specific and clear guidance for approaching a task and recommendations based on best practices. We weren’t giving customers the big picture; we didn’t really have a good grasp of the big picture ourselves.

So, we decided to try a different approach. Instead of starting with a list, we started with a picture. We came up with 28 solutions that can be built using our products and created Visio posters to illustrate them. Then we used the posters as the basis for our planning effort.

Created: Customer Scenario Posters

The word “scenario” can mean many things. We use it to mean a comprehensive but specific customer goal along with recommendations for using our technology to achieve that goal. In other words, a scenarios identifies a solution that you can build with our products, along with an execution plan for achieving that solution from the IT professional’s perspective. Our scenario posters don’t illustrate the end product—the web site the customer is building, for example—but rather how the IT professional audience can plan, design, and deploy a particular solution.

The scenario posters have the following components in common:

  • a customer goal and description
  • a list of the features (required, optional, or not used) needed to make the solution work
  • a recommended deployment plan— the physical topology plus how the physical parts fit together
  • a recommended process for planning the application

In addition, several of the scenario posters include other components such as a data flow chart or extranet diagrams that are essential for that scenario.

With these posters, we were able to represent a lot of complexity in a very visual format. And building these scenario posters gave us several benefits—they’re an excellent way to start discussions and a good focus for collaboration. The pictures speak for us in a way that a documentation plan never could. We use these posters to target and scope the content we will create so that we can give customers the big picture and help them understand how to use the many pieces of the product set to build the solution they need.

Poster components

The first component of each scenario is the customer goal and description. A short statement summarizing the customer goal is followed by a longer description that uses a fictional company example to elaborate on key tasks and interactions among users within the scenario.

The second element, the list of features, helps us understand exactly which of the product’s many parts came into play for each scenario. This list helps us verify coverage and prioritize content. If a particular feature set is used in all scenarios, it is deemed a “core” feature and is bumped up on the priority list. Likewise, if a particular feature is not required for any scenario, it is unlikely that we will spend the effort to create content for that feature area in the initial content set.

The third element, the recommended deployment plan as illustrated in Figure 1, provides a place for us to create prescriptive guidance about the best way to deploy a particular solution. An Internet or extranet solution has different authentication and security needs than an intranet solution, for example, and we created diagrams that showed the hardware and infrastructure required for each solution, plus a growth plan showing the best way to start with a base installation and then grow to support more connections or provide more reliability.

DeploymentPathwithScale (Robertson) bw

The fourth element, the recommended process for planning the application as illustrated in Figure 2, provides key questions to ask when planning the capabilities for the application, whether the application is an Internet site, an intranet portal inside an organization, a records management system, and so on. This section allows us to focus on the application administrator audience, one that we had traditionally not provided much content for. For example, for the records management scenario, what auditing needs to be put into place? What existing systems need to be integrated? What metadata needs to be tracked for each record type? The application administrators must answer these types of questions as they design their solution.

ApplicationPlan (Robertson) bw

For more information and to see our solution posters, go to http://technet.microsoft.com/en-us/sharepointserver/bb310619.aspx.

Process: Creating the Posters

Generating the scenarios and the posters took some time but also represented the bulk of the planning work for this product cycle. Here’s how we came up with the posters and our scenario plans.

1. Determine the most common usage scenarios
We met with representatives from marketing, the product development team, the product planners, and the internal IT department at Microsoft, in addition to customer representatives. We asked: What are the five main things you do with this product? What do you think customers will be building? What problems are these products intended to solve? What size of organization are we targeting? What industry segments are we trying to reach? This discussion generated three to five scenarios ideas for each product. The base scenarios were our starting point.

2. Research each scenario
We divided into specialties within the IT audience to research what each member of the IT team would need to be able to do a job—what does each role do in the scenario? We delved into customer roles, business goals, application usage, deployment plans, and operations needs.

3. Develop the posters
We started developing the posters, and along the way, asked questions like these:

  • Who is using the product (number of users and job titles)?
  • What is the business goal (general/for product)?
  • How do the users work and communicate (internally and externally)?
  • What is the workflow?
  • Why did they choose this product and what do they want to do with it?
  • What other products are needed or exist in the environment and need to interact with the solution?
  • What is the best way to deploy this scenario?

Along the way, we discovered that we needed to drill further down into certain concepts or subject areas. For example, database management, server topologies, and the deployment process became important. These spun off into posters of their own—models and flowcharts—that explained a pattern across all scenarios or explained a process flow for a specific phase in the IT lifecycle. We used the models and flowcharts as the structure for the information needed for each solution. For an example of a model, see SharePoint Server Topologies at http://office.microsoft.com/search/redir.aspx?AssetID=AM101639071033&CTT=5&Origin=HA101639821033

4. Analyze tasks

Now came the big question: what do we write? We did some task analysis but with a twist. We identified the key tasks that users needed to perform to be successful during each phase of the IT lifecycle (Evaluate, Plan, Deploy, Operate). We called attention to any details that needed to be tested or filled in by others (such as performance data) and iterated on the list of tasks as we received feedback.

In addition to this analysis, however, we used a tool that provided multiple views into the list so we could flag information like the following:

    • What are common tasks for all scenarios?
    • What are unique tasks per scenario?
    • What are priorities?
    • What do we share or re-use? (not only per scenario but per product)

5. Review and revise

In our team we share a set of commitments and at the top of the list is “listen.” It was time to solicit feedback and find out if we were on target. First, we worked internally to review and revise the scenarios with the original stakeholders and a few others (such as consultants in the field). Then, it was time to take them to real customers.

      • We held meetings and conference calls with customers, Microsoft’s Most Valued Professionals (MVPs), and a group we call the SharePoint Rangers, consultants with a lot of deep experience with these technologies.
      • We set up a room at the Technical Adoption Program conference, put the posters all over the walls, and talked with all the customers who came by.
      • At another event, the SharePoint Conference a few months later, we set up face-to-face “Design Time” meetings with customers. The customers submitted their goals and architecture designs ahead of time, and we brought product development team members who could walk through their designs and make recommendations. This interaction really gave us a good sense of whether we were on track with our representative solutions.

What did we learn from all this feedback?

      • We understood the customer goals and requirements better than before.
      • We revised the scenarios to better suit real-life requirements.
      • We prioritized our content set according to the high-use scenarios.

Gained: Customer Connection and Validated Plans

This work happened more than a year ago. Now we’re deep into writing and producing cycles of our work. Looking back, we see that we gained much value out of creating the scenarios and the scenario posters and from using the scenario process as the basis of our planning.

Among the benefits:

      • Immediate understanding. Because the scenario posters are so visual, customers and partners just glance at them and immediately start to talk about their situations, what they’re trying to do, and in the partner’s case, how they can add value.
      • Collaboration. Because our writing team produced them, we all understand the big picture. By the time we were done, we understood the customers, their needs, and our products much better than we could have done just by reading specs or talking with the product team. We had direct access to customers and not just second-hand information. Doing scenarios, flowcharts, and models also helped us define our writing assignments. Not only do we understand what each person is working on, we know how all of our pieces fit together.
      • Validation. Because the whole product team bought into these particular solutions, we know that they’re solid and will actually work when implemented. The Marketing messages are being built around these solutions. These posters have spread like wildfire internally and the solutions have been used for usability testing, marketing plans, and training plans.
      • Alignment. Because they’re out there, everyone knows what we’re targeting with our documentation. Microsoft Press, the marketing team, and the Solutions team can suggest supplemental content that fills in our gaps, rather than overlapping or contradicting. With this understanding, we can use our resources across teams more efficiently and appropriately.

Looking Forward: Building Targeted Content and Expanding Audiences

Now that we’ve got some good foundation content written, we’re starting to look at how we can build content sets targeted at particular scenarios. For example, we’re creating a Records Management Guide that addresses the planning tasks that must be performed when creating a records management solution—drawing from the example scenario that we created. We hope to perform the same transformation for several of our scenarios: taking them from fictional examples to guidance for real-world solutions.

Also, in the next version of our technologies, we’re looking into ways we can broaden this scenario approach to all of the audiences that our organization writes for—Information Workers, IT Professionals, and Developers. We’re exploring lighter-touch scenarios (focused on smaller-scope goals) as well as the enterprise-scope scenarios we addressed for this version. And we’re thinking about the best ways to deliver this content for each audience. Although books are a hit for the IT professional audience, they are a little weighty for Information Workers who have smaller pieces of a scenario.

Conclusion

Developing scenarios has provided us with valuable information, insights, and experiences during our content planning and content creation stages. The experience of creating scenarios and scenario-based content has given us the opportunity to understand our customers and their goals and to target our content to those goals. The process of creating the scenario posters also helped us improve the collaboration between the product team and user assistance, as we worked together to understand how customers would use the products in a real world way. And developing the information visually before we started writing helped us firm up our recommendations and best practices for using the technologies, so that we can write more efficiently. In short, we highly recommend using scenarios for creating content. CIDMIconNewsletter

About the Author

SamanthaRobertson bw

Samantha Robertson
Microsoft Corporation
samantha.robertson@microsoft.com

Samantha Robertson is a senior writer in the Office Servers User Assistance (UA) group at Microsoft. She has been writing for 15 years and has a BA from the University of Washington and MA in English from Brigham Young University. She spent the last 9 years writing about Microsoft Office and SharePoint Products and Technologies for the IT/Administrator audience. Samantha played a key role in developing the solution-based approach that Office IT UA is using to develop the content for the Office 2007 System and Office 2007 Servers. She presented their scenario-based design innovations at the 2006 Best Practices Conference.

 

We use cookies to monitor the traffic on this web site in order to provide the best experience possible. By continuing to use this site you are consenting to this practice. | Close