Typed Mobile is a bookmarking mobile application where users can save any URL and image resources in one place, which syncs to the Typed web application.
After building Typed web application, our team decided to build a mobile app to enhance resource collection experience of users. I got onto the Typed Mobile project as a Product Owner, being responsible for coming up with Typed Mobile v1.0.0. Writing a product requirements document, designing wireframes, discussing business goals with business strategists, deciding data metrics to target, implementing data events, running Product Scrums, and finally launching it on App Store and Google Play Store, I experienced a full product development cycle end-to-end.
Role:
Product Management, Data Analysis, User Experience Design, Project Management
Team:
Team Typed
Duration:
December 2021 - Present
Results:
- Gained 100+ active users the first month after launch
Current Status:
Future versions launched
Typed as a web application is a tool facilitating the workflow of collecting and organizing resources and writing documents with the collected resources. Typed users would collect web articles, PDF files, or any forms of "resources", or references to look at, to write a document. On the web app, our users are capable of adding resources by either directly importing files or pasting links to the workspace or using a Chrome web extension while browsing other webpages.
Our team thought it might be helpful for users to have a more accessible way to collect these resources, whether it be a URL link or an image on their devices.
I started looking into whether or not to pursue building a mobile app. Looking at our user data on Amplitude, I was able to identify that the user retention rate is positively correlated with the number of resources they collected.
More than that, we realized the less time the users take in collecting resources, the higher the stickiness is. Beyond what the data was telling me, our Customer Success team got a lot of user feedback asking for a mobile version of Typed, especially with a web-clipping or bookmarking feature.
These points led to the realization that it was an appropriate time for us to start building our first version of the Typed mobile app.
It was important for me to decide what type of users we are targeting with the first version of the product. Since people have various workflows of collecting and organizing resources, I had to narrow down which personas we needed to prioritize to not only meet our ultimate goal of increasing retention and stickiness of the web application but also make bookmarking easier for those who consume a lot of content on mobile devices.
I decided to target both current Typed web app users and new users who would need the resource collection feature. Since we already have identified an ideal customer profile for the web app, I pictured a persona of a user who is currently not a Typed web app user.
With my understanding of an ideal customer profile for Typed Mobile, I was able to ideate minimal features that the ideal persona, Michael, would benefit from.
As our team had limited resources to be put on Typed Mobile, I had to plan minimum viable features that would be enough to test our hypothesis of increasing user retention rate with the mobile product.
I rated each feature I planned out based on its need, which is mainly driven by user interviews and business strategies, and the cost for building, which I was able to gauge by discussing with mobile developers. Based on the ratings, I prioritized which features should be shipped out in the first version of the product.
Typed Mobile v1.1 would have the following core features:
Based on these core features, I started writing a detailed PRD (Product Requirements Document) including user stories from making an account to performing core feature actions.
To better illustrate the written PRD, I created basic wireframes of the interface and basic interactions using Figma.
.png)
Using these wireframes and the PRD I created, the designers started creating a high-fidelity wireframe which could be used for the developers to reference when building the product.
As I realized user onboarding of the mobile app would be crucial for users to figure out the core features of the product, I decided to use walkthrough screens on the sign-in page for users to slide through.
One of the walkthrough slides introduces how users can use the Share Extension to save any articles to the app. The initial wireframe I created delivered the message of "saving any articles from any apps" with a screenshot of using the share extension.
After our team started designing the app, following the mobile design guide, the design team and I created a high-fidelity design to better match the overall design. One thing that was noticeably changed was the emphasized icon from the Typed app icon to the Share button icon, as I believed it would reflect the share extension method better.
For the second iteration of design in v1.0.1, I suggested three changes: 1) using more simplified diagram/mockup of the interface rather than an actual screenshot, 2) adding different share extension icons since on various apps and OS would have different icons, 3) changing the text to include "Share button" as it seemed unclear before.
When users do not have any resources saved, an empty state interface displays stating that the Inbox is empty.
Initially, I designed the empty state to have a call-to-action message to encourage users to save a URL from a browser. I first had put a mockup of a URL search bar to indicate the feature of copying and pasting the URL and the share extension icon as well.
However, after the first version was launched, we got user feedback stating the empty state was confusing as it was not actually displaying an empty state. I went back to the prototype and first changed the text to clearly show what the empty state is in our product - the Inbox being empty. I also made the URL search bar smaller as it seemed misleading to have an example URL to take up a large portion of the interface although the URL is there as an example.
.png)
After running a 3-week sprint, our team was able to build the very first version of Typed Mobile.
The product is currently available on App Store
After two weeks of releasing the first version, I started looking into the user data to see 1) if we are meeting our metric of raising stickiness of the web app and 2) what noticeable user behaviors arise from the product.
All the user data were retrieved and manipulated using Amplitude, then I transferred the data sets over to Excel to run analysis and create any visualizations.
One thing to note from our daily retention rate was that for those who have used the product for more than a week showed a relatively constant and higher daily retention rate of ~25% compared to the average retention rate of all users of ~10%.
To look more into how the usage of the mobile product affected the overall stickiness to Typed and Typed Mobile, I looked into the users who have 30+% stickiness on mobile after 2 weeks and compared their stickiness before and after the usage of Typed Mobile.
Noticeably, these 7 users' stickiness increased drastically from before to after using Typed mobile. I looked more into these 7 users' usage of the web app and mobile product to find out if there is any pattern.
The chart above shows most users use both the web and mobile product on the same day for most days, proving our hypothesis of the Typed Mobile serving as an extension to the web application.
Typed Mobile was the first product that I had a full ownership of as a product manager. I learned a lot about how to run a smooth product development by communicating with cross-functional teams including developers, designers, CX managers, and business developers. I was also able to learn taking features out of a product rather than thinking about features to load. Since the first version of the product had to be a real "minimum viable" product to test our hypothesis, I had to focus a lot on prioritizing minimal features that would still serve the purpose of the product.