It is nothing new that websites built today are optimized, tested and evaluated to improve the user experience. We A/B split test, use qualitative and quantative user research, run check-out optimizations, use AI and machine-learning to create highly personalized and effective customer experiences. As professionals we do all these things to increase the value and performance of our web-presence, there is simply a strong economic incentive to do so.
What about the experience of the people managing these highly optimized websites? What about the editors? (or webmasters as we used to call them) Behind the scenes of any e-commerce or content-driven website stands an army of people who daily spends hours creating, editing, curating, relating and managing content. Have you ever given them much thought? Optimized their experience? A/B split-tested common workflows?
The aim of this book is to look behind the scenes of todays websites, look at the life of the content editor and how we can make it better. Because this also has a strong economic incentive. With better editing experiences, improved workflows and more efficient tools, website editors will spend less hours, make fewer mistakes, be able to act proactively and be happier.
Atleast, this is my thesis: Optimizing for editor happiness will lead to more effective teams, happier clients, higher content quality and ultimately a better bottomline.
I believe that our current way of working with content editors is broken. Agencies, Customers and Developers do not optimize for editor happines, and most software vendors does not have it as part of their competitive edge.
Therefore the title Effective Content Management - when you focus on building something that is effective to use, your users can get things done, fast and feel confident and accomplished - and isn't that really what we want them to feel?
This book is very much WIP but the overall structure is currently 3 areas a detailed table of contents is available here
Determining what you will be building and why. This is all about creating the right spec. Both as a customer and as a developer/agency. Who could you take editor experiences into account when writing a tender? when you write a spec? when you start defining tasks?
General theory and background on usability and designing for humans. Tools for designing the experience for daily tasks and workflows, with a strong focus on providing simple to use checklists and prototypes for common tasks.
Introduces tools and techniques for testing the editor experience. The focus here is simple processes that end-users / customers can use to test the effectiveness of performing everyday editor tasks and workflow.
Besides the 3 main topics I will be collecting case stories from customers, agencies, developers and experts to provide context, background and stories from the trenches.
This book is intended 3 audiences:
- Practitioners building websites, designers, developers, UX people, who want to know how to plan and design tools for editors
- Customers buying and evaluating systems that involves editors, who want to ensure they get tools optimized for the people using them every day
- Agencies. Project Owners and software vendors / projects who wants to increase focus and awareness on editor experiences
People who know me, will also know that I have 10 years of history as employee and co-owner of Umbraco - a open source CMS. I would be lying if I said I wasn't biased by those 10 years. So to be clear, the purpose of this book is not to promote Umbraco or any other specific software. It will include samples using Umbraco to illustrate certain points I want to make, but it is not about software, it is about the process - infact software plays a very small role in this.
As you can see from the license, all content will be made freely available. Furthermore everything will be written in this open repository, so I will publish drafts, work-in-progress and finished chapters as they are done. It will be just as open, fun and dirty as a normal open-source project.
This also means that you can make pull-requests and file issues as normal. Maybe you know of a good case story, a person I should talk to, want to volunteer for an interview, existing writing on the subject, or maybe just correct my danglish and spelling mistakes, all contributors all go on the contributors list.