Columbia Basin Trust

I undertook a comprehensive research project for the Columbia Basin Trust to help them:

  • Gain an understanding of the Trust’s business needs
  • Develop a process for identifying all requirements for a future site redesign
  • Research the existing online presence
  • Solicit input and feedback from various stakeholders
  • Provide recommendations on platforms/technology
  • Identify requirements, including functional and non-functional needs for technology, design, content, user experience, platforms, and maintenance

My work included: a heuristic evaluation and competitive audit, web survey, web analytics review, stakeholder interviews with internal and external stakeholders, and a requirements and technical recommendation.

Heuristic evaluation and competitive audit

I evaluated the Trust site against eight usability and design principles including navigation, labelling, design consistency, organizational clarity, readability, task facilitation, and mobile support. Using a three-point scale for each heuristic, the site was scored on whether it did not meet, partially met, or completely met these established design principles. I also conducted a competitive audit to uncover what similar organizations were doing online, reviewing 11 sites from like-minded organizations that were identified in collaboration with the Trust, and evaluated them based on content, key functionality, tools and capabilities, and communication tactics that could improve user experience. Following I provided a detailed set of recommendations.

Screen Shot 2016-06-29 at 9.13.33 AM

Web analytics review and web survey

We undertook a comprehensive review of the Trust’s website analytics data over a six-month period to gather and analyze data about how users were engaging with the Trust site. This information helped us identify and validate what content people were using, where they left the site, and if they were getting to the information they Trust wanted them to find. From this analysis, we also gathered technical considerations such as browsers and mobile devices the Trust would need to consider supporting.

CBT web survey

I worked with the Trust team to create a 12-question survey that could be accessed on the website or via a link sent out in their widely read newsletter. This provided additional details about the current site usage and content that was important to their communities and stakeholders.

Internal and external interviews

I talked to both internal and external stakeholders in order to get a complete picture of how successful the website is in meeting their needs, and to pinpoint areas that needed short- and long-term improvements. Both sets of interviews helped us uncover business requirements (both functional and non-functional), and identify user experience and content issues.

For our internal interviews, we met with each of the Trust departments and asked them to describe their roles and how they currently interact with the website. Then we drilled deeper to identify pain points, current challenges and problems, future needs, success criteria, and target audiences. It also helped us re-validate some of the feedback we had from prior research, including our heuristic and competitive audits and web survey.

We also conducted interviews with participants who represented the Trust’s target audiences and key external stakeholders. These sessions, conducted remotely, allowed us to validate the specific needs and concerns of external stakeholders.

Overall findings

cbt-sticky

Personas

I created four personas for the Trust, providing a strong research tool to inform future project work. Each persona captured information about their technology usage and access, pain points, needs, wants, motivations, and goals.

cbt-personas

Business requirements

Writing a successful RFP requires detail, but too much information can just confuse the process. During the stakeholder research we gathered a complete list of functional and non-functional requirements that we prioritized based on the MoSCoW technique. The key letters in the acronym stand for “Must,” “Should,” “Could,” and “Won’t/Would,” in evaluating how necessary each requirement is for a successful final solution.

Finally, we provided the Trust with some guidelines on how to structure its RFP and evaluate proponents’ proposals, so that it could be confident in choosing the best vendor for their redesign project.