\/* Button component *\/\r\n.button {\r\n @extend .display-inlineBlock;\r\n @extend .borderWidth-0;\r\n @extend .appearance-none;\r\n @extend .whiteSpace-noWrap;\r\n @extend .verticalAlign-middle;\r\n @extend .outlineStyle-none;\r\n @extend .cursor-pointer;\r\n @extend .userSelect-none;\r\n @extend .textDecoration-none;\r\n @extend .fontWeight-4;\r\n @extend .transitionProperty-all;\r\n @extend .transitionDuration-s;\r\n @extend .transitionTimingFunction-linear;\r\n}<\/code><\/pre>\n<\/aside>\nThis approach provided a number of benefits. It allowed us to keep all the styles consistent across the entire app. It enabled us to get CSS duplication down to zero, since each style is declared once and once only.<\/p>\n
However, just rebuilding the front-end in a more DRY (Don't repeat yourself) way wasn't going to solve all of our problems. The biggest problem with the old method, was that styles were typically encapsulated in page sections rather than reusable components. There were more child selectors than I'm comfortable dealing with and namespace classes were not uncommon. At that point, Marvel was growing pretty quickly and the team was expanding. We had iOS and Android apps to consider. There was also the new Canvas iOS app to contend with. Different teams not only had different design problems, but different programming languages were being used too. The old front-end approach would result in uncontrollable bloat if we didn't find a better solution. We needed to come up with a way to keep our design language consistent across all our different platforms and devices, without duplicating code.<\/p>\n
So, we decided to move our styleguide to its own separate repository. We packaged it up as an NPM module which trickles down to each of our products. Going forward, any future updates to the styleguide will be submitted directly to the styleguide repository, documented, then updated across the Marvel platform.<\/p>\n
<\/p>\n
#3 Improve cross-team communication<\/h3>\n
One of the most interruptive problems I\u2019ve experienced at pretty much every tech company I\u2019ve worked with is poor internal communication, particularly between designers and developers.<\/p>\n
The typical workflow I've observed in a lot of tech companies involves a lot of unnecessary back and forth between teams. So much time is wasted on things like setting animation parameters, arguing over box shadow values, documenting colors and other trivial tasks.<\/p>\n
Now that Marvel utilises a global styleguide, we no longer need to maintain high-quality assets. We no longer need to produce hi-fidelity mocks. A designer can simply whack together a UI using whatever colors, fonts, assets or software they have readily available. Accuracy is not important because the developer will override everything in the mock, choosing the closest match from the styleguide in each case. In some cases, all that\u2019s needed is a spec sheet written in a Google Doc.<\/p>\n
By abstracting away the visual layer, developers can churn out UIs with minimal design input. In some cases, the design team doesn\u2019t even need to be involved. This really starts to blur the line between designers and developers, taking the focus away from visuals and placing it where it belongs, on content, copywriting and user flows.<\/p>\n
<\/p>\n
#4 Encourage change<\/h3>\n
Most good designers I know share a common urge to put things right. This can be frustrating when you join a company that has already established a brand identity. As with most brand identities, there\u2019s usually a lot of room for improvement but you can sometimes feel like you don\u2019t have a voice. Often times, this comes down to inexperienced, over-zealous designers not understanding the full complexity of a product. But it\u2019s not uncommon for companies to inadvertently discourage change.<\/p>\n
I\u2019ve worked on projects where I didn\u2019t feel invested because product ownership was limited to a select few people. I\u2019ve seen good suggestions from new designers get shelved because whoever had been assigned ownership was busy on something else. Tweaking designs is often discouraged because nobody is really sure which areas of the codebase might be accidentally affected by the update. When products are not designed systematically, different segments are often siloed and unconnected -- making them inaccessible to most of the team.<\/p>\n
Having a global styleguide which is\u00a0abstracted away from our\u00a0core product, provides an accessible avenue for anyone at Marvel to voice their opinion. We want to encourage everyone at Marvel to contribute to our product regardless of their skillset. If you\u2019re comfortable with code, you can jump in and make your changes, then submit a pull request and start a discussion (fight). If you don\u2019t work with code, you can open an issue, upload some mocks\/docs, then get a debate going.<\/p>\n
One useful artefact of this approach is that we automatically start compiling a rich history of pull requests, issues, debates, mockups and documents that we can reference later. As teams scale, a lot of time can be wasted as new employees attempt to work on ideas which have already been explored. By encouraging all design work to be submitted through the same avenues, we keep the whole team updated on where the product has been and in which direction it\u2019s headed.<\/p>\n
<\/p>\n
#5 Encourage solid reasoning<\/h3>\n
One of the most attractive aspects of design is the sense of freedom it offers. To a designer, there\u2019s something exciting about a blank canvas -- ultimate creative freedom. But the reality is, when it comes to design systems, creativity and freedom are just not that important. Noodling about in Sketch might appeal to a designer's\u00a0creative needs but it\u2019s not at all conducive to a performant, cohesive web product.<\/p>\n
<\/div>