Shifting Structures: Changing How We Work to Support Structured Content
•Download as PPTX, PDF•
2 likes•1,276 views
This is a story about how a government organization embraced structured content that can be created once and used everywhere and changed how it works in the process.
Recommended
Recommended
More Related Content
Similar to Shifting Structures: Changing How We Work to Support Structured Content
Similar to Shifting Structures: Changing How We Work to Support Structured Content (20)
Recently uploaded
Recently uploaded (20)
Shifting Structures: Changing How We Work to Support Structured Content
- 1. michelle.chronister@gsa.gov @mchronister Shifting Structures Changing How We Work to Support Structured Content Michelle Chronister User Experience Team Lead, USAgov U.S. General Services Administration
- 3. Content & Editorial Board Teams Topic Managers Editors Marketing Accessibility User Experience Operations Board of Directors
- 4. Content & Editorial Board Topic Managers Editors Marketing Accessibility User Experience Operations Board of Directors
- 5. Print Publications and Distribution DivisionWeb Content Division USA.gov GobiernoUSA.gov Kids.gov Contact Center Services Division Answers. USA.gov Publications. USA.gov
- 6. Print Publications and Distribution DivisionWeb Content Division USA.gov GobiernoUSA.gov Kids.gov Contact Center Services Division Answers. USA.gov Publications. USA.gov
- 7. 8.9% of traffic 0.5% of traffic 90.7% of traffic Top 20% of Content Assets: 1,054 Traffic: 36,491,202 Middle 60% of Content Assets: 3,163 Traffic: 3,570,493 Bottom 20% of Content Assets: 1,054 Traffic: 190,288 Iceberg by Anton Noskov from the Noun Project (CC BY 3.0 US)
- 11. It’s hard to create content free from presentation.
- 12. We need product managers.
- 13. Measuring adaptive content isn’t easy.
- 14. People can’t be on too many teams.
- 15. Change is hard.
Editor's Notes
- I’m currently the UX team lead for USAgov which is part of the Office of Citizen Services and Innovative Technologies and 18F at GSA. Our mission is to: Broaden citizen access to high value government information and services anytime, anywhere, any way via their channel of choice.
- We created a UX team in December 2013 to improve all of the products we offer which range from: multiple responsive websites in two languages to contact center services like phone, email, and chat to print publication creation and distribution.
- The UX team was created through an internal reorganization along with 10 other functional teams.
- The functional teams are charged with supporting all of our channels, including writing and editing content in English and Spanish measuring the performance of our content and channels marketing our channels and building partnerships enhancing accessibility keeping everything running
- Before the reorganization into functional teams, our websites and other services were managed by channel or product based teams. There was a product based team that managed the contact center, including a separate website, answers.usa.gov, where you could find the content the contact center agents used to answer phone calls, emails, and web chats. This content was different than USA.gov and managed by differnet people. There was very little coordination between the teams. There were other problems too.
- Years of working this way also led to Internal inefficiencies and unnecessary costs Multiple content management systems Inconsistent standards and APIs and conflicting goals
- We also had a lot of content ROT - content that’s redundant, outdated, or trivial. Even worse, we had conflicting content sometimes. You could look on USA.gov or answers.USA.gov for the same topic and find different information. In 2012, we analyzed the content provided by our websites and our print publications and found that 90% of our traffic was to only 20% of our content. We had to change how we created content and presented it to the public.
- So we decided to move to a structured content model that would allow us to create content once and use it everywhere. We also decided to consolidate USA.gov and answers.USA.gov (as well as their Spanish equivalents) and launch the consolidated effort at beta.USA.gov and beta.GobiernoUSA.gov.
- We planned to publish our content via an API that could be used to generate our websites. It could also be used by other government agencies and external developers. So our functional teams went to work: The content teams created new content. The web operations team looked for a CMS. The UX team created and tested a new taxonomy, wireframes, designs, etc. From December 2013 to April 2015, our functional teams were very busy working on all of these projects, including figuring out how the new teams worked together. It the end, the beta sites were a total redesign from soup to nuts. We wanted to avoid this, but in order to solve some of the problems we knew plagued us for years, such as cluttered pages and complicated navigation, we had to start over.
- We launched the beta websites in April 2015 and kept them up for 2 months before they replaced the old websites. What you see now on USA.gov and GobiernoUSA.gov is our new platform. In the description of this talk, I promised to tell you if all of our plans worked. Well, we did everything we set out to do, but learned a lot along the way and made changes from our original plan. We’re still making changes and trying to make it work, but I can share some of the lessons we’ve learned so far:
- I think the biggest lesson is that it’s hard to create content free from presentation. The initial charge was for the content team to write content in a vacuum - content that could be created once and literally used anywhere regardless of presentation. After launching the beta sites, we saw that content on web pages wasn’t always in an order that we knew would best suit our visitors (and this is where the majority of people see our content - USA.gov had 23.5 million users in the past year). The order of the content on the page was automatically determined by business rules, such as place all high priority items first and arrange them in alphabetical order by title. This led to the content team sometimes gaming the business rules in order to get content to appear in a specific order - kind of like naming your business A+ Bail Bonds to appear first in the yellow pages For now, we’ve given up on the idea of a content being automatically organized on web pages. The order of content is now controlled by page owners and it’s better for everyone involved.
- The UX team is responsible for the generation of the websites, but we aren’t empowered as product managers in the traditional sense. The board of directors wanted everyone to be responsible for the success of all of our products. This was an attempt to smash the previous organizational silos. But when everyone is responsible for a website, it means no one is really responsible for a website. We learned this when it came time to QA the beta sites before launch. Every team thought another team was responsible for this task. We had to scramble at the last minute to QA the sites before launch. We’re now exploring adding product managers that would cross functional teams. We don’t want to return to the siloed product teams we had before, so there are thoughtful conversations happening about the best way to accomplish this.
- Our content is chunked into what we call assets. As I mentioned before, these assets are created once and used in multiple places. When you consider that an asset can appear on multiple pages on multiple websites in the contact center knowledge database for the agents to use when answering the phone, email, and web chats in print publications and on social media you can see the measurement challenge. We’re still trying to figure out the best way to measure and report across such a wide spectrum. The performance measurement team is experimenting with a tool called Tableau that we hope will help us pull together the available metrics from our channels and explore and visualize them in more effective ways. If you know of better solutions, I’d love to talk after this session.
- When we created the user experience team and other functional teams, everyone was on more than one team with a primary and secondary team. Some people were even on as many as three teams. The idea was that this cross-pollination would benefit the teams by increasing communication from the bottom up. In reality, people were swamped with too many projects and competing priorities from different teams. We now have a 2 team limit and have discussed limiting people to one team. The move to product managers may change this again. We’re also trying to do a better job of coordinating priorities across teams.
- This is obvious, but it’s worth calling out specifically. In the past 2 years, our organization of about 40 people has been reorganized (many people now have a new supervisor) people were placed on new teams and given new work (for some people, they little experience doing this work) The constant change has been hard on everyone. But I’ve never met a group more committed to public service and improving the lives of everyone in this country. All of us know that the change is needed and worth it.
- So that’s our story. It’s a story about how a government agency moved to adaptive content, but it’s really more than that. It’s the story of how we’re trying to change the way government works in order to better serve people. It’s a marathon, not a sprint.