Bad news: having issues with the slider on the main page – hence the large grey empty box. The usual ‘technical difficulties, please stand by’ warning apply. Now for the good news and silver lining that arose from it: having a great WordPress developer who offers good clear support for my theme – good documentation, good support site and ticketing system, and good – heck, great – response time makes the pain of a code problem a little easier. I posted my problem last night, and woke up with a response this morning. Even to know that someone’s posted in the thread that they need more information before they can offer a solution is a sign that the problem’s being worked on – and for customer service, the perception that one is being listened to is as important as the solution itself. Reassurance that a problem has been heard matters for keeping your customers loyal – more on that in a second.
We often take for granted that there are help files, read me’s, version control logs, release notes, video screencast walk throughs and other tools of the support trade; there are still many instances, however, where the support we need to get software or any products working is sorely lacking. Think of the last time you wrestled with a product or service, especially with your technology. While there might have been a user manual, there might also not have been the kind of help that would take you to the next level of mastery – I’m thinking beyond the quick guide and manual, and onto more of the ‘tips and tricks’ that come from user forums, blogs and in person classes.
There’s an opposite danger as well, where an over dependence on support help as a bandaid to address product flaws occurs. This shows up that if something doesn’t work, somehow that the ‘documentation’ will address that rather than designing a clear, usable and beautiful product right from the outset. Like much of design, there’s a balance – having the help is important, but it’s their to address problems for the end user rather than address deficiencies in the product development. I often look to what the Technical Writers on a project are being asked to do, either officially or unofficially – are they documenting how the end user should fix problems in the product or service, or are they being used as an usability gatekeeper and QA person addressing problems with the product development itself – that key requirements were missed? Good documentation is important enough work to have as a task; having our documentation writers show the flaws in developing the products is fantastic but shouldn’t be what their primary role is since the role of creating documentation is a full time roll itself.
There may be different philosophies of how you help your user – I’m thinking of the debate between more iterative processes as opposed to Agile, where the code itself is the documentation. The point is that it’s an incredibly important part of the equation for design to make sure that how you use a product or service is supported even after the customer has purchased it and used it – both from a product use as well as marketing opportunity. When a friend asked about building a WordPress site, I pointed out both the source of my template as well as the developer I worked with – I probably would have done that even if there wasn’t the excellent support, but having that other high point to convey helped. Having had someone who took the time to walk through what the user needs to do means that you’re dealing with a professional who understands that support helps both the end user and the developer – and that’s an equation that benefits everyone.
Leave a Reply