Live Data Prototypes
Marty Cagan—leader in technology product management—has been educating folks on the unmatched value of experiments like these for a long time. Read his 2011 article →

Think about it like a “personal coding design sprint” with a primary goal of testing with users in the browser instead of a static mockup.

Below is a selection of live data prototypes I created during my time at Sprout Social. Most were completed in anywhere from an hour to a few days and ultimately saved us weeks and months in development and opportunity costs.
Prototype Link
Background Story

Tip: Try the slider and arrow keys!
We had some customers with competitors that had a teal brand color and their advocates were confused and offended when met with our proprietary branding. My hunch was to solve this by supporting a custom hex value to replace our default teal, but I needed to make sure it held up in the wild.
Epic win. Our engineers appreciated that we were able to avoid building a full scale theming system like Slack to focus on testing a single value across all supported environments. From a marketing perspective, this granularity in brand representation served as a differentiator.
We had automated digest emails, but several of our customers wanted on demand control over which stories were emailed to advocates.
Flawed success, then epic win. The first version was met with confusion, and the second was a crowd favorite. Not only did we met a contractual deadline to ship this within 3 weeks, but we had it ready it 2.
Our largest customer asked for this, but we felt ghost posting is common in online publishing so we went for it.
Flawed success, then epic win. We ran into some issues with permissions and who should be appearing in the list, but we were still able to ship within 3 days of me creating this prototype. We were surprised by how many customers told us they loved the feature! It’s the little things. 🙂
At first, I just set out to wrap my head around all of Facebook’s different posts types, but I learned there were a ridiculous amount so this helped us drastically reduce the scope of supported types to ship faster.
Flawed success. We moved ahead with the new endpoints and UI, but translating Facebook’s backend to our normalized frontend proved tricky and we shipped about 6 weeks later than expected.
Our sales and accounts teams asked us to introduce user limits they could leverage to provide more clarity and control in sales conversations. I made this to educate them on how this would affect end users.
Flawed success. We didn’t make any changes to the product and decided to manage this out-of-band. Felt good to protect our users from running into a dead end over something they couldn’t anticipate or be expected to change.

Related: Broadcast test
Although we used Mandrill to send all our emails, we assembled them in-house. As we added more, they became inconsistent and difficult to manage. I made this as both an engineering reference and production-ready code. Each email was able to be tested in advance in Litmus to ensure they looked right in all our supported clients.
Flawed success. We were able to update and ship all our templates in just a couple days. The only hiccups were a few specific customers with unexpected combinations of environments and client versions that required additional QA review to resolve those support tickets.
When we started Bambu, we only had one story type (articles) that we displayed in 2 different ways: detail view and preview which was re-used for the list view and content emails. Eventually, we had double-digit story types and double-digit layouts across mobile, tablet, and desktop displays. I made this as a reference to make it all easy to understand.
Just a guide. Zach—our UI developer—ended up building all these possible states into our production component library.
Similar to the UI stress test above, I made this to demonstrate the nuance of our content types in our main feed.
Same as Story UI Stress Test above. The team got a kick out of my use of the voice library since we were hot on accessibility.
Our customers wanted a way to publish original content internally, and it wasn’t likely that we would be able to afford an integration with Google Docs or equivalent. My goal was to prove we could quickly implement a lightweight editor that was compatible with our stack.
Epic win. We ended up shipping this right away as Internal Stories. The biggest flaw we patched later was automatically saving so users didn’t lose everything if they refreshed or lost their connection. Eventually, our customers wanted more muscle and we switched to CKEditor.
There were two prompts to this exploration: introducing categories and clearly distinguishing our admin and reader experiences.
Efficient fail. We simply weren’t ready to commit to all these changes, but this served as a reference that informed all future changes to our navigation, information architecture, and even our end-to-end v3 experience that will ship soon! The categories connected here recently shipped as Topics.
Our Core app ran into an issue where we had too many dependencies when servers failed. I was tasked with making the minimum viable payload to display an error message when multiple services failed.
Flawed success. This template inspired the final deliverable, although I think I may have stripped too many things down.
My boss came to me with some sketches and a vision for a one stop shop for our wiki, company news from Bambu, and Google Apps. I whipped this up this skeleton that same day.
Efficient fail. This helped internal folks realize the limitations of what we had imagined and commit to building out a similar experience in Confluence with plugins—a route that prioritized crowd-sourcing its evolution and maintenance.
Did this for fun as a personal project, but it helped us understand the resources we would need to maintain an experience like this on the same scale as our core product.
Efficient fail. Given our limited resources, we decided against building out a full calendar view. Gaps like this compared to our core product contributed to the eventual consolidation of the administrative functionality back into our core product.
¹Read this article that differentiates these outcomes—efficient fail, flawed success, and epic win. “Just a guide” means something we were going to do anyways and this helped us ship faster.

Other random things

  • Before I introduced Dearborn—our production component library—I created this stateless component library as sort of a preview for our engineers. My favorite part of this exercise was the tiny script I wrote to apply the styles as this is pure Javascript with no external libraries.
  • Before we had a way to sync our brand colors across our team, I spent a Friday afternoon creating a script to generate a Sketch plugin from which is where we were managing our design system at the time. The whole team was able to start using the latest color values immediately. This predates most of the design system syncing tools now available including’s own syncing tool (now InVision DSM).
  • Early UI demos