The challenge -in this fast-paced marketing environment companies need quick and beautiful solutions to implement marketing objectives. There are currently two options for mobile marketing – slow loading, expensive mobile sites, or an app download. Both of which require months of design and production to implement. Neither of these allows for speed and flexibility to respond to marketing needs.
Clients need beauty, performance, and to be able to deliver their message quickly. The Famous platform allows for clients to create apps very efficiently with our templates.
The famous platform allows authoring of mobile micro-sites like this.
As Lead UX Designer for the Famous, I was responsible for designing the entire user experience and visual design for the Famous platform. I was also responsible for creating the UX Design processes, UI libraries, and system of working with engineering.
I worked with the CEO, Head of Product, customer service representatives, a team of engineers and potential clients to define direction across all product tools and related company processes. Part of the challenge was a moving target of product market fit - a common problem for new companies.
Design Sprints, Customer Interviews, Competitor landscape, User Testing. Journey Maps...
Before I joined the company, several pilot clients used the beta version to run some marketing programs. Although I no longer had access to these clients, I had the data from their programs and the anecdotal information from the sales and customer service teams. This information was very helpful in understanding where to begin with some customer expectations.
To begin, I set out to understand our users – Who are they? What are their different needs? I interviewed potential clients and reviewed BETA members feedback to understand what they wanted, how they saw using this tool, what tools they may be using currently, and how we could improve on them. 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 different subset of tools and permissions.
For each of these users, I created user journeys for specific important tasks, built prototypes, and ran user testing sessions, which we recorded and then reviewed with the product team. This process allowed us to refine our direction and understand what features we needed and didn’t need.
I defined all the different user types that would interact with our product. We have internal (Famous employees) and external (customers). Then we define their roles, what knowledge they have and how they would interact with the Famous platform.
Adhering strictly to the Google Design Sprint guidelines, we gathered our the Head of Product, two engineers, another designer, customer service rep and myself, and we blocked off a full week of time.
Our goal was to understand what the authoring environment for our platform could be. In the beginning, there was some push back from engineering. "Why are we here?"
By day two everyone was excited and bought into the process. This cross-functional team involvement I saw there inspired me to do these type of team exercises more regularly, on a smaller scale. I saw clearly how this helps team alignment, buy-in and, unity.
Sprints generate ideas that we then whiteboard and wireframe for testing and creating final designs.
We gathered the whole product team to do a full week design sprint. This created alignment between product, engineering, and design.
During sprints, we vote on concepts to help define our product direction.
Through the sales teams, we were able to set up meetings with potential clients to understand their needs and existing solutions. Occasionally we were able to do usability testing.
Our internal teams were easier to test. I regularly setup usability testing sessions with sales, customer service, PR our internal design team.
Other than our customers these were the users of our app. Their design chops and technical skillsets also closely matched that of our client base.
We started with the premise (from the CEO) that all the fine-tuning design tools would be available to our internal designers, but other users would have much less design control.
Through user testing, we realized that even beautiful templates will be destroyed by bad content. We revised our main user types to designers and non-designers. Then we started to optimize the tool to make authoring of an app as quick as possible.
I used Lookback to perform usability tests. We recorded the sessions, analyzed them and shared this information with the rest of the team,
After a combination of research, sprints and user testing, and iterating on options, we settled on a direction for the primary authoring experience. The result 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. Also, I designed a tool for A/B test apps and report results.
Based on research, I advocated for a sketch plugin that would export all assets directly from a designers sketch file straight into our app templates. We could create sketch templates that would map 1 to 1 directly to our platform templates.
Doing this would theoretically reduce app build time to almost nothing. It was an idea that took a while 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-times to zero - far exceeding our goals.
Early prototype screenshot of the authoring tool.
Product screenshot - Customer microapp library
Product screenshot - The app authoring experience.
Working with engineering is an ongoing process that starts at the beginning of the design process. It is essential 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, all necessary assets, a link to the Zeplin file, 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 with designs – 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.
I worked closely with engineering to:
Our goal was to speed up development, onboarding of new hires, and create a shared language between our growing design and engineering teams.
Famous Studio component library
Our product team used agile methods to align with each other and keep a project schedule.
As is common with many small startups, the time here was quite tumultuous, with many pivots, team changes and overall stressors to the team and the product.
Over the course of the project, we went from a web app to a macOS app with a cloud component. We went from 7 team members to 22 and then back down to 7.
Since I left they have further pivoted to a be a tool for designers, not a marketing tool as we had been working on. However, the authoring tool and cloud component I designed is still used for this purpose.
The Famous Platform is still growing. Currently, it has expanded to support Instant Ads, Instant Articles, and Instant Apps across multiple specific use cases and navigation models, including Facebook, Twitter, Snapchat, and standard search results.
The platform allows users to create apps for these specific environments and publish easily, quickly, beautifully, and performs efficiently.