How to implement an Enterprise Design System
You might recall a few days ago, my article on 'Why build an Enterprise Design System?'. Well, now that you've done that (you have done that haven't you? If not, maybe you should read this) it's time to actually knuckle down and implement that Design System across your eagerly expectant design team.
As someone once said, I have a dream.
And that dream is to not actually design anything, ever again.
Radical thoughts, I know folks, but hear me out.
"It's easy to make good decisions when there are no bad options." - Robert Half
If you have a fully implemented Design System, there should be no need for user interface design, as we know it. If I, as UX, say use a checkbox on that screen, then everyone from the UI designer to the front-end developers should know what that checkbox looks like, how the user interacts with it, it's rules regarding placement, label alignment, padding above and below; the list goes on.
There should be no room, or opportunity, for deviation.
The Design System is there to ultimately create order, reduce confusion and develop harmonious designs, whoever creates or builds them. It should clear a visual designer's head as they don't have to 'create' a component, they simply pluck that component off the shelf and then move on to more challenging issues. Likewise, your front-end dev will love you (and possibly want to bear your children) as they don't have to code up and style a relatively common element; they should just be able to employ a snippet from their magic code dungeon (or whatever).
Which then brings me nicely along to tooling.
All of this works beautifully, but only if you're all singing from the same hymn sheet. We've all been there. Oh but our in-house designer uses Powerpoint. We still build our sites in C++ and host on GeoCities.
Honestly.
Now don't get me wrong. You could create your Design System perfectly, ship it out to all your designers and developers as a 72-page PDF and hope for the best, but let's face it, that's not ideal. You'll still be leaving yourself wide open to inaccuracies and misinterpretation creeping in, plus you'll end up with a suite of designs and products created in different design applications that can't always be shared successfully.
You need what I'm going to call, somewhat pretentiously, a front-end software stack.
Now this is where we're going to differ, you and I, so I'm just going to say these are my personal preferences. You might like to use other applications, but this is what has been proven to work for me over the last few years. The underlying principle is exactly the same.
One stack to rule them all.
UI design
Today, it's a stand-off between Adobe XD, InVision and Sketch, give or take a few other contenders. As a frequent business traveller, I'm personally not a fan of having to be online to do my work so my preference is clearly for Sketch or Adobe XD. Whichever you choose, make sure all your UI designers are using the same platform (and plug-ins if you're going to use them) then you can ensure that your Design System can be shared in library format.
Both Sketch and Adobe XD allow you to create cloud library documents that contain reusable colours, character styles, and components (formerly known as symbols), share them across teams for reuse in their own documents, and manage updates from a central system so that everyone uses the latest assets.
(Before you ask; InDesign, Photoshop and Illustrator are not web design packages. Just stop that right now.)
Wireframing
Props to Balsamiq here. For a simple wireframing tool that anyone can use, it's the obvious choice with just enough features to be really useful yet without the steep learning curve of other platforms. If you're a Sketch or Adobe XD fan, then there are third-party wireframe kits out there that allow you to create the same simplistic "wireframe" look and feel you crave, as well as your polished UI work, all in the one software package.
Prototype development
If you're using InVision or Adobe XD, then the prototyping option is a no-brainer as both have their own onboard prototyping options. Sketch also plays nicely with InVision if you grab the rather nifty Craft plug-in which enables seamless uploading (and more besides). Personally I'm a fan of InVision as, despite it's rudimentary options, it's pretty quick to create something passable for the real thing both on desktop and mobile devices. Even with a little knowledge, an impressive mobile app experience can be simulated on a client's handset quite easily.
An honourable mention should go to my old mate Axure RP. It's fallen out of favour recently as you need to build your prototype in the application directly (which can mean doubling the work involved if you're designing your UI in something else), plus it's quite complex to the uninitiated. However, it's ability to write real HTML pages, complete with conditional logic and functional user inputs mean that if you're producing a prototype that needs to be intelligent, such as a form-based service with multiple scenarios, than Axure is my go-to software. Also, like Sketch, you can create component libraries that can be shared across Axure projects.
You might possibly want to look at other alternatives such as Figma (which allows collaboration on the same document) Framer, Flinto (very app focused), Principle, Proto (for animations) and so on for specific use cases. It's very much a case of horses for courses when it comes to prototyping.
Developer hand-off
It's now the moment of truth. You've a wonderfully simple user experience. Your designs are pixel-perfect. Your client has drooled over the slick prototype and signed off on it, in pen. Now comes the point when all of that work is dashed unceremoniously onto the rocks as you pass it all, lock, stock and barrel to the development team.
However, it really doesn't have to be like this. Tools like InVision Inspect, and Zeplin if you're using Sketch, take away all the headache of marking up screen after screen, specifying font sizes, line heights and supplying exported images. Sorry, have you got that icon as an SVG? Noooooooo. Just upload your Sketch or InVision files, grant your developers access, and let them take what they need, when they need it. It's a lazy, err I mean "efficient", designer's dream.
Project management
All of this means nowt, however, if you don't communicate to each other. I've used Slackand Trello quite often over the last few years and it's pretty much all you need for a small to medium-sized design team.
Trello (which can best be described as kindergarten Jira for designers) should be your go-to tool for anything job-related; be it project descriptions, links to Zeplin & Dropbox, InVision prototypes, copy documents, visuals, everything. There should be no excuse for an email asking for the latest version of xyz. No need at all. Ticket all your jobs, put them into projects and swimlanes, allocate your team members, upload your collateral and crack on.
Slack is then your place for general team communications, from individual chit-chat to team and project-related channels. With a bit of fiddling you can even get Slack and Trello to talk to each nicely which increases the visibility of everything at all times.
Your development team will probably want to extend this management capability with something impenetrable to everyone else, like Git, which again, you can integrate into your other comms tools to provide general ticket and status updates.
So there you have it.
How to Implement a Design System (and more besides). I'm not saying it's an easy task by any stretch, but get it right and you'll have the foundations for a better, brighter, more cohesive product design future for your company.