CMS developers: Eat your own dog food!
How to become a better CMS developer by walking a mile in your clients' shoes.
Dogfooding basically means that whatever product or service you're selling, you should be willing to use yourself - as an endorsement of its quality and capabilities.
In the CMS world, an example could be an Episerver partner adopting Episerver for their own company website. In general software terms, it means developers should try actually using the sites/apps that they build for their clients.
As developers, we tend to be very focused on the technical quality and maintainability of our code, but often we don't pay enough attention to the usability aspect. After all, what we build ends up in the hands of real people. An editor doesn't care how refactored your code is*, she cares about how intuitive and efficient her workspace is - and how quickly she can get stuff done.
(* Though project stakeholders will care if your spaghetti code makes site maintainence cumbersome and costly!)
To avoid developer tunnel vision, try to see things from a user perspective. It will challenge how you think about building sites.
1. Do customer support on a variety of solutions
Seriously - go volunteer for a week's duty on your support team. Real feedback from real users keeps you on your toes. Reading other people's code and interpreting their mindsets will broaden your horizons.
-
See how a feature can be implemented using different patterns.
If you churn out identical solutions every time, you won't improve much. There are always more than one way to implement a given feature, and you can learn a lot from studying your colleagues' work.
-
See how the UI of a feature can affect usability.
Users come in all experience levels, from novice editors to hardcore site admins. Study different UIs to make them as simple and intuitive as possible - ideally, so simple your grandmother could use them.
-
See what works for the editor, and what doesn't.
Developer assumptions about usability generally suck. Believe me, customers will tell you when a feature is too cumbersome in their daily work. Use that info to simplify and streamline wherever possible.
2. Hold a training course for editors
Teaching an audience about a solution you've made should be a breeze, right? Yeah, unless they don't understand what you're trying to show them.
-
Interact with users of various experience levels.
Learn how to substitute technical terms with plain language. This is a skill that will benefit you every time you interact with someone who doesn't speak geek - whether you're doing sales, support or discussing specifications with your clients.
-
Watch how real users interact with your solution.
They will always try to use and combine your content types in ways that you as a developer didn't expect, or have a different idea of how your properties should be presented to them.
-
Let user frustrations inspire you to do better.
Seeing aspiring editors fail at using custom or built-in Episerver features will give you ideas for which areas need to improve. You might end up building an awesome replacement plugin for a core feature (in which case, share it on Episerver World, will you?)
3. Create real content in a site made by your team
There's a reason why "by engineers, for engineers" isn't a compliment when it comes to usability. Your feature fulfills the technical requirements, but would an editor give their stamp of approval?
-
Uncover pitfalls and limitations.
Create a few pages of realistic content to check how page types, blocks and user permissions are set up. Are you allowed to create the content types you need, wherever you need them? Do editors have too much freedom with blocks - or not enough?
-
Uncover bugs in previewing, responsiveness and performance.
Are there sensible previews for each block type? Are the proper styles applied during on-page editing, or does it look a mess before publishing? How's the page tree performing when there are hundreds of content items under the same node? Does the image editor have sensible size presets available?
-
Uncover problems when content starts piling up.
Putting all News Article unstructured directly under the News List node wasn't a problem for your two test pages during development - but 3 months later, editors are struggling to find their way through hundreds of News Articles. Did you even set a default sorting criteria for the News List?
4. Keep your company/personal website on the latest CMS version
In the spirit of dogfooding, at least one of your own "mission critical" sites should use the same CMS that you recommend to your clients.
-
Gain first-hand experience with the upgrade/install process.
Docs are great, but practical experience is better. Doing a few upgrades on a real site will help you put those release notes and breaking changes in context.
-
Be able to provide more accurate and honest estimations for your clients.
Working with the latest CMS version will remind you which features and processes take time to implement correctly. It will help you avoid those overly-optimistic (or over-inflated) estimates when clients ask about the cost of upgrading.
-
Find the bugs before your users do.
Most new versions come with a few bugs that slipped through testing. There will likely be fixes available shortly, but being aware of these issues will help you decide whether to find workarounds or to postpone upgrading your clients' sites.
-
Refresh your editing skills and UI knowledge.
CMS features change and evolve all the time, and you should be fluent in using them to discover their possibilities and limitations. So you've read about the new Projects feature - but could you demo it?
5. Do demos and technical pre-sale
What seems clear in your head, doesn't necessarily come out as you intended. Getting feedback on your presentation skills will help you understand what it takes to convey concepts clearly.
-
Do technical demos for other developers.
Presenting for developers in-house or at seminars will help you express your ideas in a way that others can understand. If your audience don't get it, you either need to work on your presentation skills - or your ideas just aren't all that good*.
(* Or... your ideas are just too genius for mere mortals to comprehend.)
-
Demo CMS features for non-technical audiences.
If casual editors can use a feature after seeing it in action once, that's a good gauge of its usability. If they lose context, pick the wrong content types or just plain old can't find that button, it might need a bit more work.
-
Answer technical questions in RFPs or sales pitches.
Ambitious prospective clients will throw all sorts of curve balls at you, forcing you to see challenges from their perspective. This will help you understand how to best implement their requests.