Cultivating Content: Designing Wiki Solutions That Scale

8 November 2013

Cura%ng Content: Designing Wiki Solu%ons that Scale

Rebecca Glassman Opower Product Documenta6on Manager

Opower •  So9ware company that partners with u%li%es that want to help their customers save energy

•  6 minutes

•  Mo%vate people to pay a?en%on and change their behavior

3 Terawa?s Saved $325,000,000+

Products •  Printed Home Energy Reports

•  Email Reports

•  Web, Mobile, and Thermostat Apps

•  Alerts •  Many more!

Opower Product Docs •  Audiences

–  Opower employees

–  U%li%es –  U%lity customers

•  Deliverables –  Confluence knowledge base –  Online help –  API guides – Many more!

OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE 6 8 November 2013

The Best Laid Plans…


One month

100,000+ views

= 121,000 Page Views


The Best Laid Plans…


25,000+ Pages

600+ Month

Hyper-‐growth is a hyper-‐problem for

knowledge management.

Opower at Scale

•  Hiring and onboarding constantly •  Mul%ple product lines

•  Itera%ve development

•  Interna%onal clients and offices

•  Specialized teams

Knowledge management enables

hyper-‐growth.

•  Symptoms of scaling problems

•  How you can uncover root causes

•  Real solu%ons to solve similar problems

You might have a scaling problem if…

you get the bad wiki buzz.

Can’t find what I need

Search doesn’t work

Missing informa%on





Too much informa%on

Missing informa%on

Old informa%on

Keep ge`ng lost





Duplicate informa%on

Don’t know where to start

Too much informa%on

Missing informa%on

Old informa%on

Keep ge`ng lost

Don’t know if it’s current

Don’t understand how ranking works


people start hoarding informa%on.

“I’m going to save this informa%on in a Google Doc, so I know I can get to it later.”

You might have a scaling problem if… people request new knowledge sharing tools.

“I can’t find anything on the wiki. Let’s buy another tool instead.”

Too Many Tools


major influx of product ques%ons. “I’m not sure if this is current. I’m going to check with the Product Manager.”


people start making more mistakes.

“I didn’t know I could only sell that feature in the US. It didn’t say so on the wiki page.”

Manage your wiki like a product.

Unearth Root Causes 1.   Stakeholder interviews 2.   Metrics

3.   Usability tes%ng 4.   Ques%on tracking 5.   Knowledge mapping

Interviews: Groups •  Different roles •  New hires and experienced •  Tech and non-‐tech •  Browsers and contributors •  Management

Interviews: Ques%ons •  How o9en do you use the wiki? •  What frustrates you about the wiki?

•  What other systems of record do you use?

•  What are the five most important things your team needs on the wiki?

Interviews: Results •  Frequency of use: varied by group •  Frustra%ons: credibility and accessibility

•  Other systems: too many

•  Cri%cal content: product limita%ons

Metrics: Google Analy%cs

More Metrics

View Tracking Macro Usage Macros

Easy Usability Tes%ng: Method •  Schedule 15 minutes

•  Ask them to answer a ques%on

•  Observe how they answer (2 min. max)

•  Ask 5 more ques%ons

•  Repeat with 5+ more people

Easy Usability Tes%ng: Ques%ons •  Did they search or browse? •  What keywords?

•  Where did they start?

•  How many levels deep?

•  Did they find the answer? •  If not, what did they expect?

Easy Usability Tes%ng: Results •  55% TOC, 45% search •  Users skip landing pages •  Users only check top 2-‐3 results

Ques%on Tracking V.1: Simple Journal 3 PMs for 3 weeks =

80 ques%ons from 37 people

Ques%on Tracking: V.1 Results

42% 58%

New hires

Veterans 50% 50% Same 8 people

Everybody else

55% 45% Easy Hard or

Missing 43%

40%

17% TPM

EM

Other

Ques%on Tracking V.2: JIRA Agile Rapid Board

Knowledge Mapping Role of Employee

Type

of P

rodu

ct In

fo.

What did I forget?

Your Business Case

Model your wiki a9er a Na%onal Park.

1. Sustainable: Easy for your team to maintain.

2. Accessible: Easy for everyone to find.

3. Credible: Easy for everyone to believe.

The BOOK

•  Internal Guides

•  Client Guides

•  Product Roadmap

•  Opower Glossary

Sustainability 1. Only what’s cri%cal •  Use templates

•  Exclude “extra” info. 2. Plan for maintenance •  Build snippets library •  Mul%-‐excerpt & archive macros

3. Allow contribu%ons •  Set boundaries •  Ad hoc workflows macro

Ad hoc Workflows Macro

Accessibility 1. Search and discovery •  Create mul%ple paths

•  Target content by role

2. Lessons from UX •  Toc < 3 levels •  No content only on landing pages

3. Other systems of record •  Incorporate data •  Keep people in their workflow

BOOK TOC

Credibility 1. Set cri%cal content apart •  Keep it in different space •  Suggest space search

2. Brand it •  Add a logo •  Use unique colors and layout

3. Promote it •  Get endorsements

•  Go on a roadshow

Results “This is going to help Opower be a be?er company.” -‐ Execu%ve

“The BOOK looks great. Using it daily already!” -‐ Client Engagement

“BOOK = RAD” -‐Technical Staff

30 Day Metrics

Welcome Page 10X •  Old = 134 page views

•  New = 1,469 page views

4th Most Popular Page

Alerts Guide Page 7X •  Old = 43 page views

•  New = 294 page views

Solu%ons Summary

•  Use knowledge management to enable hyper-‐growth.

•  Manage your wiki like a product.

•  Model your wiki a9er a Na%onal Park.

= Page views

OFun on the Wiki

1.   What if I don’t have enough people or resources?

2.   What if I can’t afford plugins?

3.   What if I can’t get cross-‐team consensus on a

solu%on?

4.   What if I don’t have support from management?

Any ques%ons?

Text code below to 22333 or visit http://bit.ly/197j4mC

Cultivating Content: Designing Wiki Solutions that Scale

To join this session, send text 136888 to 22333

AWESOME = 2T

PRETTY GOOD = 2S

NOT BAD = 2R

MEH = 2Q

Rate this Talk

Cultivating Content: Designing Wiki Solutions That Scale

Technology

Transcript of Cultivating Content: Designing Wiki Solutions That Scale