Within the Guidebook platform, event organizers can access promotional tools to boost awareness of their event's guide. Within these tools are two web-based options: "Guide on the Web" and "Download Page." During a road planning meeting, Guidebook's head of project management expressed concerns about the "Guide on the Web feature". Specifically, whether the feature warranted further development or if it should be depreciated and phased out in favor of another solution.
In the past, I had researched and worked on concepts to potentially replace the Guide on the Web tool so I understood its limitations. I also knew the Download Page, while straightforward, offered very little to inform and entice end-users into downloading a guide.
Once the meeting wrapped up, I spoke with the head of project management and presented my idea: a promotional webpage that could replace both the Guide on the Web and Download Page. Soon after, I began identifying key stakeholders and drafting documentation on what would eventfully become the Cover Pages project.
An example of a Guide on the Web page
Initially, "Guide on the Web" was meant to be a browser-based 1:1 version of Guidebook guides. However, as time went on and the Guidebook app improved and added more features, "Guide on the Web" was left behind. Networking, theming, and other core features never made it over. The lack of feature mirroring wasn't the worst of it; "Guide on the Web" had a major flaw.
When building a guide, the content within it exists in two main states: building and published.
When a guide is in the building state, its content is very much under construction - end-users do not have access, and only after an event organizer has finished their build and received approval (from Guidebook) can it published.
Published guides are accessible by end-users on the Guidebook app (or any white label variant). During the publishing process, all the content is compressed down into a bundle that is then sent over to the Guidebook app. When an end-user downloads a guide, the app fetches and decompresses the bundle, and they have themselves a guide.
Once the guide is published, any change to the content requires another publishing process to re-occur. Placing content into these two states gives event organizers control over what an end-user sees, and when they'll see it. However, "Guide on the Web" does not display published data, it instead pulls and displays content from the pre-published, i.e. building, state of a guide. This undermines the change control process for event organizers and creates an inconsistent experience for end-users.
Before "Guide on the Web" was depreciated, there had been incidents in which secret sessions or promotional giveaways had been leaked simply because the content was accessible on the web where it should not have been visible until an event organizer published their guide.
Behold, an old dusty thumbnail of a product lost to the unyielding march of progress.
Aside from a guide's name, a little branding, a list of some (not all) features, and an input field to enter a phone number (to text a download link), "Download Page" offered nothing else to inform potential end-users about a guide, not even a brief guide description. While "Download Page" gave end-users a way to access a guide outside of the Guidebook app, it wasn't a good promotional tool.
After formally identifying the deficits of both promotional tools, I began writing out what I wanted Cover Pages to be. Below is an excerpt from the first of such documents. It's a list of goals I wanted the new tool to meet:
The Goals