In 2016 I joined Nextbit – the small, scrappy startup that made waves in the mobile community and shipped the first-ever, cloud-storage smartphone called The Nextbit Robin was launched off the success of a Kickstarter campaign, which primarily meant that our main concern wasn’t with designing the world’s best phone – we knew we were a small fish in a big pond already. Instead, we just wanted to do right by our backers and fans and design a cloud-based smartphone experience that would wow our backers.
I joined the team during the early-middle part of the phone’s development. During my time at Nextbit I was in charge of designing Gallery, Camera, and Smart Storage applications as well as designing UI elements for our device’s cloud-syncing functionality.
At the time that I joined, the phone had already been launched and was live – so efforts mainly focused around fixing up issues users were experiencing, polishing and fleshing out features, and making upgrades and improvements to each individual app’s overall experience. I used Sketch and After Effects throughout the project.
The gallery app is the equivalent to the iPhone’s Photos app and it stores all of the photos are taken with the camera. When I came onto the project there was already an initial idea and design of the app. My job would be to start from there and finish the app out entirely.
(inherited design starting point)
The first part of my process was to step back and define what the goal would be for the project and what outcome we were looking to deliver. The problem that presented itself to us was, “How can we create a gallery app that lets users view their photos in an efficient and appealing way?”
After defining the problem and gaining consensus of what we were shooting for, I aimed to further refined the problem into specific goals and outcomes.
User Goals
• View photos – be able to see my photos, beautifully
• Scan photos – be able to peruse through my photos at-a-glance
• Find photos easily – be able to navigate my gallery and find a photo that I captured within a relative timeframe
I started by exploring the navigation structure for the app. Getting that right would help the other two goals (scalability and viewing) fall into place later. I initially did a wide range of exploration options that would enable the user to browse photo sets by year, month or week.
The challenges were finding ways to navigate photos elegantly while simultaneously deciding how far I wanted to stray from existing design patterns. Through the explorations, a few things became clear:
• Even though it was an interesting idea to be able to view photos as a calendar format we quickly decided this wasn’t an efficient direction to go in because he couldn’t see how many pictures you had taken in one day, not to mention displaying bursts and videos captured. Having multiple date picker navigation elements proved to be confusing. We initially wanted to have an album section but it became confusing to figure out where to put it.
• Maybe it isn’t best to put too much emphasis on date navigation. If our goal was to eventually show off the photos within the gallery, that would imply by default that the date picker – or whatever method we would eventually use to choose the timeframe to browse within – would need to be minimal and unobtrusive.
• We wanted to keep the top header area clear of extra icons and clutter. Therefore, if we couldn’t make a mode or sub-feature work within the gallery itself, and do it in a beautiful, seamless way, we would remove it to avoid detracting from our main purpose of the application – displaying a beautiful, usable gallery.
After rounds of iterations and reviews with stakeholders, we landed on a suitable layout and direction. The gallery looked clean and presentable and navigating photos was possible through scrolling and also by pinching or expanding gestures to go up or down in granularity.
I had found a clean and elegant way to display the date ranges and even added the option to hide the dates using the dropdown. The team was fine with the result as well. But to me, the experience could still be better – there had to be another way to hide or show dates without having to resort to using two taps just to do so.
My proposed solution to this was to turn them into “peeking dates” – time period rows that are open when you’re swiping and remain on-screen for a moment after before returning back to a condensed view.
This solution was accepted and implemented, but there was still another issue on my mind that needed to be resolved…
How would users be able to scan through their gallery if they have thousands of photos? If they had to swipe, pinch and expand via gesture just to “helicopter” over to the part of the gallery they want to see, it would be very inconvenient.
To rectify this, I designed a small scrolling element that displayed the month and year while rapidly scrolling through their gallery. Using this timeline scrubber would allow the user to scroll through their gallery at a higher speed than just swiping while still giving them a point of reference to where they were browsing in time and date.
The end result was a beautifully structured gallery that was easy to navigate and provided context right when needed. Designs were handed off to engineering and I saw them through to ensure proper execution. The app launched with the phone’s release in February 2016.
This project was also inherited in a sense, as the main camera design was complete when I started this project. However, the slow-motion feature had not been designed yet – this is where I came in to help.
(inherited core camera app design)
I started wide by exploring different possibilities. We had early ideas of what direction we felt would work well but wanted to perform due diligence and explore all the options on the table.
In further iterations I explored incorporating more of our brand colors, using text instead of an icon to indicate the user is in slow-motion mode, and using motion around the shutter button to communicate the concept of slow-motion.
The team eventually settled on a final solution that consisted of using our light melon brand color, simple text, and motion around the shutter icon for the capturing portion of the mode. For the clip editor, we settled on a transparent header and a more minimal timeline design.
For this application, it used the full capabilities of our cloud-based system. Having everything on the device be capable of living on the cloud meant users could free up tons and tons of storage space on their actual device. But that opened up a whole array of complexities and complications when it came to figuring out how to use and interact with this cloud. An interface needed to be built that enabled users to have a clear idea of what was in the cloud, what was going up to or down from the cloud, and what was actively ‘installed’ on the device itself. All the terminology we would need to reinforce this design would also prove to be equally challenging – but the team and I were up to the challenge.
So where do we start? We had multiple meetings discussing all the cool things we could technically do and what we would like to do. Before it turned into a free-for-all though I worked with the team to narrow down the goals of the app and what the user would want, expect and need when it came to managing the device’s storage and content.
As a result, we were able to come to the following goals and sub-features we would need to create a clear and useful end-product. Users were going to need to be able to do the following:
• Have visibility into their storage insights. At any moment, the user needed to be able to tell how much space they have either on the device or in the cloud. Ideally, they could have a breakdown of what their storage files consisted of (video, pictures, apps, etc.)
• A way to manage apps between the cloud and device storage. Since we learned in our analytics that a lot of users would push and pull apps to and from the cloud, as well as archive (“offload”) them, there may need to be a dedicated app management section as well as a way to manage their app collection in an easy and intuitive way.
• A way to know what was recently uploaded, downloaded or archived. There needed to be a way to see what recent activity occurred so users would have a confirmation and running history of sorts, documenting what has or hadn’t been downloaded, offloaded or uploaded for their immediate (or not-so-immediate) reference. When they last synced their phone with the cloud and backed up things to the cloud in case they needed to pull from it later rather than reinstall the app from the Android App Store. I started by wireframing what would be our management application called “Smart Storage”.
Here is a sampling of the early wireframe iterations – suffice to say, there were many. And along the way we made great progress and got a lot more clarity on things, considering trade-offs and putting the design through the wringer all for the sake of the user.
Once we agreed on an overall layout and flow, I did more iterations in high-fidelity. We made a solid amount of progress but still had a few kinks to work out. We needed to refine the flows for both pinning and archiving an app, and also handle syncing a little more seamlessly.
With one last push, we reached a solid solution that met our goals and met the needs of our users according to the beta testing with core users.
My Reflections & Lessons
During the project, I learned a lot. As my first official design role after finishing an internship, I learned so much about creating hardware, software and the overall implications of a real-world design project. I would like about marketing, engineering, design QA, and a little bit of entrepreneurship by working closely enough with the CEO and CPO to get an idea of how the company was doing an overall direction things were going in. It was an invaluable experience and the challenges and pressures that I experience at the company really grew me personally and as a designer.
Some key takeaways:
• A true, in-depth experience. It was a very cool and unique experience to be able to see the whole production process for both hardware and software products. Having the chance to work on apps that were closely tied to our own physical product was a very valuable experience. I was there early enough to be able to see the excitement that was generated around the product and got a lot of insights into the details of things because the company was so small and everyone communicated so well. Very rarely do designers get to really see and understand how every part of a company works and see the details day-to-day. So I’m super grateful for the journey and all the experience I gained from it.
• More user research. Looking back on it, because I was so new to design (I had been self-taught for about 8 months before starting at Nextbit) there was a lot of time spent on just keeping pace while doing the most basic of design tasks. And while resources were slim and timelines were short, I definitely would’ve liked to spend more time researching, both qualitatively and quantitatively.
• Proactively define the product. I would’ve also liked to spend more time sitting down with the team and figuring out what each app should have in it and what was feasible within the amount of time we had remaining, considering engineer in efforts and overall bandwidth. I definitely feel like I could’ve structured the conversation more and helped shape the product and process in a way that would have streamlined things, leading us to a more efficient process and effective end-product. These are all learning points I would take note of and improve upon in future roles and projects.
