We realized early on that this solution would be a combination of processes and product design. This platform would require many different tools. An app builder, a template builder, billing, testing, user management and others. For each one we started with one question. Why? Once we understood why, we could begin to understand what we needed. We used Agile methods and Design Thinking to quickly determine user needs and product direction.

Allow our internal designers to use our system to build custom templates for clients in about 30 minutes. Allow a non-designer client to create a beautiful mobile app complete with complex animations using these templates in under 15 mins. Ensure the resulting apps were always beautiful and always performant.

To begin, I set out to understand our users – Who are they? What are their different needs? I started by creating temporary personas to get a feel for who the individual users might be. I then interviewed potential clients to understand what they wanted, how they saw using this tool and what tools they may be using currently. Through this process I identified internal users and external users, some were designers and some were marketers and managers. Then I refined the temporary personas. Each of these personas would need a specific set of tools and permissions.
For each of these users I created user journeys, built prototypes and ran user testing sessions which we recorded and then reviewed with the product team. This allowed us to refine our direction and understand what features we needed and didn’t need.

We knew we had a lot of questions to answer about how the company processes would be set up and how the platform would support those.

We ran a week long design sprint to explore user journeys and to map different users journeys through the process. Instead of trying to solve a single problem, we set out to understand what the problems were. We knew basically who the users would be but we didn’t know the best way to build the service we wanted to offer.

Over the course of the week we began to understand how a user would be introduced to our company, onboarded to the platform and what their individual journeys could be. Over time I matched this with persona research to refine the tools.

An example: We knew that a client would have users build apps using our templates inside of the Famous platform. We hypothesized that this user would be a marketing person with little or no design experience. Therefore our tool app design tool and templates needed to have very little style controls and allow for our internal designers to control the design at the template level. This led us to understand that our template library needed to be more flexible and tools needed to be added for our internal design users that would allow them to quickly create template variations and make them available to the client.

With our internal users we were able to run daily user testing sessions. I recorded them with Lookback.io using the Famous platform as we added new features and tweaked existing features. Over time we watched as their time to build and design templates dropped from about 40 minutes to 14 minutes.
In the end our goal for allowing our designers to create templates in 30 minutes was bested by nearly 50%. We built tools for building and templates, authoring apps from templates, analytics, experiments (A-B testing), Brand Management, User Management, Template/App Management and Client Billing.

Client Personas – Marketers
The biggest takeaway we had had from our external user tests were around building apps from our templates. Content is king once again. We started with blank templates with no content. This was confusing for users who were new to the system or new to a specific template. We needed to add dummy content to the template that showed them how it could/should be used.

This led us to rethink how we were approaching the templates all together. We tried creating content specific to each client for each template. This showed them how their app could look and also pre-loaded their logos and styles into the template, making their job much easier. For our internal designers who are familiar with the system the time spent to do this was trivial so it was a win.

Famous Personas – Designers
We had a hypothesis that our designers would use a large monitor and make the window as large as possible for the best viewing experience. However, none of the designers we tested with did this. They had other windows open with the text content and image content needed to create the app. This led me to two conclusions. 1. We needed to think more about how we used space on the screen to allow for proper viewing of the app and toolbars while building on a smaller screen. 2. We should consider an asset library that allowed for the designer/user to upload all necessary assets and manage them for specific apps and across apps for assets like logos and icons.

After a combination of research, sprints and user testing we settled on a direction for the main authoring experience. This included solutions for many user personas across several journeys and required the creation of dozens of new tools. Altogether this would account for the process of creating templates, assigning them to clients, letting clients create apps from these templates, manage their account and users. In addition I designed a tool to A/B test apps and report results.

In addition, I advocated for a sketch plugin that would export all assets directly from a designers sketch file directly into our app templates. We could create sketch templates that would map 1 to 1 directly to our platform templates. This would theoretically reduce app build time to almost nothing. I see this as one of my most succinct design ideas. An idea that took awhile to sell. Eventually it became the core of our app authoring experience. It allowed designers to stay in their natural design environment – Sketch or Photoshop – then export directly to the Famous app builder. This reduced app build time to zero, far exceeding our goals.

In order to increase efficiency in future development and support a growing team of designers and developers, I set out to create a comprehensive design system that would incorporate all UI components, styles and page layouts.

The system started at the Sketch file with a set of symbols and nested symbol components that allowed for the assembly of full pages within Sketch. The symbol components matched one to one the react components being built by the engineers. The goal was to eventually create a living style guide that could easily be updated when components change. It would also allow for engineers to copy and paste code segments to build and designers to copy and paste code segments to create clickable prototypes very quickly and accurately.

Working with engineering is an ongoing process that starts at the beginning of the design process. It is important to understand what is possible, what works with the current tech stack and the things that are currently built.

When designs are finalized the deliverables are the sketch file itself, all necessary assets, a link to the Zeplin file ( A tool that allows the developer to see all the css properties) prototypes that show complex motions and most importantly time to sit with developers to ensure that things are built as designed.

There are always unanswered questions – and the fact is engineers see things differently than designers and often come up with edge cases or states that were missed. This interaction between designers and developers is crucial to the success of a product team.