Doing product design in a huge organization is tricky. Clear, constant communication is imperative.
A few years ago at Salesforce, that mostly meant hours upon hours of creating static redline specs. I didn’t go to school for this stuff, but burning the midnight oil to label CSS attributes across hundreds of screens seemed really, really broken.
Each time a minor change was made to a component in the system, you threw back a shot of whiskey, cursed your existence on the planet, and started the process of combing through every sheet to update outdated elements. Then you’d recreate the PDF and tell everyone that the new one labeled final-final-v2.pdf is the version that they should start using.
There’s definitely a better way. But before we get to that, let me tell you the story of what it took to get there.
Finding the horizon
Our design was approaching seven years old. That’s like 114 in web years. We were in desperate need of a redesign, and everyone knew it.
We actually pushed out a first version of the style guide last year that was specifically for desktop. I was surprised at how quickly it spread internally. We weren’t even close to completing it, but the need was so large that even an inkling of a design system was enough to make a significant impact.
The problem was that the first style guide was built around a concept, not a final product. The concept was off the mark — it was minimal and clean and all that, but it just wasn’t us.
How could we break years of patterns that our customers were now obsessed with, but were also holding us back from evolving?
The answer for us was to start with mobile. The constraints that the phone provided just made solving those problems so much easier. I remember breathing a deep sigh of relief.
We could do this.
Landing on a Design
So we decided to start small by re-imagining what Salesforce would look like as a mobile app.
We developed mood boards, personality concepts, and brand filters. We sat in dark rooms and asked ourselves deep, existentialist questions like, “Is a button really a button?”
We ended up with a handful of key templates and a fairly neutral aesthetic.
In light of the simplicity of the interface, we developed an icon system to imbue some personality into the visual design. The icons are colorful, slightly whimsical, and are also customizable.
Customers can pick a metaphor and a color and the icon is programmatically generated, giving them control over branding the different sections of their Salesforce application.
Then we went deep into the design process, fleshing out all the details and edges of the high-level vision. Many heated conversations later, we started to see some great progress towards getting this thing out the door.
Feeling the Pain
As soon as we finished the majority of the designs and building was well underway, we started getting hammered with emails. Usually these emails contained one or more of a few consistent questions:
“What is the hex value for the blue?”
“Where are the latest icons?”
“What font are we using?”
The really bad part was that answering these questions was beginning to turn into a full-time job. We had to stop designing and switch into maintenance mode. How could we save ourselves from these emails while giving everyone what they needed?
As painful as it may have been to shift gears, we knew what we needed to do.
Retreating to Focus
We pulled away from answering everyone’s questions for a week and escaped to a secret offsite location to kick off the style guide. Fueled and informed by the incessant emails, we were pretty confident that we knew exactly what people needed from this thing.
After taking a few hikes to clear our heads, we started hashing out all of the content. We basically had to disassemble the entire application into its smallest building blocks and identify all the uses and variations for each one.
The kickoff was a big success. Armed with some rudimentary wireframes and gigantic Google documents full of content, we trekked back to the office and started building out each section of the Style Guide.
Documenting the Style
The Style section documents the high-level principles and visual assets behind Salesforce1. We hoped that this section would answer most of the questions we were getting about icons, colors, typography, and the principles used to design the app.
Principles. We wanted the first part of the Style section to set context for the viewer without getting too specific or detailed just yet, so we wrote out helpful tips and techniques around 3 key principles: hierarchy, alignment and simplicity. These principles aim to impart a general understanding of the reasoning behind our design systems.
Colors. Next, we presented a small snapshot of our color palette. We wanted to give enough information so that a designer could easily extend our color system without being overwhelmed by a list of every single color we use in the application. We also included a handy download link to get the swatches on your machine.
Typography. Our current web experience has many different fonts and sizes, so we wanted to keep the new design as constrained as possible. We limited it to only one font, and we chose Proxima Nova Soft to add some personality into the design. We included a small segment to display the font, as well as all of the weights we were using.
Iconography. Lastly, we displayed our icon systems in all of their colorful glory. Now, instead of emailing us, designers can quickly check this section to see the latest icons and download them if need be.
Packaging the Patterns
After fleshing out the Style section, we turned our attention to all of those building blocks we had thrown into Google docs. In order to accommodate designers who preferred to use Photoshop, we assembled a static UI Kit document, but we knew that we wanted to build the patterns out in code.
It needed to be a living style guide.
To do this, we developed a scalable and flexible OOCSS architecture, and made sure that the HTML was well-structured, semantic, and accessible. If you’re interested, the rest of the stack is a blend of Angular, Node and Hogan, which we store on Github and deploy through Heroku. This setup is providing our front-end team an enjoyable and efficient environment, allowing our product work to speed up exponentially.
In order to display the building blocks in a useful way, we ended up with two sections: Components and Examples. The Components section contains a long list of reusable blocks of design and code, while the Examples section shows the viewer exactly how those components can come together to create an application.
The most powerful thing about documenting all of our patterns and building them in code is that now, designers and prototypers on our team can use the components to rapidly create real, interactive deliverables. And they never have to worry about anything being out of date.
It was hard to scope the exercise down to something that was quickly achievable. But it’s been great to see many of our customers already using this for guidance and direction, and the countless questions have started dwindling down to a manageable number.
Now that there is something out in the wild, the team is looking forward to iterating and improving upon it. It’ll be really interesting to add in new sections like voice, illustrations and animations, as well as expand on the functionality of existing sections.
The most exciting part for me, though, is the unforeseen impact on the future of design at Salesforce. I’m hopeful that getting this into people’s hands is going to evolve the way the teams build products.
Clearer communication. Better prototypes. Living specs. More designing in the browser. With those improvements now in place, everyone is looking forward to fixing entirely new problems that help push Salesforce further out toward the cutting edge of product design. Onward and upward.
Special thanks to Paul du Coudray, Chris Auyeung, Sönke Rohde, Mark Geyer, Ryan Spohn and Adam Morse who all made this happen. You can follow their work on Dribbble.
Great job guys. Keep up the awesome :)