Gathering requirements at the start of a new website or when you launch a new feature is just as important as the testing you’ll set up for your users later. Let’s talk about why.
I’ve worn many hats over the past few years – quality assurance, business analysis (BA) and now digital strategy – and I’ve seen how important having each of these roles can be as you implement a new site. In my experience, digital marketers don’t find themselves playing a huge part in the early stages of a website implementation. BAs provide requirements for the different project areas, including those related to marketing and development, determining how implementation should be carried out. Hopefully, at the end of the project, marketers can (should) verify the work done to make sure everything requested performs as expected. Sometimes though, this might be a bit too late…
Nothing is quite like getting ready to launch a website or new feature and discovering that pages are not tagged with profile cards, or the content you wanted to test is set up in a less than optimal way or that the custom work for triggering goals has some limitations (Thankfully, with Brainjocks SCORE™, this last one has become a thing of the past. Check out what I mean by reading Introducing Experience Rules (XPR)). Like with any website implementation, there are a lot of moving parts. Making sure requirements are laid out properly, and dealing with team members who may be new to Sitecore can make things difficult. Knowing how to provide effective requirements and developing a testing plan to make sure the functionality is scalable can be an even greater challenge.
How can you avoid these limitations? By making sure marketers are included early in the process – during the requirements gathering and testing phases. While it may seem like too many cooks in the kitchen, it will absolutely save you time in the long run. Some common, easy and possibly obvious (but often overlooked) tips that have helped me with scoping requirements for a new site or component include:
- Creating a Features List: Sitecore, as well as other content management systems, often come with digital features out-of-the-box, so leverage them! In Sitecore, an often underutilized feature is Path Analyzer which allows you to create maps showing “sequential paths contacts take as they navigate through your website.” (Sitecore Documentation). Knowing that Path Analyzer is available, you may want to ask yourself, ‘Are there pages not to include for a specific reason?’ ‘Could a new map for user analytics specific to a set of pages be valuable?’ These questions can be answered early in the process – which lays the groundwork for requirements, suggests even more questions from the responses and provides test cases to make sure all works as expected for launch.
- Dissecting the Design: The creative team will design pages or individual components, the BA team is combing through the designs for development-related requirements – and your marketers should be doing similar work. Does the page present limitations because it’s a bit rigid? Do you have a hypothesis that moving page elements around could work better for your audience? See if functionality can be built in to offer varying layouts so they can be A/B tested. Are buttons contained within the component or on the page? Add functionality to trigger one or several goals and of course, allow this option to be content-editable and therefore, testable (by you, hopefully).
- Not Asking for the Moon: Having worked as a BA myself and for all of you out there who still do, there have been times when a colleague might say that a requirement has to have “all of the features possible work in every way. I need all functionality all the time! And
ineed to be able to change it on the fly”. Don’t be this colleague! Functionality and content that is too dynamic, over-complicated or lacking an end goal, especially if it doesn’t have a use case, will extend development time and make testing a nightmare. Gather metrics that your team, department andcompany are interested in, then ask the BA how to get this information. Work together on ideas for using the data rather than having a complex set-up providing possibly irrelevant data.
While these tips are not the last word on testing, having this level of involvement early on in the requirements gathering process will set you up for success. Using the requirements gathered to test your end goal will enable you to set the foundation for future tests targeting your audience and iterate more easily based on the results.
For my encore to this series, we’ll take a look at what the next steps might look like after the requirements have been gathered and your testing of the test setup has come to pass.
I’ll be back! (In Terminator-like voice!)