Screenshot GalleryDevelopment GalleryFlypaper UI Story

Where does award-winning software come from?


Early in 2007, a company called Flypaper Studio was born. The mission: Launch the best content creation software that even non-technical people can use.

Six years later, Flypaper Pro has no relevant competition in its market. It’s easy, it’s powerful, it has a passionate user base, and it’s won a few awards. This is all by design. Here is Part 1 of how it all came together.

Part 1: Catalyst

Flypaper is a desktop application that promises to be the easiest way to create multi-touch, interactive or motion graphics content for digital signage. Currently on version 3.10, the development of Flypaper has been an exciting 6-year rollercoaster ride.

The most significant part of that ride for me has manifested itself as the User Experience. Flypaper is instantly approachable, yet grants users the power to do things they could never do on their own before. It’s easy, it’s fun, and it’s empowering. The success of Flypaper is almost entirely due to this great user-experience. This is no accident. As the Lead Designer since the inception of the Flypaper project, building a great user experience has always been my highest priority, and the execution of that experience is due to the months of iterative design work done early in its life cycle.

Before our team even began designing Flypaper however, there was a simple idea proposed to solve a complex problem.

Path Manager

Flypaper was born as an interactive storytelling tool, proprietary to our custom e-learning development group. In 2004, we called it Path Manager, and it allowed Instructional Designers to more easily create complex decision-making activities for learners.


A couple of programmers were tasked with creating the technology, and although Path Manager allowed our Instructional Designers to write and organize interactions that were previously inconceivable, it was difficult to use, was full of arcane terminology, and had an incredibly steep learning curve.


Still, there was a lot of power under the hood, and it was clear that our clients were willing to to pay for the amazing simulations and other interaction possibilities that Path Manager offered. We just needed to streamline the workflow and usability to fit our tight design cycles.


For years up to this point, my primary responsibilities were as Art Director for the custom client work we were doing. I had countless projects under my belt, producing graphic and Flash assets, designing UI/UX, maintaining brand guidelines, and working closely with our clients, our programmers, and everyone in between. Now, the development team needed graphic assets to dress up various functions within Path Manager. This was a fun opportunity to put a nice skin on a Windows application, but as we slowly improved Path Manager, something larger began to take shape.


I found myself shedding light on, and discovering elegant solutions for usability and workflow problems. I wasn’t just replacing graphic elements. I was reorganizing and re-drawing entire sections of controls. Soon, what began to appear on whiteboards and in my sketchbook was a unified application and runtime that supported everything a custom e-learning development company could need, from a script-editing environment, through publishing and live online review cycles. Path Manager became just a panel within the larger application. An avatar system was created, with fun animated personnel icons, to let users know when multiple people were working on the same project.


Although I don’t know this was ever said out loud at the time, the entire company’s mantra became “iteration”. We iterated on software names: Path Manager, Alchemy Author, Catalyst. We’d iterate on a drag and drop operation, which would improve the efficiency of our content developers, allowing them to spend more time working on more sophisticated content, which in turn pushed us to iterate on more sophisticated functionality to support their efforts. It was a truly symbiotic relationship between content producers and tools developers, each feeding the other.
My job was to be the guy in between. I understood the needs of the content producers, and could easily dig into the weeds of their processes with them to better understand how they wanted to work. I learned to put solutions on paper, bring them to the developers, and negotiate solutions based on effort versus reward and any technological limitations that might be present.


As a whole e-learning content development solution really began to take shape, we started demonstrating Catalyst for clients and would-be clients as the ultimate way to produce the types of content they were looking for. What we didn’t know at the time was that our new tool was even more desirable outside of the e-learning market.

Part 2, soon!