Symphonie

A music score reader and project management tool for musicians

#HumanCenteredDesign #Music / Client: Tsinghua University Symphony Orchestra (TUSO)

2016 - 2017 / Instructors: Qin Gao, Ruoyan Li

Teammates: Yimei Huang, Chu Zhuang

My key roles

user research, UX design

THE CHALLENGE

How would you enhance the rehearsal experience and daily operation for semi-professional music ensembles?

THE OUTCOME

We proposed Symphonie—a music score reader and project management tool, designed for both practice and performance scenarios—to optimize the learning and collaboration experience for musicians and symphony orchestras. 

FEATURES

As a project management tool, Symphonie keeps, organizes and shares the music of each part of the group and notes taken by the members.

As a project management tool, Symphonie keeps, organizes and shares the music of each part of the group and notes taken by the members.

visual

Left: accent colors & icon sketches.    Right: wireframes of the music score reader and file/member management features.

INTERACTIONS

While reading the scores, musicians can locate a page or a bar with ease, quickly highlight music scores or take notes, and also effectively communicate with the conductor or other players. 

While reading the scores, musicians can locate a page or a bar with ease, quickly highlight music scores or take notes, and also effectively communicate with the conductor or other players. 

iteration-2020-preview

Iteration (WIP)

Process overview

Process overview

process-project-timeline@2x

In summary...

This project began with our:

  • love for music,
  • curiosity about the "mysterious" domain of the professional orchestra,
  • and desire to fix a longstanding user need.

As design starters, we:

  • learnt HCI & UX fundamentals
  • brought expertises from each's field, either psychology or industrial engineering

While looking back, I wish we could:

  • do more market research about existing products,
  • generate more solutions while ideation,
  • start with a few core features and did more tests and iterations. 

For process in detail, please view on a larger screen. 

Process in detail

Understand

From the personal experience of Yimei—our team leader, and the principal cellist of TUSO at that time—we realized that the current fashion of symphony playing had many inconveniences during rehearsals and performances. After fast validation with other TUSO members, we decided to move on with it to make the experience better.

To gain domain knowledge and understand our users, we started with immersing ourselves in the environment and interviewing different types of users in the first week. 

-

1. Immersion

To learn as much as we could, we did:

— secondary researches

fly-on-the-wall observations (4 scenarios)

— object studies (music sheets, folders, stand, etc.)

2. Interviews

To confirm and expand our findings, there were:

4 interviews with different roles at TUSO

1 focus group with 5 active members

interview_3_cropped

3. Synthesis

The findings were summarized and structuralized with:

3 Personas: a cellist, a percussionist, a conductor

1 mindmap of people, objects, etc. in the system

1 list of 32 user needs

Understand_system map

A mind map to show what are in the system, and the relationship between the components.

understand – v1 – needs

The main, repeatedly emerged needs we identified from the user studies.

Ideation

We thought group rehearsal as the most common scenario that also covered most of the needs. And most needs of the conductor are shared by sectional principals and other members of the orchestra. As a result, we confined the main scenario to be group rehearsal of an orchestra, and focus on the players instead of the conductor. 

-

1. Brainstorming

Based on the user needs, we summarized the "facts, feelings, opportunities, & risks" and searched existing products for inspirations. We came to the solution of a digital sheet music software.

inspirations@2x

2. Storyboards

We that illustrate the main features with storyboards:

— for principals: group notifications, groups sync display

— for everyone: bars positioning, sectional scores jointly display, page turning, note taking

The concept

a sheet music reader + team management tool

We defined the goals and functions as below, to cover the needs we thought most urgent. 

v1_concept

Design

1. Information Architecture

To simplify the relationship of the elements (sheet folders, sheet music, notes) shown below, and reduce the number of files, we made the design centered around the individual user. 

v1_wireframes_information

For an individual user (like Jane), she uses multiple sheet folders which belongs to different groups. These folders contains copies of sheet music and notes by Jane, yet many copies are of the same piece of music.

1. Information Architecture (Ctd.)

The home screen is like a "file manager" with several other components. Users can get to any sheet folder or files under any group here. 

design – v1 – home

The software is centered around the individual user. The home screen enables access to any file and group information. Selecting a group's icon will "filter" the files and info being displayed. The sliding menu is hidden when not being called, because the home screen is far more frequently used than other screens (apart from sheet display).

2. Wireframes

We started prototyping by crafting wireframes of key screens that enabled all functions. 

design – v1 – prototyping

2. Wireframes (Ctd.)

Then we drew an overall functional structure, which helped us build a complete set of wireframes.

design – v1 – wireframes

Iteration

0. Heuristic evaluations and user tests​​​​​​​​​​​​​​

With heuristic evaluations and cognitive walkthroughs, we found what we thought "simple" made the info structure confusing, and led to problems about files' ownership. There were also problems about too many features and detailed interactions, many of which were not suitable for the scenario. 

v1_test_results

We decided to go back to the initial findings we had, to restart the design journey.

1. Revisiting the user needs

We looked into the findings from the user studies once again and generated a list of 14 user needs. To rank the importance of them, we appropriated the first step of the "House of Quality" analysis and did a questionnaire study with seven members from TUSO. 

iteration – need analysis

A "House of Quality" analysis (n=7) was conducted to rank and categorize the potential needs. Seven members from TUSO were invited to compare and rate the needs pair by pair in a matrix. We then calculated their importance and categorized the options. We identified seven needs as primary (which are musts for the product), and six as the bonus (can be met by functions to be designed). The levels of importance would indicate the level of the features in their hierarchy.

After analyzing the needs, we refined the concept of Symphonie.

v2_concept

2. Iterating the Information architecture

By referring to team management tools (e.g. basecamp, teambition), we came up with the other idea that everything will be organized by groups. Though it seems more redundant, it became easier to understand instead. 

iteration – IA

Elements—music piece, sheets, sheet folders, notes—are organized in "groups," in which users have different permission levels. A group can be the whole or a section of an orchestra, a music band, a temporary ensemble, or a private one just for personal use. Any piece of music has several sectional sheets and a full score; each sheet can be attached with several versions of notes; sheets & notes could be shared within or between group libraries. Though users have access to any sheets and any personal/shared notes, the sheet of their default part and the last seen notes will be displayed every time they open the music. 

We showed the two methods to organize the elements (the previous and the new) to friends to quickly test, and this latter one was preferred.

iteration – IA – comparison

3. Iterating the interactions with the music score

For the "not handsfree" problem, we still kept using hands to keep the device simple, but tried to minimizing the time for interaction by integrating different gestures and reducing the information displayed. ​​​​​​​

iteration – sheet – comparison

We looked into pdf/Ebook readers and MacOS for inspirations, and designed the following interactions.

interactions-02

We looked into pdf/Ebook readers and MacOS for inspirations, and designed the following interactions.

interactions-01

We looked into pdf/Ebook readers and MacOS for inspirations, and designed the following interactions.

interactions-03

4. The new experience flow

According to the functions and information structure, we established several scenarios and their respective flows, which led to an integrated flowchart.

flowcharts

The integrated user flow of Symphonie, with core actions being underlined and having deeper arrows.

process photos

Working on the flowchart

5. Wireframes

The flowchart led us to several alternatives of the wireframes. Below shows the overall picture.

wireframes

The wireframes of Symphonie, in which main actions have arrows with full lines.

6. Mid-Fidelity Prototype

A rough prototype made with inVision showing the screens of higher fidelity.

* The mouse behaviors in the video do not exactly represent the designed gesture interactions.