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.
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.
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.
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.
Essentials to Success:
• Relatable/Quality content
• Call to Action posts
• Subtle branding
• Captions with passion
• Laser focused hashtags
• Excellent Imagery
• Product shots!
• 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