Project Objective
I was tasked with creating a way to seamlessly share Shazam Experiences created by the Shazam for Radio team. Ultimately I would have two jobs:
· Implement a new workflow for getting new Shazam Experiences approved and ready for sales and marketing purposes.
· Create a snappy web app for sharing and hosting new Shazam Experiences.
Problem
The Shazam SFR team gets internal requests from the sales department for new Shazam Experiences (Brand and Artist mobile experiences built natively in Shazam). There were a handful of people who had to sign off on new content for marketing purposes but no real system in place to handle these requests,
ultimately leading to bottlenecking and frustration spanning 3 departments.
Process
1. Research
workflow analysis
The first step was mapping out the current workflow to see who was involved in the process.
What was the takeaway?
· There were a number of redundancies in the current workflow. Instead of a linear progression, Shazam Experiences were being passed back and forth between departments.
· While the web app was created to facilitate a sales need, there were key decision makers in sales, marketing, and product who had a stake in how the new process and web app would ultimately function.
Key Stakeholders
refining Goals
The next step was figuring out actionable goals that didn't neglect any players while also not democratizing the design process, ruining the end product. How'd I do it?
Aligning Value Propositions - Making sure we were on the same page.
Avoiding Solution Based Discussion - Recognizing there was no quick fix.
Establishing Feature Priority - Avoiding a design by committee approach without minimizing individual needs.
"Don't Hate, Collaborate"
2. prototype
wireframing Workflow - Beyond the web app that is the center piece of this case study it was essential to design reporting patterns to faciliate the decision making process.
TESTING THE SYSTEM - I developed a a more linear reporting and decision making structure and began testing it before integrating any new tools (web app).
Picking BUILD tools - In all actuality I would be responsible for developing this thing myself so it was key to pick tools that I could build quickly with. I went with the big three: HTML, CSS, JS.
3. ITERATE
Development - The app needed to be snappy so I built a custom framework with jquery. I built the audioplayer using mediaelement.js and wrote code that fetches media on demand.
mediaelement.js was my first choice for this project as I'd used it in previous builds. The code snippet above is v2 of about v5 now of the function I wrote to grab the track dynamically. (Not the prettiest, but it works. Build fast, test live!) It also grabs all other media for the player (background, track ID picture, and title).
"Introducing Shazam Showcase"
LAUNCH - I had implemented the new workflow with a working prototype earlier that month and was ready to launch the new web app. I slapped a name on it and introduced it to the key players who would be using it in their day to day.
Further testing - The design iteration process is a living thing. At the end of every project I'm working on, regardless of my role (interaction, experience, interface UI, Identity) I like to check myself so as not to wreck myself. Does this product meet the goals I intended? Does my value proposition meet user expectation? Is this product meeting a different need?
While there were some surprises (sales leads began sharing Showcase with their own clients pretty quickly and it became a pretty effective method for sharing Shazam Experiences externally) it did the job I had hoped it would.
Showcase integrated organically into our workflow and became an essential tool for three departments within a week.
