Designing + Building Kanary Triage
video shows the Kanary Triage UI and demonstrates how users can provide feedback on resources.
Background
Kanary was interested in product directions not solely focused on data brokers and data exposures.
With increasing doxxing, harassment, and online abuse, we wanted to build a more holistic solution to the "oh shit" moment when something scary escalates.
Our first experiment was adding an Under Attack? flag to our regular onboarding flows. Users following this path received personalized and prioritized care. This also opened a line of communication to learn more about what they were facing and wanted help with.
Our next experiment was a small service named Triage, which we designed, built, and launched over the course of two weeks. It was targeted to those who were already under attack and was comprised of three pieces:
- A typeform survey asking about the person's situation.
- A django backend where we compiled resources and attached them to a person's request.
- A react frontend that served those resources at a link emailed back to the user.
Why Triage?
Triage was created with a goal to start simple and learn as quickly as possible: Do our ideas and direction resonate? What are the most common issues being faced? And could we actually provide something useful for these complex, intense, and scary situations?
Our main points of reference were organizations and resources that we categorized as:
- 📒 Low touch: Compilations of resources like PEN America's Online Harassment Field Manual. These are great, but require sifting and understanding lots of info during intense times. Many of these grow outdated.
- ❤️ High touch: Organizations providing hands-on guidance and counseling. These require high organizational funding, training, and stamina. It's a lot of time and emotional work to provide this guidance during crises.
Our approach to find a middle ground: To match people with useful resources and guidance, personalized and prioritized to their situation.
Instead of having to support in real-time, this would be delivered asynchronously with a human touch, showing that a real person had heard and understood what they were going through, and allowing for back-and-forth follow-ups.
Building it
Not adding new tech
Kanary is built on React, Django, and Postgres. In building triage, we briefly considered a "fresh start" of different frontend frameworks or using a "real" CMS underneath. Should we switch to Next? Our backend engineer was interested in Svelte…maybe that?
We quickly decided on sticking with our existing stack. Instead of managing a separate deployment, we could build within the same codebase and tools that let us build fast. Our primary goal was to learn quickly, and this supported that.
Switching to a micro-frontend-ish architecture
For the frontend, I wanted Triage to be simple, responsive, and unencumbered by any baggage Kanary had picked up over the years.
Unfortunately, hitting even an empty page in the Kanary app triggered a handful of API calls and bundle downloads, taking 2–3 seconds to initially load on a good connection.
To get around this, I bumped our React version to take advantage of newer lazy() functionality and split our main <App/> into two separate pieces. Not quite a micro-frontend (Modular Monolith?), but still clearly separated within our code.
The results were great: Triage page loads were consistently in the 300–400ms range.
This also avoided unnecessary API calls and made it slightly more anonymous: If you had been logged into Kanary, hitting any URL would previously have sent down identifying account info. With this separation, we had a more appropriate segmentation between the two.
Smooooth feedback
This video demonstrates smooth UI transitions showing how a user can provide feedback on a resource with thumbs up or thumbs down options, with animations that reveal a feedback form when needed.
On the user-facing side, it was also important to collect feedback on exactly what users thought about the product. Was it even useful?
For the simplest first implementation, I added 👍 and 👎 buttons to each resource. Any reaction was immediately saved to the database, but if feedback was negative, it would pop a drawer with an optional long form text input.
Iteration
After an initial round of form responses, feedback rates were low. In talking to users and reviewing analytics, we knew they were viewing the resources and finding some helpful, but not taking the time to let us know.
To get around that, we forced their hand by limited the ability to see a resource before rating the prior. Feeling some discomfort about this friction and wanting to preserve the integrity of our data, I made sure to allow for a "skip" response:
This video shows an iteration on feedback collection where users are required to provide feedback on the each resource before proceeding to the next, with options to skip if needed.
Accessibility
During my time at Kanary, I continually made improvements to their product in terms of accessibility.
Triage was no different. Despite being a quick and scrappy product, all pages followed best practices in accessibility: fully keyboard navigable and relying on html semantics over custom solutions.
Outcome, learnings
Rapidly designing, building, and deploying this was a great way to learn more about the problem space and hear about real experiences people were having.
Due to high employee time requirements to provide quality resources and responses—some of which were in response to extremely sensitive situations—we only ran it for a few months before winding it down.
However, it served it's purpose in validating the direction we were interested in. And started us in learning about and building a library of valuable, useful resources based on real feedback and experiences.
Having learned what we needed, we wrapped Triage and proceeded on to designing and building Kanary Copilot, which began as a continuation of these initial goals.