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?
Read more – > https://medium.com/startup-lesson-learned/c8f3001f709b
- Welcome to element14 Online Style Guide (uxe14.wordpress.com)
- Ask DN: How Should I make a Style Guide for my App? (news.layervault.com)
- Style Guide (sktorta.wordpress.com)