Spoiler alert: If you want to jump right into our notebook outlining how we use Notebooks at Abstract, use this public share link.
Have you ever heard the expression “we’re building the plane as we’re flying it?” Since launching Notebooks earlier this year, that’s exactly what we’ve been doing. Our entire team is using Notebooks to build Notebooks. Quoting from our internal docs — “everything [at Abstract] starts with a notebook.” We’ve learned a lot from both building and adopting a new platform and we hope sharing a peek behind the curtain will encourage you to try Notebooks and see how it can help your team too.
How we increased our shipping velocity with Notebooks
As you may expect, with any new tool or platform there will be a period of acclimation for you and your team as you form new norms and processes. When our product design team first started using Notebooks, it felt, well… a little forced. We experienced the same pain points other teams do when adopting new tools. It takes a bit of time and consistency, but we’re now ramped up and we’re finding that Notebooks has helped us increase our shipping velocity by 23% since March.
Sprints and squads
A few months ago our entire team moved to a formal two week sprint cadence and reinvested in dedicated squads. Each sprint there’s a process of kicking off a project, making decisions, and then iterating — all of which can be easily documented in Notebooks and repeated.
With reviews in Notebooks, we’re able to create an async design review and get the feedback we need to move forward with our designs. Because there can be so many stakeholders involved in the design process, it’s easy to add everyone to the review and call it a day. But what we’ve found from our own experience is that the more folks we add, the more that request can get lost in the shuffle. So tightening up the review process by only adding the key critical squad members to review requests has worked a lot better. Then we @mention anyone in a comment that needs to stay informed, which helps keep the project moving.
At the end of a sprint, we use decisions to share where the work landed. This ensures that when we come back to a feature or another team picks up the work, there’s clear documentation about what’s been done and why.
This is kind of meta, so stay with me — as our shipping velocity has increased and we’re able to ship new features faster, we’re able to take advantage of features and improve them. To share an example, here’s one of the ways reviews have evolved over the last few months.
When you request a review, reviewers can either approve or request changes. After using the feature for a while, we noticed a pattern. People were approving reviews but also leaving a comment of things that needed to be updated. This sort of defeated the purpose and caused confusion on whether things were actually approved or not. We found people were intimidated by the Request Changes button. People thought it looked scary, which may have had to do with the bright orange warning color and sharp edges to the icon. We came together as a team to brainstorm alternatives, and gravitated towards the concept of iteration – which also happens to be one of our company values. With a change of icon and color based on this value, requesting changes now feels much more like collaboration, and less like scolding your teammates. The new treatment shipped a few weeks later, and we’re already more comfortable making our feedback clearer with that Request Changes button.
Getting these features into the hands of our team as well as our customers has allowed us to make better decisions. In this way, we’ve really been able to live that value of iteration. If you’re interested in seeing what updates we’ve made and features we’ve iterated on recently, check out our release notes.
Our design team sits within the Product org at Abstract. That means we’re BFFs with our product managers. Each week, we have a standing brainstorming session that includes product managers and brand, content, and product designers. We like to call it the PD Jam. Our product managers have a deep understanding of what our customers need and our design team acts as the subject matter experts. We’re able to think and dream big and ask the question “wouldn’t it be cool if…”
Just one piece of the product puzzle
Our team also knows we can’t rely on dogfooding alone. We can advocate for the things that we see value in and then build it, but the bulk of our new features and updates have come from the feedback we’ve received through user research, including contextual interviews, surveys, and usability tests. We’ve also worked closely with our Design Partner Program, a small group of teams that are invested in helping us make Notebooks successful. And our product team partners closely with our customer success managers and solutions engineers to hear insights about the onboarding experience for teams just getting started with Notebooks.