Raise the Bar was an original idea, designed to fulfill my own app tracking desires.
I was responsible for all design aspects of Raise the Bar since the idea conception early 2013. This includes:
Branding, UI, UX, Marketing, Advertisement
Sketch, Symplii, Photoshop, Invision, Firebase, Analytics, Omnigraffle, Illustrator
User Testing, Analytics,
Customer feedback via Helpshift
We wanted to create a gamified productivity tool, helping our ideal user to progress in life through fun personal tracking. Since this was our initial collective personal endeavor, and a brand new product that was yet to be successfully implemented on the market, we did everything from scratch.
There were no stakeholders, high-level approvals, required specs, previous iterations, established market strategies, or user metrics. Just down and dirty conversations between the Designer, the Developer, and the User.
I created early sketches and brief documentation of project features and minimum requirements. This set of standards for developing a MVP (minimum viable product) proved to keep the team on track and relatively focused; while we collaboratively allowed new ideas and advanced features to flow into our “stretch goals” or list of future updates.
Despite this organization, Feature Creep was our most reoccurring pain point throughout the entirety of the project. With limited time from each developer, and an ever-growing list of potential upgrades to the app, it became increasingly more difficult to agree on what features were essential within each update cycle.
Being a designer creating a useful, full-functioning tool himself, I find it essential to identify what tools and methods are most useful to your process, and where your holdups originate.
With such a small team of just 3, our initial attempt at a JIRA workflow proved more cumbersome than efficient, despite regularity with it. If I had to pin it down, we settled on a rough mix of Agile and Waterfall, with a mostly linear approach, through individual sprints and handoffs.
Understanding our need to remain flexible on feature implementation, I strongly believe this mixed approach helped us to define an approachable scope in design cycles, while leaving room to quickly respond to ever-changing user requests/feedback or technologies. It also allowed each member to have work readily available when the opportunity arose in their schedule.
Working directly with an Android and an iOS developer allowed for creating very unique experiences for both operating systems; however, it presented a slew of unique challenges that disrupted everything to the design process, down to the libraries used. Questions we had to ask ourselves moving forward:
What does a different navigation look like, while keeping the same look-and-feel?
How do we cross information streams, especially with different data points?
How do we offer subscriptions for features not available on ios, like widgets?
How do we explain different user flows/interactions via support FAQ’s to both devices?
Looking into user feedback within our app reviews and in-app support, we concluded that there was quite a disconnect with how we intended the user to use the app, and how they actually used it. It wasn’t necessarily a bad thing, but it definitely created some glaring problems that we didn’t anticipate.
Needing to gather more information about our issues, we used UserTesting.com to observe a large variety of users (struggle to) work through the beginning stages of Raise the Bar.
We asked the user a series of questions while navigating through the app:
User Testing provided some embarrassing results.
New users opening the app for the first time, didn’t know what the app was for!
We had some work to do in teaching the user, and it had to start with onboarding.
Acquiring a new user is most often a difficult, and sometimes expensive process. So leaving them confused and scared upon entry was a devastating mistake. Based on direct feedback from the users, I designed a new onboarding approach. As opposed to dropping them on the first page and teaching them what to do, I started by introducing them to the app with a series of 4 screens.
I created a simple way for the user to enter the app, acquire brief information with both imagery and text, while keeping the option to skip if so desired. Teaching the user directly what the app is for, should help ease into using it, while putting them in the mindset for what they could achieve.
Of course, it’s easy to assume it works. But testing was necessary to prove it. So we implemented and tested this small onboarding change through the same “UserTesting” tool we previously used, and watched as fresh new users gained considerable interest from screen to screen.
After asking the same set of questions, new users were able to answer all 4 questions with confidence, and confided that they would like to continue using the app to track what they previously input.
I created a simple way for the user to enter the app, acquire brief information with both imagery and text, while keeping the option to skip if so desired. Teaching the user directly what the app is for, should help ease into using it, while putting them in the mindset for what they could achieve.
Of course, it’s easy to assume it works. But testing was necessary to prove it. So we implemented and tested this small onboarding change through the same “UserTesting” tool we previously used, and watched as fresh new users gained considerable interest from screen to screen.
After asking the same set of questions, new users were able to answer all 4 questions with confidence, and confided that they would like to continue using the app to track what they previously input.
Taking the feedback and results from the previous test, I decided to take the user’s passive knowledge to the next level. Empty states are traditionally used for providing information in areas where there would otherwise simply be blank space. Ideally, this information helps to inform the user what they could fill this empty space with, and through bridging this knowledge gap, encourages them to do so.
Initially, I only filled in our Home page and our Tags page with empty states, signaling to the user that these places need your help with content. However, I saw another opportunity to teach the user about some of our more obscure features, by taking advantage of the negative space that I’ve previously designed into these screens.
By placing quick information about the feature when it’s turned off, the user can read to better understand the use of the tool. And as soon as they interact with the feature, more of the page is consumed by interface, while getting rid of the help information below it.
Overall, implementing these empty states were a bit trickier to test the impact; however, we did begin to see significantly less customer service requests asking for information on how to use these features. So I’d chalk it up as a win, until we can find an alternative, or more effective solution.
Pushing new users into the app turned to be one of our biggest challenges. With a budget of nearly $0 to invest in marketing, I had to find creative ways to get eyes on our product. Social media tends to be one of the more approachable ways to reach new users, but also involves an incredible amount of content creation. Weighing the costs, I decided to further define the brand in several different areas, hoping that the recognition would help with new user acquisition.
The internet is an essential leaping point for any tech tool. You can’t expect your product to be easily shared or even easily accessed if it doesn’t have it’s own unique home.
With this in mind, I built Raise the Bar it’s own unique website, with detailed product descriptions, a brand story, calls to action, and enough information to get the user curious. With links to the Apple and Android stores on the site, our funnel was a bit more fleshed out. Analytics did happen to show a slight uptick in users; however, it wasn't substantial enough to assume it was directed related to the web site's existence.
Later into the development cycle, I explored a number of ways to acquire new users. With many different social media options, I started building out a full-fledged Instagram account for Raise the Bar. It started off as a test, but later turned into a well branded account with over 6,000 followers and acceptable engagement.
With a productivity theme and subtle but visible branding, I was able to target several specific markets to test engagement and follow through. Ultimately, I drove a significant amount of potential users to our website, and in turn, to our app’s corresponding store page. As the account grew, we saw a steady climb in analytics coming directly from instagram links.
Essentials to Success:
• Relatable/Quality content
• Call to Action posts
• Subtle branding
• Captions with passion
• Laser focused hashtags
• Excellent Imagery
• Product shots!
Lessons Learned:
• Create a template
• Break your template
• Have a sense of humor
• Engage with people
• Ask questions for engagement
• Have 5 different post types
• Use tools for post timing
Considering the amount of time invested in the project over the past 5 years, it might be easy to feel like the overall end product isn't quite worth it. However, I can't downplay the importance of all the knowledge gained throughout the process, and the ability to take that experience and funnel it into any of my following endeavors.
Couple that with the recurring income from several different attempts at monetizing the app, 100,000+ unique installs, users from everywhere around the world, and an entire brand identity that some full scale companies struggle to compete with...
And quite possibly the best benefit of all?
I get to use Raise the Bar on a regular basis to legitimately fill my own needs!
Definitely worth it.