A simple design to dev workflow
I am inspired by what companies like Airbnb and MailChimp are doing to break down barriers between design and software development. But I don’t work for a giant company, so I wanted to see if I could apply these same principles to a lightweight design/dev workflow. Something small enough that it could be set up and maintained by one or two people.
Here’s the general idea: After an ideation and brainstorming process, the design team creates a hi-fi design and passes it to the dev team. The devs create a coded prototype, which is then published to a living style guide. Once the prototype gets the thumbs-up, the styles are published to a software package manager. From here, developers can install the styles into their app with high confidence that it will match the designer’s original intent.
Let’s take a very simple example—a slider widget—and walk through the process. You could use any number of tools to accomplish this flow. Here, we’ll use Sketch, Pattern Lab, Travis CI, and npm.
Ideation
The process starts with designers brainstorming ideas. Since the point at this stage is to get as many ideas as possible out there, they work very quickly with rough pencil & paper sketches.
At the end of this stage, the team takes a look at what they’ve got and chooses a few of the most promising ideas.
High fidelity designs
Designers use Sketch to create hi-fidelity mockups based on the initial concepts.
Again, the team looks these over and picks one to move to the next stage.
Coded prototype
The developers use Pattern Lab to create a coded prototype. Ta-da!
It helps tremendously that the widget is being created in isolation. It’s much easier to focus on getting the details right when all you need to think about is one little component.
When the developer gets to point where they’re ready for a review, they push their code to the remote repository. Travis CI, which is set up to listen for new pushes to this repo, kicks off the build and deploy process. The code is validated, and if it passes the tests, a new version of the UI pattern library is published.
The developer tells everyone to take a look and make sure the coded version matches the design. If things need a little more work, the designer and developer can sit side-by-side and pair up on the revisions. Pattern Lab is set up to use BrowserSync, which allows you to immediately see your changes — very helpful for these types of collaboration sessions.
Pattern Lab makes it easy to see how our new slider looks in various contexts. For instance, we could pop it into a panel with multiple sliders and see if the design still works:
We might see issues with the design that we didn’t see before. Is it confusing to have the label above the slider and the value below? Maybe. We don’t really know. But since the living style guide is a deployed web app, it’s easy to run some tests with real users and find out. We can “debug” the UI at this early stage, figuring out what works and what doesn’t before we get to production code.
Once everything looks good, the developer publishes the styles to npm, again via Travis CI. As before, the code must pass its validation tests in order to be published. This ensures that the code is production-ready from the very beginning.
Use it in a real app
Developers npm install the styles into their app, consuming the styles just as they do any other dependency. Pattern Lab provides a code snippet that shows the markup used to create the component.
The developer simply writes code to generate this markup, a fairly trivial task for most developers. The hard part has already been done. As long as the app generates the specified markup and the styles are imported, the component is (almost totally) guaranteed to look just like it does in the pattern library.
The code
The Pattern Lab starter kit code can be found here. This is based on the original Pattern Lab starter kit, the primary modifications being the addition of automated processes for deploying the style guide, publishing the style package, and hooking into Travis CI.
