Forem: Calum Flanagan

Reduce friction and improve productivity by implementing a Design Language System

Calum Flanagan — Wed, 06 Mar 2019 17:13:09 +0000

I wanted to write about an article that I read by Design at Airbnb. It talks about some really important practices and discusses how they moved over to a Design Language System (DLS) - not too dissimilar to our own Style Guide that we used when I was at Zuto. They talk about how it helped them to quickly prototype, speed up their design process and release products much faster. I recommend reading the article before reading this post, just for some context (and because it's a great article).

I wanted to outline some things from the article that will hopefully help those who might not understand why a tech company have such a thing a as a style guide or DLS. I also want to help you understand how we used ours at Zuto, what the value of it is for us as developers and how it can help us to prototype more.

One quote from the article stood out for me:

"The DLS provides us with a shared understanding of our visual style, and streamlines contributions to a single system. This system also enables all of us to prototype and experiment with ideas in high fidelity faster and at a lower cost."
-Airbnb

While we had a Style Guide in place at Zuto and we used the components that it is made up of to produce many of our products; we were still actively trying to improve on the "shared understanding of our visual style" - side of things. The design team were hard at work on figuring out the best way to display and visualise what Zuto is as a brand and discovering the best way to use that brand across the DLS, is what helps us to gain a "shared understanding of our visual style".

Once we have created a DLS with a so called "visual style", prototyping becomes much easier too, because we no longer have to worry about fonts and colours (the finer details), we can focus more on the functionality of products that we want to build/prototype.

"It enables product reviews to focus on the actual concepts and experiences of a design, rather than padding, colors and type choices."
-Airbnb

As I said above, if we already have a DLS in place, prototyping is easy and quick. Using a style guide, we can knock up really quick and simple high fidelity wireframes, using only elements from our Style Guide. We can then use those prototypes to present our ideas to product owners or our peers. Moving on from there, we can start to mock up a more established React prototype and continue designing the prototype in the browser with the help of designers. Then when it comes to actually implementing your prototype, you will have already done a lot of the groundwork, allowing you to focus on the logic.

If you really get this process down, your life as a developer would be much easier. The design team would carry a lot less weight on their shoulders too, because they would no longer have to create fully fledged designs that take a long time to conceive. Also, product owners would benefit from the fact we would be building much more MVPs, rather than all singing all dancing pixel perfect products, because we are releasing value quicker!

I believe that prototyping enables us to design and build better products, and enables us to do both of those things faster and more often. It can help to move your team away from trying to build completely perfect products first time around and instead work on the MVP, test its value and iterate. If we are using elements from our style guide, then there should be no need to make small pixel perfect adjustments.
When talking about the effect the DLS had on their process, Airbnb wrote:

Development is generally faster, since product engineers can focus more on writing the feature logic rather than the view code. Additionally, engineers and designers now share a common language.
-Airbnb

So development was quicker, but not only that, design and engineers are on the same page, which massively boosts productivity and reduces push backs! We certainly felt that after implementing the DLS into our workflow and involving designers in the contribution process to the DLS.

However, all of the above is dependent on your tech department as a whole being committed to maintaining a style guide/DLS and following it's guidelines. Creating and more importantly, maintaining a DLS is the difficult bit. If you are able to get all engineers/designers/product owners, invested in the value that a DLS will bring, then hopefully the passion to maintain it and use it will come naturally.

Playing with Jest

Calum Flanagan — Tue, 26 Feb 2019 17:23:20 +0000

I recently started playing with Jest for a bit of fun and to see how it compared to the stack I usually use to test my React components - Jasmine (with Enzyme) and Karma as a test runner. I've heard a lot of good t h i n g s about Jest and how it basically does all the things that Jasmine does (since it was based on it)… and more now that Facebook have modified it and built on it to expand on what Jasmine does.

Quick and easy

The first and one of the most useful advantages of Jest that I noticed when building an app from scratch, was how quickly I was able to set it up and get on with writing tests. Previously I had to setup Jasmine and then Karma, along with Karma's config file that you have to mess with. With Jest it was much quicker and much easier. Simply npm i jest then add the jest command to your package.json in the npm test script like this:

"scripts": {
  "test": "jest --coverage"
}

and you're done. Running tests is ridiculously fast too, because you're no longer having to spin up a Node.js process that invokes Karma.

You may have noticed the addition of --coverage paired with the jest command in my package.json. This allows you to have complete code coverage, so when you run your tests you should get an output that looks something like this:

Now, you can see at the very bottom that Jest ran a test suite which failed for one reason or another, but above that might be an indicator as to why certain test have failed. In the table above, it details how much of my code has and hasn't been tested. So it's possible that some of that untested code is making my tests fail. It also saves this data as a file you can open in the browser, where you can see exactly which lines of code you've not tested in any of your components. Fantastic! All that value and all you have to do is append --coverage to the jest command.
NOTE: you can also do this with Karma, but I thought it was worth mentioning anyway, while we're already talking about tests!

Familiarity

The second cool thing about it, especially if you're transitioning from Jasmine (with Enzyme) like me, is that you can still write tests in the exact same way as Jasmine and use all of the same utilities with it (from what I've seen so far). This means that your beloved Enzyme "mount" and "shallow" can still be called upon…

Enzyme is still your friend

With Jest, you are still able to use AirBnB's popular React testing utility - Enzyme. Enzyme does lots of cool things, but one cool thing I want to mention is it's ability to allow you to shallow render components in your tests. Shallow rendering a component basically means you are only rendering the component itself, not all of its children. This is particularly useful when it comes to Jest's best feature (in my opinion) - Snapshot testing, which I'll get to soon.
If you're gonna use Enzyme, you might want to setup a jestsetup.js file. Here's what mine looks like:

import Enzyme, { shallow, mount } from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';

Enzyme.configure({ adapter: new Adapter()});

global.shallow = shallow;
global.mount = mount;

This isn't a necessity for using enzyme, but if you want to be able to use the shallow and mount methods in your tests without having to import them every single time, then this is how you share them globally.

In addition to this, in your package.json you will need to tell Jest where this setup file lives, like so:

"jest": {
  "setupFiles": [
    "./tests/unit/jestsetup.js"
  ],
  "snapshotSerializers": [
    "enzyme-to-json/serializer"
  ]
}

Snapshot tests

Snapshot testing in Jest is what makes the switch from Jasmine worthwhile. Along with the fast setup and the fact you can do away with Karma now, writing a snapshot test in Jest is ridiculously easy and just as fast. In short, a snapshot test will basically capture the entire output of a component (hence shallow rendering is useful here), then when the test is ran it will compare what it captured to the actual output. So you are covering every area the code in your components.

Failing snapshots

If a snapshot test fails due to a bug in your code, this will easily be picked up by the test. So we simply fix the issue, re-run the test and check that the snapshot test is passing again. However, you might be thinking what happens if changes are made to the code in a component? Won't the snapshot be out of date? Yes, but Jest has a solution. Sometimes a snapshot test can fail due to an intentional change in your code, because the snapshot for the updated component no longer matches the original snapshot for the test. To resolve this, you simply need to run this command jest --updateSnapshot and the snapshot will be updated.
Of course, this is where you have to be careful not to record a snapshot for a component that still has buggy behaviour. So only update your snapshot when you are happy that there are no more bugs in your code i.e. your unit tests are passing.

Multiple snapshot tests

When playing with Jest I created an app that allows the user to enter a search term into a search box, which in turn hits an API endpoint and returns with some results. I then pass these results through to another component using props and display them there (a search-results component). Therefore, my component would have a couple of different states based on whether or not it is populated with data from the API or not. So in conjunction with this, Jest allows me to have multiple snapshot tests to cater for the different states of the component. An example might be as follows:

it('matches snapshot', () => {
  //Assertions here
});

//Then another test for when the component has props >>>>

it('matches snapshot after receiving props', () => {
  //Assertions here
});

What I plan to look at next

I haven't yet looked far enough into how mocking works in Jest, but if my assumptions are right, I should still be able to mock using a Jasmine spy - since Jest allows you to use other Jasmine conventions.