SugarSync 3.0 design refresh
SugarSync is a cloud service that allows users to sync their files & folders across their different computers & other devices. Since its launch in 2008, the desktop application has gone through two major releases. 2014 was the planned schedule for the third iteration of the app, which aimed to compile the best parts of the first two versions.
Working with our in-house interaction designer, we developed the design concepts from scratch. My role in this production was initially in visual design, but incorporated interaction design as we matured into the project.
Initial research
To know how to start the research, I sat down with the key stakeholders to understand any requirements & business goals we wanted to achieve. A short 30-minute session lead to these key points:
- Improve the experience from the not-so-successful second version
- Free reign to experiment with different layouts & visual design direction as long as it makes the app easier to use
- Try not to look drastically different from the corporate/marketing website
- Incorporate the iconic SugarSync bird in the design
- Solid colors would help make it be timeless
- Reserve a space for possible marketing messaging if we need it for promotions, conversion to paid accounts, etc.
- Our first version user base is still happy with what they have, so more of an emphasis to cater to our newest users using the second release version.
The exploration began with an invite to the stakeholders, a few key project leads & some of the support team for a one-hour brainstorm session. My request to the team was to pick up a dry-erase marker, find a spot on the whiteboard, then write out some keywords that would describe this new app. I thought of it as the analog tag cloud. We would find the common keywords amongst the team & considered those to be of top importance.
I then sat with my fellow interaction designer & did an audit of all the pages that were needed in the older versions of the app, then walked through the flow to see if there was excess in the flows. The aim was to eliminate steps or screens if they weren’t absolutely required.
First visual design drafts
Equipped now with the top level keywords, I began collecting photos & screenshots of apps & other interface elements that contained these keyword descriptions to create a moodboard. This moodboard is an excellent tool to get a quick sign-off with the team on the vibe the app should try to uphold without taking the bigger leap of actually going into Photoshop & creating a high-fidelity mockup.
In the meantime, whenever inspiration strikes, a whiteboard isn’t too far away if I’m in the office. Otherwise, my ideas go straight into my notebook.
This usually leads to some rough wireframe exploration where we would sketch out a few ideas. We would then produce them digitally on Axure, then share our thoughts on InVision with the rest of the team so they can passively provide feedback at their own leisure.
For something as monumental as redesigning the app from scratch, it required a series of design reviews at the rate of one session per two-week sprint. The stakeholders would sit in & I would gauge their reactions to some sample layouts. Though no major issues with the architecture of the screens, we were hung up on the different possible color variations.
Through constant iterations, I designed high-fidelity mockups for a few critical screens: the top-level folder view, the sub-folder level view, and the sharing dialog. Here’s one of the first screens to make it to the high-fidelity mockup stage:
We were constantly trying to collect feedback even outside of our team. We showed the work around the office & asked our peers to vote on their favorite designs.
I opened up conversation to anyone & everyone who was interested. I uploaded my screens to InVision to a wide audience & collected more feedback.
Pivot
After some survey responses from users we emailed to try out a clickable prototype, the feedback wasn’t as stellar as we would like. In general, the feedback was positive, but a common response was that users thought that because this was an early iteration of the design, the polish of the design felt “unfinished.” Some mentioned that it had more of a wireframe feel rather than a final stage visual design.
It required the prompting of our CEO to step in to ask me if I was confident in the design. I approached it pragmatically: yes, it technically accomplished all of the goals laid out in the beginning, & yes, it also answered a lot of feedback left by the team. Perhaps it was trying to accommodate to everyone that the design evolved to something more diluted.
He mentions that though much time was spent to bring us to this point (nearly four months of design work), we’re still in early stages that it may be worth it to start from scratch. I was given a new exercise: produce a handful of new & vastly contrasting ideas to see if any new directions strike us. If we couldn’t find anything, we’ll carry on with our current look.
I tried different things, even some things that defied the original requirements. I tried layouts with subtle gradients. I used a custom typeface. I broke out of trying to keep within a handful of colors. Heck, I even tried a variation where I avoided the SugarSync green color.
In the end, I’m grateful that I had the opportunity for this exploration. We decided to move on with a new direction we dubbed Skittles (because of the rainbow of colors in the left pane menu & because it’s a candy & SugarSync loves candy):
View final mockups of the desktop app »
The current live version of SugarSync 3.0 now embraces this new visual design aesthetic.
The UI kit
In order to maintain uniformity with the patterns I’ve established, I’ve created & maintained a UI kit. It’s a four-screen InVision slideshow that shows UI elements on a light or dark background. Every other slide is a screen that ‘overlays’ the specs on how to create each UI element:
Early on, I’ve asked my developers to bookmark this page, as they’ll continue to reference this. Currently, it’s now a part of an internal wiki page that also outlines the microinteractions that outline how elements should act when the user interacts with it (transitions, hover states, etc).
This carried over to our non-desktop products as well. We’ve also had to convert our mobile apps to this new 3.0 aesthetic, & they all adopt all these new patterns. Even our banner ads & print materials now utilize these same patterns.
With an established UI kit, does this mean that we’re firm in our pattern decisions? Not really. At regular intervals, I’ll make sure to reserve some time to challenge our established patterns to see if we can find better solution. Below was an exercise to see if we can improve the understanding of our shared folders to show the difference between folders that are being shared by me & folders that are being shared with me:
Also, for clarity, I’ve grown into the habit of creating pattern matrices that shows how a UI element would look at different states. Here’s how the SugarSync icon changes depending on the state of sync, displayed in the OS X menu bar, Windows system tray & task bar, as well as within the desktop app itself.
Lessons learned
Maybe it’s because I’m a people pleaser, but the biggest downfall in this project was that I tried to accommodate to everyone who participated in providing feedback. Even though I was able to appease everyone who chimed in, the design became more uninspired & lackluster.
My managers & mentors instilled some confidence in me. They reminded me that whenever I was in doubt in anything related to visual design, the company hired me for my design expertise & in the end, I should have the final say in anything visual design-related. I’m also in the position to disregard any design preferences my team may have, especially since their decisions are subjective.
With the app now live & is currently being updated, we’ve been finding some small quirks on the application framework that SugarSync is built, Qt. In translating my wireframes & high-fidelity mockups to be built on Qt, I’ve taken for granted how easy it is to set up small elements but are different in Qt. For example, button widths are fixed & not fluid to accommodate for longer text. This becomes tricky because different OS platforms display fonts at different widths. We can provide a fixed with size to make it work on both Mac & PCs, but it doesn’t solve the issue when we need to localize the button in other languages.
