COMPANY
Keakie
Year: 2021 - 2022
Role: UX Designer, UI Designer
Team: Product owner/CTO, iOS Developer, Android Developer, CEO, Head of curation, Curator relations lead, various music curators
Overview
As the first hire for Keakies core music offering, I would lead on the UX and UI for what would become Keakie's MVP app on both the iOS and Android stores. Working in scrum with the Product Owner / CTO, iOS Developer and Android Developer, we would successfully launch into both app stores within 4 months.
Process
Due to the nature of Keakie being a start up with the end user base being non existent, we adopted a Lean UX process within our sprints. This enabled us to internally define the problem, and the opportunity to test our thinking and designs with Keakie's other audiences, including DJ's, mixers and music curators who are specialists in specific music genres from Latin America to Hip Hop, to Drum & Bass and Techno to name a few.
However, before you do read on, this wasn't a polished end-to-end process. Keakie is a start up and I adapted and delivered quickly where I needed to. I couldn't always get the capacity I needed or continuously pull people into workshops. I was working on several priorities at any given point in time in order to deliver value and move onto the next priority. My developers were incredible and we worked closely, to the point "hand-offs" weren’t necessary because they were as close and involved in the designs as I was. From design crits to refinement and to reviewing and crafting our atomic design system along the way, this might not have been the ideal end-to-end process, but we delivered.
Research
Stakeholder interview
At the time, Keakie's site had been in existence for 2 years approx, so I wasnt starting completely from a blank slate. Whilst there were no qualt or quant data to draw from, I wanted to absorb from the CTO (founder) the story of Keakie to date. I needed to better understand Keakie in its wider context of music and the thinking behind the product.
I wanted to get beyond this need to launch an app because that is a solution to an unknown problem. Whilst Keakie was not in a position to validate whether an app is the right thing to do, it was fundamental for me to understand why would a user choose us over Spotify or Apple Music? Are we attempting to reinvent a wheel that doesn't need to be touched? The questions and the dialogue went beyond the scope, the goals of the product and who is Keakie's audience. This stakeholder interview was the deeper context needed in order to shape how might we redefine how users discover music which in turn, would become Keakie's USP.
"Users stick to the same music they know with little or no motivation to discover new music when it comes to platforms like Spotify. Being able to create a playlist is a detrimental feature as we're contained within our comfort zone."
"The reason why a user would choose song "X" or "this" playlist is because they believe it represents their mood or activity. Contextual listening needs to be at the front through personalisation, not the other way round where users need to treasure hunt for it."
"What is the point of a playlist in which a user becomes so familiar with, that over time they just start skipping the majority of the tracks listed? What if playlists were curated by DJ's and specialist music curators?"
"Personalisation as a term is thrown around so loosely. What does it mean have to have a personalised listening experience? Music that we love is either recommended to us or something we hear in passing. We want to bring that human touch to users through expert curation."
Declaring assumptions as a team
The app had the beginnings of a roadmap based on the thinking above from our key stakeholder, but it really needed a common starting point which is what declaring assumptions as a team would give us. Assumptions are of course our best guess on what we know today until validated. They are filled with risk, but by collaborating with the wider teams we would give everyone the opportunity to ask questions, the problems in which we think we're solving and how to best solve those problems. The wider team would include those who are music industry experts, music curators, CEO and our CTO.
By working in this cross functional capacity, we're immediately increasing the product thinking of the entire team. The team not only voices their opinions and concerns, but are able to hear other points of view which moves them from a discipline specific view to a broader and holistic product focused one.
Over 70 responses were generated from the team and categorised into themes / topics which were then prioristed or de-prioritised, voted and discussed collectively. This would become our anchor into shaping our MVP in order to start delivering value for hosts, new listeners and wider conversations.
Defining the problem
user stories
Taking the priorities as set by the team, I was able to translate these into actionable user stories that we could start pointing to with acceptance criteria attached which would be agreed with key stakeholders so there were no suprises when reviewing the thinking in design crits or feedback collected from users.
Proto-Personas
Personas are typically used as a tool to represent what we learned in research / discovery if conducted. With proto-personas, I was able to change this from being a one-time untouchable delivery to a deliverable which gets us moving to start delivering value to users. This enables us to take our assumptions and focus on the immediate needs until validate. Proto-personas are re-visited everytime something new is learned about our users which could eventually be used to inform a wider discovery piece.
I created these proto-personas to create a shared understanding of the problems we're solving as the baseline for our MVP app and as a reminder to the team that we're not the end user.
Design Considerations
Content is key
We don't need to re-invent the wheel when it comes to how content is communicated to our listeners. The content, our shows are what are unique and needs to be at the front for our listeners. Design shouldnt get in the way of this and the information hierarchy should be clear. This needs to be stripped back and simple.
Knowledge is power
Our listeners won't all know who each of our hosts are, so we need to ensure the right information is available at the right time. We don't yet know the value in which context gives to our listeners, but we are a platform for discovery and part of that experience is being informed.
Expectations at a base level
We're a music stream platform regardless of our mission. There are base level expectations our listeners expect from us in terms of behaviour. We're not in a position to develop on what is universal behaviour and expected of us.
Simplicity for an introduction
Considering users from similar platforms, we don't want to clutter or distract listeners from engaging with the product and what we have to offer. Engaging with an episode is our golden path. We're unique in our offering, but we need to ensure that we're not over thinking the product at this point.
High-fidelity designs
Shows
Due to the Keakie site already being in existence, I was able to start interpreting the look / feel of the site with new components for the app. This wasn't the time for a re-brand or adding components for the sake of creating something new. It was important that we were always trying to keep effort as low as possible.
The hierarchy of which information was prioritised was ensuring that the listener was in the know of who the host is and what the show is about. Discovery is what drives Keakies mission and informing the listener the right context of a show they had landed on was key for us as we want to encourage users to become familiar with the tone of a show before deciding to engage with an episode.
Discovery
The first screen users will engage with beyond the login process. This page is pivotal in achieving what discovery means for Keakie. We're relying on genres to lead our users at this stage because the shows themselves won't mean anything to the majority of users. There is value to be validated in the metadata communicated, e.g. the type - mix/radio/podcast being displayed as well as the artwork covers themselves in terms what is the user understanding.
Keakie represents the underrepresented and the shows brought onto the platform are picked by a human. There is significant opportunity for this page to be pushed further when thinking beyond an MVP. However, what we have achieved is an immediate resource for users to dive into and try out a show with minimal interaction.
Users will be served a recommended show at the top, followed by an organised list of genres. These are accompanied by a short description - this is particularly useful when more underground genres are displayed to the user which might not be so familiar to them.
Applying Hick's law, we've kept the amount of shows available to a user restricted in the viewport as we want to limit the amount of thinking time on the user making a decision to move forwards.
The genres and their corresponding shows change over-time depending on which genre / sub-genre the user is getting the most out of.
The Player
In comparison to the rest of the product, the mini-player had clear expectations in terms of what information we needed to display. The challenge then becomes around how we place this information in an environment which continues to push forward the host, but isn't over the top for the user. Over 20 variants were rapidly created with some being displayed below. When we think of mini-players, a handful of brands come to mind and whilst we're not wanting to re-invent the wheel, we needed to define the mini-player which belongs to Keakie and doesnt feel like any other.
The full-screen player (FSP) came before the mini-player which gave us the inspiration to produce the variant we would go live within the app stores. The FSP gave us the opportunity to nod towards the host even more with the artwork situated in the background. The hierarchy of information and placement of this was the challenge in this task. We opted for the episode name being the primary header in this instance, as the user is in the state of listening to said episode rather than positioning the show name above this. The secondary objective was the handling of the metadata "now playing" - this is the current track being played within an episode. It's not the focus like other platforms so we were able to reduce the prominence but not lose the importance of this key piece of information.
Genres
With 16 parent genres, we wanted to bridge the gap between sub-genres and the end user. Casual listeners may not be able to distinguish the difference between Liquid and Neurofunk on the surface, both of which are under the parent genre, Drum & Bass. However, we want to increase the users knowledge so they feel confident not only knowing what they're about to listen to, but can identify themselves with specific genres which they have not heard of before. Is it the BPM difference? The tempo change? The energy difference? The smallest changes can define one sub-genre to the next and may even just help the user establish exactly what they need and choose to listen.
There is no limit to how many sub-genres a parent genre may end up having and we wanted to future proof this. Consideration was given around grid vs list, but felt this could overwhelm the user. Given the state of which the user is at in this journey, is the user wanting to explore or search and find? We kept this to a list view as part of our MVP as this gave us the confidence that clarity was being met and we weren't trying to force information at the user.
Test & Learn
Whilst we didnt have an established audience whilst Keakie is in its infancy as a product, we do have a range of industry professionals who would be using and supporting the product - this includes hosts themselves which are those who generate the shows / content on Keakie, DJ's and music curators.
Usability testing was kept light throughout the product development as we aimed to achieve rapid feedback whilst identifying patterns and placing other feedback collected into a parking lot which may or may not inform a future backlog.
We tested what we had ready at the time regardless of the fidelity. This was particularly useful as we were able to have discussions around thinking and expectations of behavour which may have been different to internal thinking.
Retrospective
This is just the beginning. We're in the app stores and Keakie is yet to secure the funding it requires to officially launch and drive acquisition. We achieved on delivering an MVP app and we're continously receiving positive and constructive feedback. The app has achieved a 4.8 rating in the iOS store and across both iOS and android stores, over 2.5k users have downloaded the app.
What I felt went particularly well was being able to continously discuss and work with our leadership team to challenge our thinking and always to be recalling on the problem that we're trying to solve through our deliverables. By working in such close collaboration, we were designing together in theory and was always striving to be user-centric, despite not having the resource or cadence of user testing.
At times, we got caught up in the nuances of our outputs which really should have been handled at design crit stages or blocked out for discussion. Nevertheless, we kept moving forwards and successfully delivered the app.