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.
Although we used 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 .
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 .
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.