Speaking in Code: Part 3

This is part three of a three-part series on how to organize an in-house Digital team around the process of website creation and explain this framework to clients. In Part One Matt provided a vision of setting up a project to succeed. Part Two discussed the execution of that vision. In Part Three, Matt talks about presenting the final site to the client and all that follows.

As the demand for websites grows, budgets shrink and ambiguity reigns, the value of a comprehensive digital division within an in-house studio is continually rising. Yet delivering websites comes with its own unique types of challenges, not least of which is how to talk about websites. In Part One of this essay we discussed discovery and design while Part Two dealt with execution and quality assurance. In Part Three, we’re tackling user acceptance testing and maintenance.

Phase Five: User Acceptance Testing

During User Acceptance Testing (UAT), your client is responsible for identifying issues and giving you sufficient details to address them. To be clear, without your help, they can’t do this; you have to make it easy for them. We give our clients a testing script with scenarios they can follow in order to test our solutions. By keeping the scripts basic, over time you’ll find they can be reused for different projects. A script needs to explain what the client is testing, how to test it and what constitutes a passing test. It also has to provide latitude for the client to try out variations of the testing scenarios and provide observations.

Common mistakes and best practices in user acceptance testing include:

Test scripts are meant for functionality. Don’t try and script every action on a site. It is sufficient and preferable for example, to provide a matrix for a site’s main navigation and then instruct the client to “try using the navigation bar to access different pages,” while recording their observations in the form. Over-engineered test scripts are annoying for the tester and lead to a ton of duplicate entries of issues where only one observation was necessary.

Instruct the client to record what they did and avoid speculation. Make sure they understand the developer will recreate their steps in order to recreate the issue. Missing information will prevent effective remediation so it is far more useful to record precise details than to speculate as to the issue.

When explaining what the current script tests, try to be specific as to the scope of the expected behavior. Consider providing a separate place for feedback that isn’t specific to the scope of the test. Most of that feedback will end up being classified as out-of-scope and thus can’t be remediated without a change order. Although a lot of this will need to be discussed on a case-by-case basis with the client, it’s helpful when your test scripts already define what feedback is likely to be out of scope and also encourage the client to consider that by them making it clear what is in scope, it will cut down on the volume of out-of-scope issues you need to address.

Phase Six: Maintenance

Websites are living things that evolve and adapt to meet objectives over their lifespan. Invariably, during discovery, we learn about some objective the client has that requires the users of the website to change their behavior. Change management requires a long-term strategy and there is no better way to support a prolonged campaign than through a website. While you’re initially being asked to build the platform that will serve as the base for your client’s promotional campaign, it is reasonable to assume that your studio can and should play a strategic role in the tactics as well.

The foundation of maintenance programs is actually flushed out in discovery. The Business Requirement Documents (BRDs) we write always include details around content management and will often include the ability to add news and events, generate electronic newsletters sent to an email list and provide users the ability to collaborate by virtue of social functions. By including these types of features in the platform, it’s implied the client intends to leverage them to promote cultural change.

The components of a maintenance program include a content calendar, copywriting, light graphic design and site curation. Discuss with your client which of these services you can provide and come up with a plan that is complementary to the tasks they can manage themselves.

Common mistakes and best practices in maintenance include:

Waning commitment is a biggie. Behavioral change takes time; use the site and content to reinforce the benefits for the user to adopt the new behavior. Commit to it.

Many clients are leery of a public, visible revolt, and for that reason, will shy away from social components. Yet publicizing complaints gives the audience ownership over their solutions which improves adoption. It also affords your client the opportunity to drive the narrative out in the open. In addition, some complaints will be valid and your client should welcome the opportunity for constructive feedback and an opportunity to respond.

Don’t forget metrics. Use analytics to see what’s working and inform decisions in the next content calendar.

Series Conclusion

By speaking about a web project in terms of these six phases you can connect clients of all levels of experience to answers for their concerns. The internet is just another medium like print and while the medium itself might be mysterious to some, the methods we use to work in the medium can be easily understood by everyone.

Matt Galemmo, the Interactive Team Lead within the Cella Studio at Merck Creative Services, grew up embracing the internet revolution in the 90s and has dedicated his professional career to discovering practical applications from the technological to the theoretical. Having worked in publishing, commercial marketing, learning and development, and now pharmaceuticals, Matt has made it a habit to habitually rethink challenges, embracing change, and drive organizational evolution.

Comments are closed.