Columbia Basin Trust

Website requirements research

Columbia Basin Trust logo above a background image of the Columbia river
The 2,000-km long Columbia River snakes through British Columbia, Washington and Oregon, forming the Columbia Basin.

In 1964, the Columbia Basin Treaty was signed between the Canadian and U.S. governments, to coordinate flood control and optimize hydroelectric energy production in the region. As a result, more than 2,300 Canadians living in the Basin were displaced.

In 1995, Columbia Basin Trust (the Trust) was established to provide social, economic, and environmental benefits to the region most adversely affected by the Columbia River Treaty. The Trust accomplishes this through the delivery of programs, initiatives, and investments, with active participation and meaningful input from Basin residents and the community.

Project background

The Trust’s website is an important source of information that helps tie the Basin communities together, providing information about its history, ongoing projects, initiatives, investments, and more. But the site wasn’t fulfilling its users’ needs or the needs of the Trust. The Trust was in the early stages of developing a plan to address these issues and sought out our expertise to help them define their requirements for a future website project.

Working with a core project team at the Trust, we completed various user experience research activities to get insights into the needs of their users. We used that information to shape our recommendations and create a roadmap for the Trust’s future website redesign.

The challenge

The Trust staff knew they needed a new corporate website – but before they started a large redesign, they wanted solid research findings to tell them exactly what they needed to do.

The goals

  • Gain an understanding of the Trust’s business needs
  • Develop a process for identifying all requirements
  • 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
  • Help the Trust get this information into a suitable format for a future RFP

The solution

We had a broad understanding of why the Trust exists, its mandate, and its goals. But we also needed detailed insights into the site’s users: their day-to-day activities, their information needs, and the challenges they faced. To answer this, we undertook a series of research activities to uncover and define requirements, gather data (both qualitative and quantitative), and inform a set of recommendations and guidance for its RFP.


Our discovery work included several research activities:

  • Heuristic evaluation and competitive audit
  • Web survey
  • Web analytics review
  • Stakeholder interviews with internal and external stakeholders

Many of the research methodologies were new to the Trust team. As a result, we decided to involve them in the planning of each research activity – this gave them an opportunity to understand what we were doing, provide feedback, and alert us to any sensitivities to be aware of. Where possible, we also involved them in the research, so they could see the work and connect our recommendations with it. We followed up each activity with a detailed report, allowing us to build a cumulative picture of their problems, and corresponding considerations for their future project . In the end, we summed it all up in a set of final recommendations.

Many of the research methodologies were new to the Trust team, so we involved them in the planning (and where possible the actual activities) so they could understand what we were doing and help us set a direction that was aligned with their goals.

Evaluating the site

An image of the heuristics evaluation table for Columbia Basin Trust

First, we took a long, hard look at the site itself.

We started with a heuristic review, evaluating the Trust site against eight accepted usability and design principles known as heuristics. To do this, we looked at the site’s navigation, labelling, design consistency, organizational clarity, readability, task facilitation, and mobile support. Using a three-point scale for each heuristic, we scored the site on whether it did not meet, partially met, or completely met these established design principles.

This helped us identify potential improvements – both long- and short-term – that would need to be fixed.

Reviewing similar sites

Next, we conducted a competitive audit to uncover what similar organizations were doing online. We reviewed 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.

Web analytics review

What pages do users visit most? What tasks are they performing? How long are they spending on the site? Each page? What pages have the highest bounce rates? We undertook a comprehensive review of the Trust’s website analytics 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 could also gather technical considerations such as browsers and mobile devices the Trust would need to consider supporting.

Web survey

Our work evaluating the existing Trust website went faster than planned, so we 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 allowed us to identify where site visitors were from, how often the users visit the site, what features they use, the effectiveness of various content and functionality, and the ease of use and satisfaction with the site.

Internal and external interviews

We 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 12 interviews with participants who represented the Trust’s target audiences and key external stakeholders. These sessions, conducted remotely over the phone, allowed us to validate the specific needs and concerns of external stakeholders.

Summarizing our findings

Our research yielded lot of data. A lot!

A photo of a wall full of sticky notes of our findings

After our research concluded, we spent a few days recording key themes on post-it-notes and organizing them using affinity mapping. Following this work we created a summary of our research and findings.

Building business requirements and the RFP

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 the project.


Since some parts of the project progressed more quickly than expected, we were able to use the extra time to provide value to the Trust in other areas. One case in point: the persona project.

Three examples of the persona documents we created for Columbia Basin Trust

A persona is a fictitious, yet realistic descriptor of a typical target user of a product or service. Demographic details, their needs, wants, motivations and pain points, and summary of their tech savvy are some elements of typical user personas. These characteristics impact what is being designed and enable you to focus on what matters. In short, since you can’t design for everyone, if you satisfy the design problem for the most important persona, you’ll likely satisfy it for a much larger group of users. We created four personas for the Trust, providing a strong research tool to inform future project work.

The results

The overall project was delivered under budget. With our flexible approach we were able to deliver our originally planned work, and provide additional research and inputs for the Trust team, including a web survey and personas.

With our findings and guidance in hand, the Trust is well positioned for the start of a future redesign project.

“The project team from Yellow Pencil demonstrated a high degree of expertise as well as a focus on communication and collaboration as the Trust ventured into new territory with respect to the website. Of equal importance to the information we obtained as part of the project deliverables, our staff has come away with richer knowledge of the foundational principles of effective website development that will serve our organization well into the future.”

Johnny Strilaeff, Vice President and Chief Operating Officer