DesignOps meetup hosted by CultureAmp and organised by Adelphi Digital’s Chan Armstrong brought us four entertaining and inspiring speakers. This session brought us four entertaining and inspiring speakers, discussing different design system solutions they used to address their workflow issues.
After attending the latest DesignOps meetup, I come away with this key message — the speed of change is immerse and therefore we shouldn't be afraid to come up with new and innovative ideas that will push the boundaries.
"Sync design and code by making static CSS into living CSS"
"The question isn't who will let me, the question is who will stop me."
"Experiment. Don't ask for permission."
Pain point: aligning design assets to dev code updates
When it comes to fast application builds, react is a major player. When it comes to faster prototyping, sketch is your go to. So, when react has components and properties, and sketch has symbols and overwrites, it only makes sense to combine the two making your static CSS into a living one.
You can then use your react components to build your sketch page, bridging that gap between design and dev. Html-sketchapp is an HTML to sketch export solution. The script produces document.asketch.json and page.asketch.json, this also allows you to version control your design files in a git repo. Why asketch? Because it's not quite sketch it's 'a'lmost sketch.
Pain point: saleforce eDM bugginess
Adam tells us to, “go rogue at work”. Innovation can often be stopped by a lack of buy-in and understanding. Few innovations have permission to go ahead and die at concept stage. Adam's eDM builder started as a pet project over a weekend, and no one really understood what he was trying to achieve. Using the 80/20 rule, Adam built a system that used 20% of the available components but made up 80% of the eDM. This system has taken their eDM build down from 12 hrs to 10 minutes. Adam used twig and inky but since they didn't play well together, he combine the two to create 'twinky'.
Pain point: understanding the impact of change or additional components
Tom and Dan printed out all the components for the website and placed them on the wall. Each component had a symbol to show what stage it was at, design, build, etc.
They found that when you needed to print out the new component, and physically place it on the wall, it prevented the scope from dramatically increasing. People put more thought into whether-or-not that component was really needed. Developers could see when something new was being added. In the end it was all about being on the same page and sharing the same vocabulary.
We work in UX, coming up with ideas on how to make our clients lives easier. Why not find our own pain points and solved them? Ask yourself what is holding back your team and how can you solve that?
As Adam said, "what would this look like if it was easy", then reverse engineer it.
Think MLP - minimum lovable product.