Market leaders adapt quickly to change – competitive, technological, customer expectations, and more. You just can't adapt quickly when you need to create dozens of documents that will most likely have conflicting information and require multiple reviews before the team is able to start building anything. It is frankly an administrative nightmare. Sure, documentation is needed (see my webinar on UX Magazine: Iteration Zero: Where it all begins) – but there is a balance between documentation helping to get a project done versus documentation management driving a project and its deadlines.
I have been working with a team exploring the use of Agile methodologies for site content creation/development. This has allowed us to simplify the process, reduce team stress, be more responsive to business changes, and generally increase process (and team) flexibility. And it is scalable to accommodate a worldwide translated site.
Pre-Agile
Before we used Agile for content creation, we had a very linear, sequential process.
- Content strategy completed – for prominent site pages only.
- Content written and reviewed by marketing team as needed.
- Content submitted to publishing be made into a page.
- Page reviewed for grammtical errors and small messaging tweaks.
- Messaging changes only addressed if there was a sudden competitive change or legal issue. Messaging had to be complete by the time the content was submitted.
- Limited number of reviews (kept it to 3) – mainly grammatical updates.
- Content submitted to translation.
- Page launched.
Marketing requires a very flexible process because it is actively working with markets and customers – which change daily – meaning messaging can change on a dime. This caused a lot of problems for the business.
- Messaging had to be locked early and changes were discouraged. If there was a requirement to change messging by the business, there had to be a solid reason. This put a lot of pressure on the team to make sure everything was buttoned up 4 or more weeks before a launch. If we got sudden feedback about a market change – we couldn't address this until after launch.
- Page layout was limited and there were not a lot of opportunities for creativity. All content was written in a Word doc with the product team and writers. Writers submitted content to be "manufactured" into a page – crossing their fingers and hoping for the best. There wasn't much discussion about the design of the content to make it easier to scan. Everything was more or less fixed.
- Scope could be reduced but not increased. If there was a new requirement to change a page, there would be multiple discussions to determine if we could fit in the work (at times, if we just did the work instead of debating it, we would have saved time and gotten it done).
- Rigid schedule - If content slipped a day, most likely everything else would slip – all deliverables moved forward at the same time. The only flexiblity we had was with translation review – and even that was limited. We had little insight into where we could be flexible in the process.
- Deadlines or quality? Some team members were more focused on meeting the deadlines; some team members were focused on quality. The two groups were constantly in conflict – and not in a good way. Given the way the project was being managed, there was no prioritized value either. We needed great quality content to launch on time.
- Team stress. The deadline/quality division caused a lot of stress between team members. This made a challenging work environment to get anything done.
Something needed to change.
Move to Agile
We decided to leverage Agile for our content creation process. Rather than create stories for the content needed, we determine the general scope of the project, defined the content strategy, and created content in iterations – with iteration 1 being delivered at around 80% complete (sometimes less) so we can further iterate on-line. Basically, we scoped the "stories" as being the content we were updating.
The process became:
- UX and writers collaborated to define the content strategy and layout of the page
- The publishing team created a page with the content strategy elements as a new template. We tweaked the design on-line, in real time.
- The writers worked with the product team to deliver an initial draft at 80% in a Word document that had the general page design.
- The publishing team puts the content into a page to review on-line.
- We have daily page reviews so we are all aligned as to the final page design – we review the final page experience, tweak it to be the best it can be, and update the content to ensure it reflects final messaging.
- Once content is ready, send it to translation in bundles.
- Page launch.
- Transparency – increasing communication, flexibility - The process is now more transparent and everyone is aware of how each step of the process works – and where flexibility exists in our schedule. And direct communication between team members has improved considerably – team members feel comfortable talking directly to each other about various requests. This has helped everyone move faster and be more united as a team.
- Prioritization - We are able to prioritize our work so we deliver high-priority content to translation early and ensure that we have key content available translated and properly reviewed by launch day. We are also able to prioritize types of changes – for example, we may update layout after sending content to translation to make the translation date AND meet our launch date.
- On-time – or earlier – delivery – We now work like a clock and get things done on-time or early. Even with a number of challenges, we communicate and figure out how can we get our project done on-time.
- Working real-time online - We work on a real page so we can always test what it looks like on a browser and see first-hand if it is scannable or needs tweaking. We always know what the final product will look like throughout the process – there are no surprises.
- Reduced stress - This was probably the biggest "win" for hte team. Working sequentially required that the team followed deadlines that the business was challenged to achieve. Sure, we still try to get messaging completed early, but if that doesn't happen, there is flexibility to fix and update later. No more battles about quality vs. timeliness. Both are now equally important and addressed through prioritization.
The flexibility and transparency we have has allowed us to scale at an amazing rate. This last launch of this site was massive:
- Added a new navigation
- Started using new page templates that were more visual
- Added a product selector
- Included a new template design that was more visual and had a learning curve for how to use it
And we did run into a number of last minute challenges:
- Change to the review process to include another team
- Potential increase in scope to accommodate another team's goals (didn't happen – but we were ready to address it)
- Messaging updates
But we still made our deadlines. Why?
By adopting Agile, we are working in a different mindset. Rather than approaching a project thinking about absolutely completing one step before the other and constantly defining limits, we approach a project thinking about what can we get done collaborating as a larger team within the timeframe to achieve the goals needed. We don't think about deadlines as much as we think about priorities – what do we need to do today, how do we get that done, what can we hold for later.
It has been energizing to be on a team driven to do more and make changes. Sure, life isn't a picnic and can be stressful at times, but overall we definitely have a lot more fun collaborating to make general idea into a reality.