This document shows how we shaped a feature for our app that allows people to create and explore templates more easily. This is generally how we structure pitches at Whimsical to gather feedback before beginning design and engineering work in full.


Though this pitch was reviewed by Whimsical leadership, it was ultimately used by the project team I was working with, made up of a product manager, myself and a few engineers. I first shared it with them to read and add comments on their own, then we reviewed it during a live "betting table" meeting when all pitches are reviewed for the upcoming cycle. 

While Whimsical had made templates available to users for some time before this feature, they were difficult to find and use. This template browser pitch coincided with a general focus on template discoverability across the app.


There was plenty of support across the organization for this work; the challenge was figuring out how to ensure that the template browser would fit within the existing visual design and interaction patterns used in the app. We also received a fair amount of feedback guiding us to pare back certain ideas in order to keep the scope manageable within the project timeframe. For example, we debated whether or not to include docs templates in the first launch of the browser, because we didn't love how the preview for docs content rendered. However, we decided to include them despite the less-than-ideal preview rendering, since we felt that it would be better to give people access to explore them sooner rather than wait to polish the rendering UI. (These conversations mostly happened between myself, the engineer focused on the frontend build, and the PM.)

As part of this work, we also proposed changes to the existing "create new file" modal, which ended up being more controversial than expected. We received feedback that templates were being featured too prominently in the prototype, possibly distracting from the higher-traffic "create from blank file" buttons. However, we argued that, in order to give an adequate preview of template files, we needed to show their thumbnails (which were previously just text links), and that the benefit of being able to smoothly transition directly into the template browser when clicking "Explore templates” outweighed the possible confusion long-time users might experience with the new design.

Figuring out the appropriate level of fidelity for communicating certain ideas—sometimes in text, sometimes in wireframes, sometimes in high-fidelity prototypes—was a challenge, as this was a completely new feature. We often had to express ideas in multiple ways in order to communicate them clearly. The documentation for each part of the solution increases in fidelity as each becomes more visually-focused. It made the most sense to just use text in a table to describe the new data model, because I was simply showing descriptions of types of fields. When thinking about the layout of the browsing UI, I didn't want to spend too much time on ideas that might not pan out, so I used just enough fidelity to express ideas and the representations of the data mode without getting too invested in any direction.

As for the high-fidelity prototype, I needed to communicate specific visual nuances to get buy-in from stakeholders who would otherwise have been confused about what I was describing, and possibly have written off the idea. I felt that a high-fi prototype would be much more effective than just saying, "this modal will visually transition into the template browser" (or even trying to wireframe it), even if the final designs would likely change.

Embedded in the pitch doc are some of the wireframes we made while working through ideas for the template browser. The actual wireframe file was much bigger, messier and full of comments; here we shared a cleaner view of it.

Brandon Dorn

This pitch doc and it's embedded wireframes were used to guide the design and development of the Whimsical template browsing UI. In particular, it was written to ensure that the team got the kinds of feedback from stakeholders. 

This document would ultimately be referenced 

At present, templates are neither easy to find in the app, nor easy to choose once you’ve found them.

 While we give users access to our full template library, a number of issues are apparent:

Templates of all kinds are commingled together, making it hard to find what’s relevant for a task.

It’s hard to infer the content of a template by its thumbnail, particularly for large, complex board templates.

Template files are duplicated the moment a user selects one, preventing them from being easily browsed and compared

By making it easier for users to find relevant templates, we hope to increase template usage which, in turn, we hope will deepen users’ awareness of Whimsical’s value and their usage of key features.

 especially, we hope that improved template browsing will help them quickly get started creating new files as they see Whimsical’s relevance for their work. For 

, we hope we they will discover new, collaborative ways of using the app.

Integrate with the “Create New File” modal

To help users quickly understand a template’s content and purpose, we’ll surface key bits of information about them alongside an interactive embed. Below is a first pass at a template data model, which we’ll iterate as we work through design.

Our primary goal for the template browsing interface is to help users quickly find and use relevant templates. To this end, we’ll explore patterns that allow users to:

Easily traverse template categories and tags

Regardless of the granular design patterns we choose, we expect the first version of the browser to have a set of views and features:

The wireframes below show early layout and interaction explorations:

3. Integrate the template browser with the “Create New File” modal

To make templates more discoverable, and because we already recommend templates in the “Create New File” modal, we’re considering a change that would 

 the template browser and “Create New” modal, or at least create a clearer connection between the two.

One idea we have is to “morph” the “Create New” modal into the template browser when a user clicks “Browse Templates.” This prototype shows what we’re considering:

Opening the template browser directly from the “Create New” modal gives even quicker access to our library.

As we develop template metadata, we’ll want to review with marketing and others to consider how we may want to repurpose template metadata publicly.

Template search and recommendation logic will be built in a separate pitch.

Custom file thumbnails will also be handled in a separate pitch.

Changes, improvements, additions to existing template content will be covered in separate pitches, or just done out-of-cycle.

In a future pitch, we’d like to consider how to allow people to “clear” templates of guidance and help content so that they can use it “from scratch.”

We’ll focus on in-app template browsing before focusing on public template browsing on whimsical.com.

Pitch: In-App Template Browsing at Whimsical

Pitch: In-App Template Browsing

Problem

Impact

Sign up to see more