project duration : 9 months
TOO BROKE
ARTISTS
SUSTAINABLE LIFESTYLE APP
the brief
Provide people a simple, intuitive way to connect with an expert in nearly any field within seconds so they can feel more informed and more prepared to face their everyday (and not-so-everyday) problems, via a mobile-first, responsive web app.
the problem
Our local working class artists and small businesses need an effective and efficient way to interact with their communities. Over the years technology and more recently, the coronavirus pandemic have negatively impacted their ability to remain consistently and economically sustainable (without the help of lending/debt) and have isolated them from one another and - what once was - their very own economic ecosystems. We will know this to be true when we see how many artists, entrepreneurs and small businesses not only use the app, but use it to create beneficial financially sustainable opportunities for themselves.
Scope
what I did
ABOUT
The Too Broke Artists (TBA) App is a social networking app that brings expert tools and resources to the fingertips of working class artists wanting to build themselves more consistently sustainable lifestyles.
Features
-
Mobile-first, responsive web app
-
Instant chat/messaging
-
Video conferencing
-
Simple appointment bookings
-
Barter & trade payments
Research
Talk to users, create prototypes, get insights, iterate, improve
Design
Sketches, wireframes, typography, visuals.
Strategy
Product planning, rollout plan, release cycles.
Analytics
Colour coding and all the other analytics we did for this project
Bringing it all together
Understand
RESEARCH
Get to know the competitors
In this first research phase, it was important to review a broad range of competitor apps instead of only those catering to artists or creatives. The most important feature each app needed to have in common was their ability to provide expert resources or skills to the users combined with an instantaneous virtual connection. This approach allowed for a more in depth perspective on how to proceed building an app that could do more than just earn them money, share a skill or offer a service.
After reviewing over 10 similar products I chose to get a more in depth understanding of proSapient & Bandsintown.
Here are some of the other products researched:
-
YouTube
-
Bandsintown
-
Patreon
-
Fiverr
-
Encore
-
Masterclass
-
Upwork
Competitor Analysis
Prosapient
proSapient’s expert network research platform allows users to gather insights from executives around the globe via consultations or large-scale surveys. Their unique range of features allow users to manage projects easily and maximize the value of their insights. "Find that subject matter specialist you are looking for with proSapient.”
Overall strategy:
-
Provide a broad range of experts from large corporations to niche markets.
-
High quality technical performance
-
Unique support, management and organizational tools to store, follow-up with and implement research inventory.
Market Advantage:
-
proSapient works within an already established market where direct/specific marketing is used to create word-of-mouth marketing and establish a quality base of experts. Prosapient used the LinkedIn platform to find and implement users and experts, paid consultations, SEO and more, while boasting a secure platform for sharing sensitive information with impunity.
Skillshare
Skillshare is an online learning community with thousands of classes for creative and curious people, on topics including illustration, design, photography, video, freelancing, and more. On Skillshare, millions of members come together to find inspiration and take the next step in their creative journey.
Overall strategy:
Skillshare markets heavily to content creators through youtube and facebook. Their strategy is to attract teachers who have any skill to share and members who are looking to learn from their peers at a competitive price.
Market Advantage:
proSapient works within an already established market where direct/specific marketing is used to create word-of-mouth marketing and establish a quality base of experts. Prosapient used the LinkedIn platform to find and implement users and experts, paid consultations, SEO and more, while boasting a secure platform for sharing sensitive information with impunity.
TBA Profile
TARGET AUDIENCE
The target audience for TBA expert app is for any person who needs the advice of an expert but may not have a friend or family member to call. We expect the age demographic to be between the ages of 18-40, this group targets a range of people who are not only more likely to elicit expert help, but who are also more likely to use this technology/method due to their demographic, unlike younger people who wouldn’t likely consider speaking to experts and older people who may not have the prowess to use our chosen technological component of the video chat.
COMPETITION
There is limited competition in this niche market of Musical Experts, making it a prime market opportunity. Other apps focus on a different type of expert, usually those servicing the corporate or digital world, and are therefore marketed as such. These apps however are well designed and have superior functionality, providing their users with good usability and results. The main competition will come from other artist focused apps that may not have already integrated such a feature into their product, who may decide to build, integrate and quickly market this feature into their app. Our competitor music apps have large financial backings that may allow them to reach the market first, with superior marketing and programming. We must to show why our specific platform is more beneficial specifically to user seeking expert musical advice than a more broad platform.
RISK/OPPORTUNITY
The primary risk is that our app will be used as a feature of other larger platforms which may make reaching our target audience more difficult or render our app obsolete. This may cause our app to not draw a user audience necessary to remain sustainable and beneficial to the experts on the Platform. However we could also use this as an opportunity to collaborate with the larger apps already garnering a large portion of the audience to grow awareness for our product and to grow more quickly than going it alone. This is also an opportunity to build an app that encompasses the best features of our competitors apps in a more streamline, efficient product.
CONCLUSIONS
It is possible to offer a competitive application that provides a solution for the music industry. The key will be a streamlined user experience that puts the users and their needs front and centre. Collaboration with other prominent apps and creating a strong need within our market for such a use while ensuring our app has a strong purpose and advantage along with it’s messaging and marketing be extremely important as we’ll need methods for getting our app in front of people and ahead of the competitors.
Understanding our users
In this portion of our design process, I was able to examine our Users through many different lenses. Through our research we were able to understand who our potential users are, allowing for a thorough first iteration of our app that takes into account not only our findings, but hopefully what real users would consider a useful app which they would actually use.
Research Methods
For this stage of our process, I employed user surveys, user interviews and contextual inquiries to build and develop the TBA app. Heading up research with user surveys, provides the clearest insight about who are our potential users. However, placing the main focus on user interviews and contextual inquiries, will provide more insights and a more in-depth understanding of the behaviours and problems from our users.
Research Goals
-
Determining what kind of creative or musician our interviewees are, or category they find themselves
-
To understand why our interviewees would seek out our product or similar by identifying “pain points”
-
Understanding the likelihood of musicians seeking advice/collaboration etc online or through a product/app
Listening to our users
User interview findings
USER PERSONAS
Based on our research I was able to construct 2 User Personas. The TBA (Too Broke Artists) App is intended to fill a resource gap for "non-professional" or "working class" musicians by way of expert advice/mentorship. Our research uncovered that our users were both advice seekers (users) and givers (experts). Here we have Stormz a working musician looking for ongoing mentorship to improve her art and her skills. Matthias on the other hand is seeking both the opportunity to lean on his fellow experts as well as remain an expert for a larger pool of people. This app would provide solutions for both.
USER JOURNEYS
Our User Journeys help us to visualize how a user may use the app and which features could create friction and which features are helpful...I have based their reaction against the industries standard way of using an app. Although, this is satisfactory, I would probably create a more unique journey for this app to avoid some of the points of friction.
Prototyping
SiteMap
When designing the site map for the TBA App, I already had in mind the categories I wanted the navigation to follow. From there I was able to more fully realize all of the pages I wanted each category to contain. Card sorting though meant to help me to confirm the viability of my site map, instead brought no need for reorganization. This was not necessarily because my sitemap is perfect, but that my card sorting process may have been flawed. Participants recategorized almost everything and no two applicants reorganized in the same way. The result of the card sorting, enable me to see the need for clear top-level navigation. That being said, I believe that within the context of the TBA app, users will have no trouble following the structure I have laid out. I look forward to further testing of the prototype to better understand the needs and behaviours of my users, as it relates to the organization of the app.
Low-fidelity
I began creating low fidelity wireframes for the three main features of the App. The focus at this point was the basic navigation and the primary pages of each feature. The phase was an important building block, confirming how I users would move through the app, as well as establishing how I wanted the app to look.
I enjoy this task, it's the moment when all of the work begins to come together. Although simple, creating such a prototype requires a great deal of forethought and planning, research and understanding for what and how your users want to see and engage with.
HIgh-fidelity
I took my time with this section and created the highest fidelity prototype I could. I couldn’t wait to bring this app to life!
Mid-fidelity
Usability Testing
At this point in the design proces I had already spent dozens of hours with my protype, getting it ready for our test group to try out. I would have to take a few days, here and there, away from the prototype to gain fresh perspective, while desiging the high-fidelity wireframes. Throughout this process my main concerns were; “does it make sense?”, “Is it clear enough for others to understand”, “does the design style I’ve chosen work for this type of app?”. These thought are ultimately the foundation for my Usability Test . I would observe how others interacted with the app and ask them to complete specific tasks, particularly if my observations uncovered they missed something or didn’t interact with app in the way I had anticipated (eg., the majority of my participants did not use/click the Home button at all. I would ask if they could locate the Home button and continue to observe without interference). The following pages outlines my proces, results and conclusions.
Usability Test Plan
Usability Test report
Once the Usability Test was completed and I had reviewed and organized my notes, there were a few repete errors, participant suggestions and navigational errors that were highlighted. Most users understood the purpose of the app, however I also decided to test a user outside of my target audience and this app made no sense to them. With all of the information that the Usability Test uncovered, it was my conclusion that the major errors were as a result of technical mistakes and the limited function of the prototype. Every user was curious to fully explore the app, however were frustrated when unable to click on non-hotspots and it ultimately confused the user and limited their options and enthusiasm to continue to click through.
PREFERENCE TEST
preference test summary
The results of this preference test were very eye opening, and served to further reinforced the importance of taking a step away from your design to properly absorb different perspectives.
According to the participants from the Usability Test in task 4.6, participants either overlooked the copy, or didn’t understand it (Question 1). However, 100% of Preference Test participants answered A. This was the original copy that I re-iterated twice and couldn’t make up my mind which to use.
Usability test participants also wanted to see the chat/message icon on the thumbnail and not only when viewing the full profile (Question 2). However, Preference Test participants seemed to understand that they would have to click for access to further features, which was the intention behind the design choices in this instance.
Question 3 was a designer question. My first draft utilised the rounded edge and the frosted overlay as a background to the text. The intention was to present elegant and less common design. However, Preference Test participants overwhelmingly chose B the more classic design style used in similarly designed apps.
While the results of the Preference Test, do help to sort through some design decisions, it’s important to also keep in mind that Preference test participants don’t have the context of having used the app. That being said, based on the follow up question “Why did you choose this version?” the reasoning provided seemed very clear and despite, the Preference Test participants having never used the prototype, I feel the feedback serves as unbiased and very helpful for updating design, which will ultimately make the app more user friendly and easier to navigate.
Final thoughts
I really enjoy this part of the process, being able to test how people view my designs was enlightening and educational. That being said there are a few things that I would change about my approach to both the Usability test and the Preference test.
Usability Test
-
Be more conversational when presenting and explaining the test - I would be more conversational when performing the test script. Rather than reading it, I would memorize the most important points and make it more interactive so as to maintain the participants attention. I was able to observe that participants seemed to tune out when I was reading the ‘instructions’ and then were confused as to what they were doing and what level of prototype they were interacting with, even though I clearly state this information in my ‘instructions’ prior to beginning the test.
-
Provide a more complete task flow. I would have fleshed out more screen and more interactivity in the app. This was unfortunately due to my level of design experience and time constraints. I had some trouble getting the design to make sense on the page. Although it wasn’t a bad prototype, it could use some further iterations and then more testing.
Preference Test
-
Keep the design differences consistently different. One of my designs was too different from the other (Preference Question 3), and the other just wasn’t pretty (preference question 2). For question 3, “which thumbnail do you prefer?” the design differences were two different for people to make a proper evaluation. And for question 2, the addition and the position of the chat/message icon was not very aesthetically pleasing and added more clutter than value to the page - which was not my intention. Had I taken more time with this design and added the icon to a more obvious position, my results and feedback would be different.
Refining the desing
We made it! And now it's time to hand off our polished product to the developers. Below is the TBA design bible. A tireless accounting of every detail of the look, feel and voice of our design... wow! This is awesome!
Design Iterations
Splash Screen
The splash screen has been an interesting struggle for me. Although I had the name of the app and tag line worked out before beginning the project, this is really where the vibe and the colours design began for me. I settled on the colour pretty quickly after some quick google searches about how colours influence people. But then there was a question of the logo and how to use the colour. Background image or no background image? Just colour and logo? You can see below that we landed somewhere between creative and corporate. I hope to eventually have a better logo, and in the end, we will use the “no image” screen as an accessibility feature for users who do not have access to newer or expensive technology.
Onboarding
The onboarding process is a very important stage for the TBA app. We have chosen to use it to explain to the user it’s purpose and benefits to them. The onboarding begins after the splash screen and over 4 pages should introduce the user to why they would want to use the app and how it can help them. It was important for the TBA language to be consisely but complete and descriptive. This was something I struggle with, but once the language and tone of the app was fully established this process cam much more naturally and easily. Along with great feedback and multiple iterations we came up with something that works, is clean, consise and uncluttered. We applied our accessibility feature aswell to allow users to use less bandwidth. While cleaning up the copy, we also cleaned up the, logo, the transitions and really focused on nailing our TBA language, voice and vibe.
welcome screen
home screen
The home screen was reiterated many times. I think the final version, give the app a unique look and works better to ensure the creative tone we are looking to elicit. I originally designed it to be a scroll down and across screen with links to arrows to see more. I wanted to use a disappearing bottom navigation and display the user’s location in the header. The high fidelity prototype replicated the wireframing design, however was too much design, too cluttere and too cumbersome for the user. The usability testing returned valuable insight that allowed me to simplify and streamline the design and pay more attention to the visual appeal, which worked better with the users sensibility - the artists sensibility. The final design removes all unecessary buttons and features, eliminate the use of drop downs or too many “view more”arrows. No hamburger menus. Everything is contained withing the pages available and the bottom navigation. For the artistic user we have designed this app for, we beleive that the idea that “less is more” and will be much more effective at reducing the users friction when interacting with our app.
Profile screen
The profile screen was my biggest challenge because I wanted a lot of information on the page and felt limited by the space provided on a mobile screen. I wanted it to have all of the buttons that I wanted, but didn’t know how to manage them on the page. My first iterations were cluttered and clunky, and still did not offer everything that I had imagined offering. When I realized I was limiting myself to the size of the screen, I quickly began redesigning vertically which allowed me more space to incorporate all of the features I wanted to provide the user in a much more palatable way. Once I let go of the idea of having to cram everything into the portion of the page that the user landed on, the page design came much more easily and also provided the inspiration for the Home page design.
Search screen
The search/discovery screen presented a very unique canundrum for me. On one hand I knew exactly what I wanted for this screen, only I had no idea how to execute it. This is a screen that is still in progress, however, one thing that I felt too cumbersome was incorporating some sort of filter. The filter version of this function required an inordinate amount of additional screens to support it - it just seemed like too much. It also didn’t seem appropriate for the style of this app and for consistency of desing it seems out of place. So there needed to be another way to convey the filter, other than the conventional way. That’s how I started to think of categories within categories. I haven’t yet perfected it, but I do believe this is the way forward. An example of a category within a category would be what you see on the on the second iteration. I thought of using colour coordination to indicate which sub category each category belongs to. My first iteration of this utilised colours too similar, and therefore with each subcategory, the differerenciation became less perceptible. I wanted to stay within the colour scheme of using the family of pinks/blues so my second iteration of this is attempting to use colours which are different enough to be able to support their own “sub-categories” of colours. I’m still not sure if the colours I have chosen will have the intended effect, however this particular screen will be a part of the “what’s next portion of this task.
search feature example
Search screen
