What is ListenBoldly?
ListenBoldly is the the official iOS and Android app for the Seattle Symphony, which is located in downtown Seattle at Benaroya Hall. App users can search for events at Benaroya that interest them, purchase tickets, and have their tickets saved to access through the app on the day of the performance.
Our Project
As a team project for General Assembly's UX Design Immersive course, we were asked to improve upon an existing product or app to solve a specific business-related problem. My team was assigned the Seattle Symphony's ListenBoldly app.
As the Project Manager and Information Architect, my job was to keep our development schedule on track within our short, 2-week schedule, and to organize ListenBoldly's content to improve usability.
What
Mobile e-Commerce App
Where
General Assembly
Team
Me plus 3 other UX designers
My Role
Project Management & Information Architecture
Timeline
2 weeks
Project Scheduling
My first job as the Project Manager was to make sure everyone knew what they needed to be working on right away. The first night of the project, I put together a Gantt chart to assign due dates for each step of the project. These dates weren't hard and fast, but they kept the workload on track.
I also set up a Kanban board using Taiga, and linked it to our team's Slack channel so we could keep each other informed of our task progress.
Heuristic Evaluation
Each member of the team subjected the ListenBoldly app to the heuristics evaluation designed by Deniese Pierotti.
We hypothesized that the app's most significant pain point was selecting seats for an event when purchasing tickets. The app simply ported over the ticket-buying page from the Symphony’s website, which was poorly-suited to a mobile app.
User Research & Affinity Diagram
While I was working on project planning, the team collaborated with our Researcher to produce a list of questions for user interviews. This included questions for the initial online screening survey, as well as for later phone interviews.
Results of user interviews produced an affinity diagram which helped us settle on primary and secondary pain points for the Seattle Symphony’s app, and find a direction to proceed. App users wanted to discover events that specifically appealed to them, and to have a streamlined checkout process that let them select their seats easily.
From there, we collaborated in putting together a series of proto-personas, which were used as a jumping-off point for crafting our final personas.
Persona
Through user research, working off of our proto-personas, we settled on a primary persona for the project. Our Researcher crafted the final persona, but I produced user stories as well as use-case scenarios that were integrated into the character of Kathy Cole.
Problem Statement
With the focus on Kathy in mind, I wrote a problem statement for the project that guided our decisions throughout the process:
When she uses the Seattle Symphony’s current ListenBoldly app, Kathy has a hard time finding events that appeal to her. When she does find an event, and goes to select her seats, the interface is clunky and difficult to use, with a lack of information on the seats available. It takes her far longer than it should to complete her ticket-buying process.
Proposed Solution
We took a three-pronged approach to solving Kathy’s problem. We would:
Give Kathy the ability to apply filters to the main event page, letting her see only shows that fit her desired parameters.
Streamline the seat selection process, with a focus on accessibility. Make information on seats prominent and easy to read.
Apply a general overhaul to the app’s UI and information architecture, adopting Apple’s HIG and making it more native to Kathy’s iPhone.
Card Sorting
Jumping into my second role on the project as the Information Architect, I conducted a card sort to gain insight on an improved app architecture. The card sort was conducted with four users, and consisted of two parts:
App pages and functionality
Event types and tags
In the first part, testers were asked to arrange cards listing functions of the existing ListenBoldly app in an organization that made sense to them. I took the results of that card sort into account when constructing the eventual final sitemap.
For the second part, I gave testers a stack of cards listing upcoming events at Benaroya Hall, the home of the Seattle Symphony. Testers were asked to sort these cards into categories, again based on what made sense to them. At the end, I asked them to name the categories that they had sorted.
By looking at how often each tester came up with the same or a similar category, I narrowed down the results into event tags that we would implement into our redesign.
Information Architecture
With the information gleaned from the card sort, I moved into reorganizing the ListenBoldly app sitemap. First, I constructed a full sitemap of the app as it existed at the time.
This sitemap was especially shallow in construction. Most major features, (the event calendar, account information,) were hidden in a "hamburger" menu in the main screen
Through iteration, we settled on a final sitemap for our project.
Our app organization put all functionality under tabs in a navigation bar at the bottom of the screen, following the standards of the HIG. With an updated Events page as the default tab Kathy arrived at upon starting the app, much more information was made readily available to her in looking for an event to attend.
Navigation Schema
To demonstrate the improved tabbed browsing in the app, I built an initial navigation schema using Figma.
The sub-nav schema for My Account and About was useful for envisioning how those pages would appear. The project scope did not require wireframes for those pages, but a real-world implementation of this project would include that work.
This version at left represents our original plan to include the Shopping Cart as a fifth tab in the primary nav bar. We later moved the Shopping Cart to the title bar, (it would only appear if Kathy had an item in her cart,) and reduced the nav bar to four tabs.
As this decision was made relatively close to completion of the project, and all members of the team easily understood the change, we decided that the time required to update the schema could be better used elsewhere, so no “final” nav schema was created.
Prototyping
To help our Interaction Designer with his workload, I assembled our prototype from the wireframes he provided.
This allowed the team to work in parallel for much of the second week. Results from our Researcher's user testing gave our Interaction Designer direction in iterating on the wireframes. New wireframe versions would be passed to me to integrate into the prototype so our Researcher could use it for an additional round of user testing, (we did two rounds in all,) while our Visual Designer used them to create new versions of the high-fidelity mock-ups.
Go ahead and explore the clickable prototype to the right!
Final Mock-Ups
While the final high-fidelity mock-ups were entirely our Visual Designer's work, I've included them here as a representation of our final product.
Project Presentation
When not updating the prototype, I spent the second week preparing our final presentation slide deck. As content was provided by the other team members, I filled in the presentation framework. As primary presenter, it was my role to keep the presentation moving, and make sure everyone’s work was represented.
You can download a full PDF of the final slide deck below. Note that the Visual Design and Iteration slides look strange since they used animated transitions during the presentation.
Next Steps
Our Researcher has constructed a secondary persona for this project as well, named Andy, but the project time frame didn't allow us to cater to him. Our proposed next steps for this project were to pull Andy back into focus, and represent his needs more. Andy wants to be able to:
Find events that expressly appeal to his interests in music.
Set up notifications for specific events, so the app lets him know when tickets go on sale, tells him when tickets are almost sold out, or reminds him of an upcoming show.
Set up notifications for specific tags, so the app lets him know when a new show fitting that tag is announced.
Our next steps are to provide new tools under Andy’s account settings to let him accomplish these tasks, using the tags that we had settled on as the result of the card sort that I ran.
We also want to extend our review of seat selection into the actual checkout process, to ensure that the entire ticket purchasing flow is streamlined all the way through.