Harmony is a new mobile OS that’s designed for efficient use and a smooth task switching experience. It makes it easier to access apps that are regularly used together by integrating their functions within each other.
Context
In January 2017, I wanted to take on a design challenge that’s different from what I’ve done before and see very realistically where my limits were at the time. So I took a mobile app design course and teamed up with 5 other designers to create this OS concept. In 4 sprints over 10 weeks, we designed everything from the design language to 12 separate apps.
Within that, I worked on the main OS navigation (app system management), camera app, and music player.
Sprint 1: What Kind of OS?
The first step was to create an identity for our OS. We knew we wanted to target young adults who are familiar with tech, but we had a lot of different ideas about what existing OS’s do well and what would make them better, and there was no clear direction. So we restarted with research.
We each examined a different default app to learn about what users liked and disliked and then created sketches to identify common themes that came from the changes made. The main insight we kept going back to was that our target user needs and values quick access, instant gratification, self-expression, but also, to some extent, privacy. This focus on efficiency and freedom became the foundation for Harmony.
Design Principles
At the end of this sprint, our design language principles were “effortless”, “tailored”, and “integrated”. Harmony would focus on faster task completion, especially between apps, and personalization.
Vision statement
Harmony delivers a seamless experience tailored to you.
Sprint 2: Defining the UX/UI
In this sprint, we had 6 main tasks relating to defining general OS standards, such as UI templates and style guides. I worked on app & system management, where app switching became my main focus.
Research
In popular OS’s, app switching usually means a lot of swiping and/or tapping to find the app from the home screen. But when thinking about how to have a more efficient app switching experience, one question I kept going back to was: is there really a need to return to the home screen?
A Different App & System Management Concept
By the end of this sprint, our OS included a pocket, cabinet, and loft. From any screen, a swipe up from the bottom edge brings up the pocket, a small drawer showing the 4 most recently opened apps from right to left. Pull that up to see the cabinet. The cabinet has the pocket at the top and below that is either a list of notifications or all of the user’s apps (swipe to switch). A short edge swipe from the top pulls down the loft. General phone settings like wifi or bluetooth and tools like flashlight would be found there.
Home Screen
It seemed like I’d covered everything the home screen meant to do. But I realized that the home served as a base users can always return to and, without it, there would be an issue of what would happen when an app is closed. So in Harmony, users can return to a “home screen” by doing a larger edge swipe down from the top. This screen has the pocket visible (as in the pocket screen above) and would show widget-like actionable elements relevant to the user at the time. So for example if a user is listening to music, that would show up on the home screen, but if they close the app, that element would disappear.
Sprint 3: A Camera App
Next, we started designing apps! This sprint focused on communication apps. Per our design language principles, we decided to integrate apps within each other so directly related ones were more easily accessible.
I worked on the camera app since I already had some sketches from the first sprint. I paired up with a teammate to integrate the camera and photos into one app since the two are often used hand-in-hand.
Problems
The camera is a pretty simple app. You open it and you want to take a picture. Many camera apps, however, clutter the initial screen with many different options, filters, and other mode adjustments. While having those options so easily available is convenient, with an increase in apps that specialize in touching up photos after they’re taken, these options largely go unused and can also take away from an immersive experience.
Changes
I reflected the simplicity of point-and-shoot by removing everything except the capture button and flash in the initial screen (first image below).
Filters and image editing can be done later but the way a shot is taken (video vs. photo) can’t be changed, which is why I thought camera mode-switching was an important feature to keep. I kept camera modes in a swipe left from anywhere on the screen (far right image).
Finally, the app is integrated with photos app, swipe right from anywhere on the screen to enter the photos section of the app.
One unique feature is the option to review a picture after it’s taken (middle image above). In my research, I found that some users preferred being able to check a photo after taking it and immediately decide whether to keep it, so I included this as an option for those users. The photos section is to the left of the camera so I prioritized that association over the familiarity of swiping right to “save” as in other existing apps. Swipe left to save, right to discard.
Sprint 4: Music Player
The next sprint focused on apps that dealt with information. I worked on a music player to do something with more complexity than in sprint 3.
Research
In the beginning I was completely at a loss about how to even get started because there were few requirements and so many possibilities. So I spent the majority of this sprint researching existing music players and talking to people about the apps they relied on and why. That included a lot of major apps like Spotify, Apple Music, and SoundCloud. An interesting one I looked at was QQ Music, a popular app in China. QQ placed heavier emphasis on playlists, especially in organizing your own and following other users’ playlists. I thought this was really important for a music player because, as a music player, being able to curate, find, and listen to the songs you want to listen to is crucial.
Design
With that in mind, effortlessly navigating through the user’s personal songs became important in my designs. This was mostly done in the Library tab. The Library immediately puts anything recently played, including both albums and playlists, first and then organizes the user’s playlists just below. The play FAB, available on every profile, immediately starts playing from that user’s songs.
The other tabs provided different ways for the user to find and discover music. Home shows updates, such as new releases, Browse is the main way to search for music when the user has something in mind, and Discover provides different methods from which the user could discover music.
A design question I struggled with was about how much I could move away from our UI templates. With the camera, I’d felt that it made sense to use a design that created a more immersive picture-taking experience, but I wanted to make sure the music player felt like it was part of Harmony without making it look the exact same as the other apps in our OS. I played it safe and didn’t move too far from our tab navigation or even the color scheme but I probably could’ve experimented more with it. I almost forgot I was designing different apps, which can have their own unique differences.
Final Thoughts
There was a lot left untouched and unquestioned in the end, especially as we started to run out of time and had to just pull things together. One of the biggest lessons was that it is so important to determine values, make decisions according to those values, and commit to those decisions. We struggled with this and ended up leaning on our research as a crutch. We explored a lot of interesting ideas but in our designs, Harmony became a mashup of some of the best features of the best apps at the time in a style very reminiscent of Material Design.
Still, it was one of the best projects I’ve been a part of. Having no guidelines or restrictions and going through research and design in rapid iterations along the way challenged how I approach design, and because of that I’m really glad to have had this opportunity.
