Creating a minimal feature demo to ensure stakeholder buy-in

James Stone
Jul 25, 2017 · 2 min read

In the past I have discussed the advantages of creating a mockup in the browser with a live site. Today I will talk about my approach to get buy-in on the entire feature, before wasting time and rolling it out to a larger system.

Today I want to show you more of my process. SnowflakeStories.com is very complex under the hood. There is a lot of complexity in the product. In order to mask a lot of that complexity, a lot of business logic has to be written in order to handle different conditions and edge cases. The books are automatically translated into several languages, which requires specific roles and other data to be gathered by the end user.

In short, it is a lot of work to keep things simple for the end user. The result is the process seems easy. That is no accident, there is a lot of effort put into making it seem simple.

The downside of that is that the project is a bit complex to maintain.

When adding a new feature it is critical that I get stakeholder buy in up and to be very clear about how things will work. Before spending the time to implement this across 3 different products (with subtle variations) and 4 different character types (all including subtle variations), I just created an MVP form of the feature.

I created this on a separate git branch and I added the feature for the easiest to show character. Once I was done, it was important to showcase how this works.

Sure I could have thrown this over the wall to the founder, with some text explaining how it works. But that would not have been the best experience. Furthermore, it would have left a lot of things up for misinterpretation.

Creating a short screencast video allowed me to clearly isolate and communicate the feature. This also served as a basis for future communication about the feature.

You will note that it is cropped tightly around the feature, it has no sound recorded, and it goes through a simple sequence to show how the feature works.

When you are working on a fast paced web product, it is critical to communicate clearly with all members of your team. It is kind of like the snowball effect. Every corner you cut, every word you leave that is vague, every hour you waste using the wrong tool can add up fast.


Originally published at James Stone.

    James Stone

    Written by

    Design Systems Engineering — ZURB Foundation Specialist

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade