I had the privilege of interviewing Soleio, a well-known developer and design expert, who was the second designer hired at Facebook. I heard about Soleio’s amazing work from my older brother, who created the chat sidebar with him at Facebook. After reading up on his latest work at Dropbox I was curious to learn how Soleio’s approach to design has changed over the course of his career.
How did you get into design? What led you to become a UX designer?
My design career started back in high school. Some classmates and I ran an intramural indoor soccer league which was comprised of students and faculty. The best way to organize the league was through a weekly newsletter that we started to publish. I spearheaded that effort mostly as an excuse to play with an application that I came across called QuarkXPress. One of our faculty members ended up identifying me as the student behind it and approached me with a job offer working at school’s communications office for the summer. I was able to parlay that newsletter project into two summer internships working under him and getting an in-depth introduction to desktop publishing.
Fast forward to my freshman year at Duke University. My roommate and I were starting a college rock band, and if you are the guy in a band who knows how to use QuarkXPress and Photoshop you quickly become the one-person marketing department. As a way to differentiate ourselves from all of the other freshman year bands, I decided that we were going to be the first to have a website. I got my hands on a copy of an application called Macromedia Dreamweaver, which I didn’t know at the time was designed to transition people who were well versed in desktop publishing to publishing for the web. I vividly remember the moment when I started tabbing between the preview mode and the code editor and began to realize that all of the changes I was making to the web page design would directly manipulate the underlying code. That was a big “ah ha” moment for me, because I started to realize that you didn’t really need the WYSIWYG editor to publish to the web.
So I built the website for my band, and then for a friend’s band, and then for another friend who was starting a business and needed a web presence—and before I knew it, I had people who were willing to pay me to write code for them. Instead of working at a café, I started to build a small business as an undergrad serving Duke University departments and organizations—and I became a self-taught designer in the process. I was really interested in content management systems and making it so that anyone with an Internet connection could publish stuff on their own to the web. I was getting a lot of feedback from clients about how to make these custom systems really dirt simple to use. That’s how I became a web developer/designer.
What was your initial approach to design while you were at Duke? When you got a new client how would you figure out what they wanted? And how has your approach changed over time?
My design approach has changed quite a lot. Part of that has to do with the nature of the work. Back then a lot of the conversations with clients were centered around what they wanted to communicate. What information would a visitor actually need to get from their website? The design process relied very heavily on their intuition combined with my own to put together a rough architecture for how their web presence was going to be organized and how it would work. We didn’t go through as much iteration, and we didn’t spend as much time and energy driving toward simplest solutions. I would get a lot more feedback from the client than the visitors/customers we were building for, and a lot of those projects were inherently static—they weren’t sophisticated web apps by any stretch of the imagination.
When I joined Facebook, the big change in terms of my design thinking happened across multiple dimensions. One facet was the idea of owning the thing that you built and having greater responsibility over the entire user experience. It was very different from negotiating what the user experience should be from the perspective of a client. Facebook was (and still is) all about giving people the power to share and express themselves. How could we best serve this basic desire? How do we tap into what people found instinctively attractive about our service?
Another key shift in my design thinking was the value of data and learning how engagement data can inform the product decisions that you make. For example, we found people using Facebook in ways we never intended them to, almost like they were contorting the product to their needs. And we would spend a lot of time trying to figure why this emergent behavior would manifest in the first place, and how we could channel that energy more deliberately in the form of new features. There were numerous examples of this over Facebook’s history: people habitually updated their profile pictures on early Facebook, so we launched a photos product to make photo-sharing easier. People tagged their friends in notes to send out messages to groups of people, so we expanded our messaging functionality to support multiple recipients, etc.
As Facebook was expanding, and you were getting more people on your team, were you the one driving the design side? Or was it a bunch of people?
At early Facebook, we tended to organize people into different product areas. A designer would be embedded in a product team. We had this federated approach to design where people owned different facets of the overall product experience. One person would work on internationalization, another on platform, another on News Feed, another on profile, and messages, and search, and so on. With this federated approach, we would have weekly or semi-weekly critiques where the entire design team would get together and review work to maintain consistency across the entire user experience.
That model worked very well for early Facebook and its business and culture. The design process that one develops as an individual or as part of the team is most effective when it directly relates to the broader environment in which it operates, the business model which it serves, and the culture that manifests from that business model and the founders.
In the case of Facebook, how does it create value as a business? It creates value by driving engagement across a set of viral social products. How does it capture value? It translates that engagement into highly structured data that it can then use to target advertisements against people’s attention—then rinse and repeat.
The job of the design team was to ensure that these products were universally intuitive and relevant enough for people to form habits of consumption and engagement. That’s how design reinforced the business and its mission to make the world more open and connected.
What approach do you use at a company like Dropbox? How is their design approach different?
The design approach, again, mapped to how the company creates and captures value. In the case of Dropbox, the primary appeal is that it keeps your stuff safe and makes collaboration easy. Users agree to pay money for Dropbox once it crosses a threshold of value and utility. So we needed to design a user experience that was so reliable, simple, and elegant that people were willing over time to commit their most important files to the product— sometimes choosing it over other competing free alternatives—and then willfully pay us for additional features and services.
We needed to be able to staff a design team that was capable of building very simple and elegant experiences across numerous device types, platforms, and user experiences. It’s a much more difficult product to design for in many ways, because the use cases are so diverse and the stakes are a bit higher from the perspective of the user.
Unlike the Facebook model—where you had individual designers federated across product teams—Dropbox design is organized around teams of designers with highly complementary skills, that represent a diverse set of disciplines—brand, interaction, illustration, research, copywriting. We believe an interdisciplinary approach has served the company very well—it enables us to validate our assumptions quickly and cheaply and with greater empathy for a diverse set of customer personas. Our view is that a highly collaborative approach to making software gives us a proprietary insight on how to build a great collaboration platform. Software has a habit of exemplifying the values of the people who make it.
With all of the different user groups that Dropbox has, what toolbox do you use that helps you create different design iterations? How do you conduct user research?
We conduct regular usability studies with folks with whom we have existing relationships. We leverage our forum website, a community of super users who eagerly give us very helpful product feedback. And we often involve this community and business partners with beta-testing early software builds. We grant these folks premium access to new stuff, because we find that their feedback is reliably salient and actionable.
We have relationships with companies that are passionate Dropbox customers who say, “Hey! Give use the latest greatest newest stuff, because we are all in on Dropbox. And we are excited about giving you feedback on your next generation of products.” So it helps to be able to deploy fresh builds to these companies so that we can get feedback directly from our constituents and maintain a rich dialogue around their wants and needs.
We set up numerous processes around collecting that feedback through all of these different channels and serving the best to the product team. We use design to de-risk early assumptions—we don’t want to spend tons of engineering resources building features people don’t want.
De-risking assumptions takes the form of building high fidelity prototypes that are sometimes indistinguishable from the real thing and running them by users. We also review alpha customers’ usage data to examine retention and engagement to inform our interview questions when we collect qualitative feedback. We can look at which companies are using a given feature versus the ones who are not and dig into why. These qualitative discussions are important so that when we do a bigger push towards a global release,we are not too surprised by how people actually use the product.
What was the most challenging project that you have worked on? How did you work through it?
There was one period during which Facebook put an extraordinary amount of emphasis and time and energy towards giving people greater control of their privacy. We heard people saying, “I feel like Facebook doesn’t respect my privacy! I feel like my privacy is being violated! etc.” So we staffed a team to build out highly sophisticated privacy controls. We told users, “Look here you have incredible control over your privacy settings!”
I personally worked on this. We designed all of this granular functionality, a control for every imaginable privacy setting, and by the time we were done the privacy settings resembled the cockpit of Boeing 747. These were very robust privacy controls. Anything you wanted to do related to privacy—you had total control.
But it turned out that we were just dead wrong about our approach, because—I mean, how many people do you know who can operate a Boeing 747? And so users were just completely overwhelmed. They couldn’t accomplish very basic things. We started conducting usability studies after the fact, trying to have folks do really basic stuff using the controls that we provided to them. Basic stuff like: How do I hide photos from an ex-boyfriend? How can I tell who can see my posts? What does my profile look like to people who are not my friends? People couldn’t even figure out how to turn on the Boeing 747, let alone fly it.
It made me realize that it doesn’t matter how thoughtfully designed your work is—if it’s not well understood and if it doesn’t satisfy people’s expectations and needs, you are not doing your job correctly. It was a difficult experience but an important one I had to go through.