The Challenge

In the Spring of 2016, Essendant's Marketing team were looking to ensure that presentations used by Sales included standardized messaging and conformed with brand guidelines, but also to give Sales flexibility to adjust presentations for individual customers. They'd been building presentations and other collateral for Sales as possible, but could not keep up with demand; as a result, Sales was often building their own presentations to work around this problem.

In response, I designed a "presentation builder" app, intended first for use by Sales, but also eventually to be used by Essendant's customers to build presentations to support sales to their customers. It allows users to build presentations using pre-defined segments, called "assets" in the app, then "play" them for customers.  The assets themselves were not restricted to any particular format other than that they be accessible via a browser, but were expected to be self-contained, and created by the Marketing team.

The Design: A Self-Service Presentation Builder

Getting There: Honing the Design

Requirements for the app were distilled from requirements my team had gathered related to the redesign of Essendant's customer portal (following the digital strategy work I completed around Essendant's digital properties), with some additional details provided by the Director of Marketing.  The interface for the pages of the Presentation Builder that allow users to find assets, view their details, and play back a collection of them (a "presentation") remained fairly constant throughout the design process.  Its evolution largely consisted of fine-tune navigating among these pages, and incorporating the tools available to users to build presentations and share assets via email. 

Getting There: Starting with a Minimum Viable Product

I knew, as I was designing this app, that there was no budget available to build it, never mind build it with all of the features and functionality it should eventually include to truly meet the needs of Sales and Marketing. In order to move forward, I recommended a minimum viable product, which would have an underlying architecture and data structure that could support the app's eventual capabilities, but a very simple, reduced set of interactions.