Overview

Our mobile and TV app clients currently use ContentSnare, a third-party tool, outside of the Uscreen platform to submit the necessary information for building and updating their apps. This creates a fragmented user experience, as customers are required to leave the Uscreen admin area to upload app assets. We believe that creating a cohesive app update experience in the admin area will reduce time to setup apps, increase app status awareness, and decrease App Launch Team email support.

Goals

Streamline the app development process by integrating an intuitive app builder tool directly within the Uscreen platform.
Deliver cost savings of $249 per month by eliminating the need for the third-party tool, ContentSnare.

Success Metrics

We will know if we are successful if:

We can reduce the number of days it takes for a customers to upload their TV and mobile app assets from 35 days to 25 days in the first 6 months

Research & Analyze

Engaging directly with our customers is my preferred approach for gaining a deeper understanding of their pain points and needs. Hearing their feedback firsthand not only helps eliminate guesswork but also ensures we avoid making assumptions. For this project, I also conducted in-depth conversations with our App Launch team to gain insights into their challenges and gather their perspective on the process.

Customer interviews

From speaking with our customers and our internal Apps Launch Team, I was able to outline the following pain points we wanted to solve with the new app builder tool:

App setup process is time-consuming, overly complex, and feels too technical.
Redirecting customers to a third-party tool like ContentSnare to collect app assets creates an unprofessional experience.
The lack of transparency in the app-building process requires extensive communication between customers and Uscreen, as customers are unable to track the progress of their app.
App assets are stored in multiple locations—some within Uscreen and others in ContentSnare—making it difficult for our team to efficiently retrieve both new and existing assets.

Customer Journey

This was a complex project involving multiple teams. To align internally and gain a clearer understanding of the customer experience throughout the app purchase and build process, we decided to create a customer journey map.

The journey map helped us identify key pain points in the customer experience and allowed us to see which teams were responsible for each stage. It also provided valuable insights into the average time customers spent at each step, as well as where the app builder would fit into their overall journey.

Ideate & Design

Analyze current tool

I began by analyzing the current ContentSnare tool to understand how customers upload their app assets, with the goal of identifying both the strengths and weaknesses of the existing process. I also wanted to ensure that any valuable functionality offered by ContentSnare could be seamlessly integrated into our new app builder.

competitive evaluations

Next, I explored other app-building tools to gather insights and inspiration, learning from both their successes and challenges. After all, there's no need to reinvent the wheel when we can build on proven solutions!

Lo-FI Wireframes

After reviewing the current ContentSnare tool, I compiled a comprehensive list of requirements for our new app builder. With this information I started to sketch out rough paths we could take for this new app builder. I presented three possible approaches to stakeholders, including my own recommendation. After thorough discussion, they agreed to move forward with my proposed path.

From there, I began creating detailed wireframes outlining each step of the process. Throughout this phase, I actively engaged with the product team and stakeholders, regularly presenting the designs to ensure transparency, gather feedback, and refine the solution collaboratively.

Hi-FI Designs

Once we felt comfortable with the direction of our proposed solution, I could start working on the more detailed designs. This allowed us to fully visualize the entire flow and the settings we would need to ask our users to complete. I used our weekly product meeting to present these designs to our stakeholders so everyone could be up to date on the latest progress and provide feedback.

Validate & Iterate

I would usually create a prototype for usability testing but since this feature was so complex and needed to be able to handle many different use cases, we decided to develop a prototype that we could get feedback with and iterate on. Having a working prototype would allow us to discover any shortcomings or improvements we needed to make quicker than any figma prototype.

User Testing

We started with a small group of internal uscreen employees as our first user testing group. We ran a 4 week sprint with 7 employees and had each person create an app via the app builder. We ran through everything a customer would have to go through including website set up, app developer accounts, creating and submitting assets and finally publishing their apps.

Design Iterations

As clear as I thought my initial designs were, it turns out that people were still struggling to understanding what different parts of the UI meant. Once I completed and reviewed the design updates with those users we learned we had solved for the initial problems we ran into during testing. Improvements included:

Copy changes for clarity, leverage existing help articles
Improved app developer account set up flow
Primary color isn't updating in the phone preview
Noticed inconsistency with preview phone and actual UI
Tooltips weren't show up for some users
Need better onboarding screen cropping functionality
Added more insights/recommendations from the Uscreen team to help guide users
Image size requirements added

DEVELOPMENT

Since we already had a working app builder on a staging account the handoff was more fluid than most projects. Most of the underlying functionality had already been built so what was left was more around the clean up of the UI and interaction improvements. Before our kick-off meeting with engineering I worked with my Product Manager to breakdown the requirements and add any edge case designs (error states, empty states, hovers, animation).

Engineering handoff

We always start every project with a kickoff meeting with Engineering, myself, and the Product Manager to make sure everyone is on the same page and there are no blockers. Since we are a remote team we will usually set up a slack channel between all teams to make sure everyone is readily available if there are any questions.

QA review

Once engineering with the development on stage I was able to start the QA process. I like to mock up any design updates needed verses typing it out as this can be much easier to understand. I added requirements to the feature outlining where the execution didn’t align with the initial design.

Release & Retrospective

BETA

We identified a few customers that were interested in being part of our beta program - once the app builder was functional with all the improvements from our testing and QA we were able to release it to their accounts behind a feature flag so we could gather feedback from a small group of real customers. We quickly realized we needed:

Strongly Encourage Google Developer Organization Accounts and discourage Individual accounts
Implement Character Limit for App Names and descriptions
Implements validation for emails and custom URLS
Ability to upload & submit custom onboarding slides

Retrospective

This was one of the most complex features I have worked on at uscreen - it required a huge amount of cross-functional effort at every step of the way. Being able to run a internal usability test on a working prototype allowed us to constantly test the app builder and get feedback directly from those that have the most context in this area.

What went well

Great communication across teams allowed us to be able to make updates quickly when new requirements came in later in the project. We had weekly meetings with the onboarding and app teams to keep everyone in the loop and they often had valuable feedback along the way.

Lessons learned

Simple changes (like validating URLS) were able to make large improvements to the overall UX.
Running a usability test with internal employees allowed us to spot UX improvements before we released it to our customers. This was invaluable!

Did we achieve our goals?