The Tools We Use

On the product team at DonorsChoose, our work touches every facet of our product and supports an array of stakeholders with different needs: our teachers, donors, partners, vendors, and our staff.

Learning from, understanding, and solving problems for these diverse groups takes a whole lot of teamwork and collaboration. It also takes a fleet of tools that help our lean team do our best work.

Our team’s approach to solving problems has remained pretty consistent throughout the years, but the tools we employ have continued to evolve. If you’ve read about our process before (hint hint, it’s here) you know that once we prioritize what to spend our time on, we start by clearly defining the problem we’re trying to solve, then we ideate on possible solutions, prototype and user test before we build, and then we ship, analyze results, and iterate.

But what tools do we use at each step of the process, and how? Note: I’ve described each tool in only one step, but they‘re often tapped into at multiple steps.

PRIORITIZE

Before deciding to work on a problem or feature, we discuss the potential ideas on the table and prioritize them based on impact, scope of work, and alignment with organization-wide objectives.

Productboard is our roadmapping tool. It allows for a ton of customization to meet our unique needs, and we can clearly assign stakeholders, add scope estimates, reflect the current product process state for each item, and more. Productboard enables the collaboration we need within the team and allows us to make more informed prioritization decisions, while providing ever-important transparency to our internal stakeholders.

DEFINE

After we’ve prioritized a problem or feature, we need to define what problem we’re solving — and just as importantly — what we’re not. This is the stage where we get a deep understanding of the current state of things and where there’s opportunity for improvement.

Fullstory helps us experience the site through our users’ eyes. It allows us to view users’ sessions on the site: what they clicked, what pages they viewed, where they got stuck. We use it to troubleshoot reported bugs, and also to understand where there might be user confusion or frustration. Our engineering team built a tool that allows our team to control where and when we load Fullstory, so that we can be intentional about recording only what we need. If we know there’s a major drop-off between one step in a funnel and the next, we can employ Fullstory to actually watch what our users are experiencing in that moment.

Qualtrics is the tool our UX research team uses to build surveys and learn more about our users and their actions. They might build a standard survey to send via email (ie. surveying donors to get a better sense of their demographic descriptors (age, education level, etc.)), or build an intercept survey to ask users questions while they’re on the site (ie. asking teachers why they’re visiting a certain page). Qualtrics is also used to screen potential participants for 1:1 interviews or user testing sessions, to ensure we’re talking to the right participants for the project.

IDEATE

Having a clear and deep understanding of the problem, we move to ideating possible solutions. A lot of this work happens in meetings, in google docs, on whiteboards, or on pencil and paper, but we do occasionally use software to help us organize our ideas.

Lucidchart comes into play when we’re working through a complicated flow or need to map out diagrams. It’s an easy-to-access and easy-to-share webapp that we’ve used to show: the hierarchy of pages in a site (or part of a site), and user flows to show the steps in a specific user task including decision points and system reactions.

Mural is a flexible tool that helps with collaboration, meeting facilitation, organizing complex ideas, and more through its visual and interactive interface. Mural has enabled us to make those sticky-notes-on-the-wall sessions accessible for everyone, even if we’re not physically in the same room. That’s been essential this year as we’re all working remotely but even pre-pandemic, Mural helped us ensure that everyone involved (we have two offices and colleagues who have always worked remotely) could fully participate. We might use Mural in a group session to write out ideas and identify themes, to visualize potential solutions on a chart and move them along axes of impact vs scope of work to narrow things down, or during a journey mapping session to show the broader steps in a user’s experience.

Sketch is our tool of choice for creating design artifacts anywhere between an actual pencil and paper sketch and a pixel perfect mockup to show how the final screen will look. This is generally a good conversation starter to get stakeholders to understand where we’re heading and helps us refine the layout, content, and visual elements of the design. Although sketch does have some prototyping capabilities, we move to another more fully-featured tool for that….

PROTOTYPE

Once we have clarity on potential solutions, our design team creates high fidelity prototypes that we can put in front of our users and make sure we’re heading in the right direction. It’s important for us to gain confidence and refine our ideas at this stage to get clarity before we commit time to actually building anything.

Axure is our primary prototyping tool where our designers can create anything from simple click-throughs to high fidelity mockups that feel like real, functional web experiences. This not only allows us to user test with our users, but gives our stakeholders and engineers better clarity on what the finished product will feel like down to the interactions.

User Zoom is employed by our UX research team to run our remote usability testing on our prototypes with real users. Typically these are moderated sessions, where a UX researcher will guide a participant through the feature we’re working on and ask clarifying questions to get a deep understanding of why a user makes the decisions they do.

BUILD

When we’ve made adjustments based on usability testing and are ready to move forward, we work closely with our engineers as they bring it all to life. I’m not going to get into our tech stack, but we use JIRA, IntelliJ, and Github to organize, produce, and deploy the code to our website.

ANALYZE

After we’ve built, tested some more, and are ready to release, it’s time to analyze the impact of our changes to make sure we’re moving metrics in the right direction!

Optimizely is our primary tool to run and analyze A/B tests. These tests may be run as part of a larger project when we want to test the real impact of changes we’re working on making (such as a redesign of the project page to ensure we’re helping rather than hurting conversion), or as standalone improvements that tend to be smaller in scope and quicker to implement (such as copy or design changes on existing pages).

Pingdom is a site speed monitoring tool that we use to run post-release spot checks on our site performance. After each release (whether it includes major feature changes or not) we check out top landing pages to quickly identify an impact on performance. If we’re shipping something to improve performance, we can see our impact here as well.

HEAP is our event tracking tool. It allows us to analyze how our users are actually interacting with the site, and is one of the primary ways we measure whether we’re achieving the goals we set for the project. If we’re making design changes to the project page, for example, do we see more users adding a project to their cart and donating than prior to our changes? Are users interacting with specific features on the page at a higher rate than before? Is that what we wanted them to do?

Looker is our business intelligence tool. Our Data team created and manages our Looker instance to provide a self-serve way for the entire organization to access information, and create reports/visuals without having to query the database directly. It’s the other primary way we measure if we’re achieving our goals. While Heap would tell us if there’s a change in donation conversion, Looker allows us to understand if we’re seeing increased donation revenue that we can attribute to our changes, if there’s been a change in the average amount given by donors to a project, if we’re seeing a change in the percentage of projects that are fully funded, etc.

Through our analysis we may discover further iterations or bug fixes that are needed in the immediate or that we’ll prioritize in the future. The product and development cycle is just that — a cycle. It’s continuous and iterative. Our tools support that iteration and come into play throughout the process, not only in the sections listed above (we dig into our analysis tools during the define stage as well, for example).

We take a similar iterative approach to the tools we use. In just the past year our team transitioned to both Productboard and Axure to meet our evolving needs. Changing the tools that power our team’s work is an investment and can have a steep learning curve at times, so it’s not something we do lightly. But it’s equally important that we don’t rest on our laurels and stick to a tool or process simply because it’s what we’ve always done. After all, as the famous John Culkin quote says, “We shape our tools and thereafter our tools shape us.” And we want to make sure our tools are taking us in a direction we want to go.