Building a Responsive Dashboard Layout with Abstract, Sketch, CSS Grid & React

Part 1 of a 2-Part Design Tech Tutorial

By    Peter Vogt    Experience Designer projekt202

By Peter Vogt
Experience Designer

Designers, I think we’d all agree that continually explaining our design decisions is a necessary, but frustrating, part of our job. Whether we’re onboarding a new designer to the team, or trying to collaborate with product owners or developers, it’s quite time-consuming and nerve-wracking to walk through and remember the entire history of a project with someone. There are lots of tools out there to help us, but it can be hard to find the time to figure out what works and what is smoke and mirrors. 

In an effort to find a more efficient and documented design workflow, I’ve personally spent the last few years testing out various design and documentation tools. Additionally, I’ve spent countless hours trying to figure out a lot of the tools our devs use, too, and I thought it would be nice to share what I’ve learned with you. 

So with that in mind, this is the first part of a two-part tutorial, which is the first entry of a writing series I'm calling Design Tech. The purpose of the series is to take a very focused look at the tools we have to use at our disposal, as well as working in the view layer as designers with both design and code.

For part 1 of this two-part series, we’ll walk through: 

  • Setting up a design project in Abstract and using a separate Abstract project to link up your design system

  • How developers think about grids on the web

  • The fundamentals of CSS Grid Layout

  • Adding a new symbol in your design system with Abstract, to be consumed immediately by your designs

 In part 2, we’ll walk through:

  • Installing NodeJS, npm, and React locally

  • Creating a local React project for prototyping your design with create-react-app

  • Building a navigation component with React

  • Use HTML, CSS Grid Layout, and Flexbox techniques to make the dashboard layout responsive in your browser

Part 1 of this tutorial assumes:

  • Basic HTML and CSS knowledge (you have edited HTML or CSS directly on more than one occasion or have even built your own simple landing page)

  • Intermediate to expert responsive design knowledge (you have designed some or many responsive layouts)

  • Intermediate to Expert Sketch knowledge: We'll use Sketch, but I won't be teaching or even showing much actual Sketch work at all. It's assumed that you work with Sketch, most likely for your daily work.

  • Minor knowledge of Abstract

  • No knowledge of CSS Grid Layout

The overarching goal in this two-part tutorial is to leverage modern technologies for a more efficient and documented design workflow, as well as one that keeps you mindful of the view layer in the browser (your canvas to paint on). By learning Abstract, the decisions in your design process become self-evident to anyone who pulls up the project in the future. The entire tangible working history of your project becomes one big artifact to be consumed by future designers forever. And by learning some CSS Grid & React, you are bringing your knowledge as a designer closer to the toolbox your developers have at their disposal.

Important note on my last sentence just now: There is a real difference between being a designer who can get hands-on with the tools developers build with, and being a designer who feels like the market is forcing them to become a UI developer. I believe that nobody can define your skillset or career better than you can. I encourage everyone in design to learn as much as they can or want to in technology, research, analytics, or whatever helps them best. I have precisely zero interest in re-hashing the wheel-spinning, ages-old "Should Designers Code?" debate. The methods displayed below are only one approach to software design craft, not the only one. 

With that existential crisis out of the way, let's dive in.

Section 1: Abstract — Design Project Setup & Management

Setting Up Abstract: Projects & Linked Libraries

You'll want to download Abstract if you haven't already. They have a free one-month trial. You can access projects from the browser for collaboration and sharing, but you will want to download the Abstract MacOS app for optimal use with Sketch. Once you're up and running, File > New Project or CMD+SHIFT+P will bring up the new project window.


I'm going to name this project designtech-library and add a description. This project will hold and maintain our linked library for the tutorial's design project, which will feed our design project with its styles and symbols. I like to color-code library projects and design projects differently, so you can tell what is what at a glance. I'll choose pink for the library project and orange for the design project.

Creating and Adding a Linked Library 

Next, we'll open our designtech-library project in Abstract and click the "Add File" dropdown in the top right corner of the UI. Select "Create Sketch File as Library." This will automatically generate a Sketch file pre-designated as a linked library for you. I gave mine the name of designtech-library-web, simply in case we ever need to add a separate library for future iOS or Android work that require their own files.

Congrats - you've now laid the groundwork for a siloed design system for your current workstream. There's nothing in the Sketch file yet, but soon you will fill it with symbols and patterns that will act as the source of truth for your design system. Note that the purple Sketch icon on your Master Sketch library file is telling you that this file is an Abstract library file, and not just an ordinary Sketch file. 

Here's the beauty of this: so long as you're linking this library to all of your projects related to this workstream ("designtech," in this case), you will never have to worry about grooming or maintaining symbols in your production design files again. What's more, you can say goodbye to cluttered symbols pages with a sea of duplicate garbage that has been copy pasted in over the course of weeks or months. I will illustrate the true power of Abstract linked libraries here shortly.

Exit back to your home dashboard in Abstract by clicking the home icon in the top left of the UI. File > New Project or CMD+SHIFT+P again to make another new project. Give it a name that reflects the project you're working on, keeping in mind that it will be intimately attached to the design system linked library we created a second ago. My project will be called designtech, and I'll give it a description and a color of orange to designate that it is a design Abstract project and not a linked library design system Abstract project.


Great. Now we have two Abstract projects: one where we'll be doing all of our design work, and one that will house our design system or pattern library.

Getting Started with Your Linked Library

Let's open our designtech-library project.

Not a lot to see. You'll notice, in the "Recent Activity" pane, Abstract is already making mention of when you created the project and added a Sketch file. This is the very beginning of your journey in version control. Now I, the stakeholder, developer, or fellow designer, can see when you created this project if I ever happen to open it up. But that's just the beginning. 

Let's hit that big blue "NEW BRANCH" button. We want to add some colors to be used as foundational symbols for our design work. Write a branch name that reflects that purpose, while being mindful of the 35-character limit for branch names. 

Try and simply keep the branch name close to the essence of what you're working on for now. There are many different approaches to naming branches and I explored some of them in my other article on Branching Models for Abstract. For the sake of learning, just name the branch after whatever you plan on biting off for work at the moment. I'm adding my first color symbols ever to the project, so I'll name the branch "first color symbols."

Pop some champagne, because you've just created your first-ever branch in Abstract. 

OK, But What is a Branch? 

I'm happy you've asked! Let's hit rewind and touch on the key element of version control, which is what you are leveraging here. When you create a new branch, you are creating a copy of your "Master" Sketch file for the project, which in this case is the library Sketch file we created earlier. The purpose of doing so is to allow you to create work in safe, siloed versions of your Master file. In doing so, you are able to add, combine, or destroy parts of your overall Master Sketch file in a way that gives you full power over everything. I compare it to being able to remove or add pieces to a Jenga puzzle without ever worrying about destroying it.

Here's a relevant example. We're using this new branch to add colors to our Master Sketch library file. Our design system needs colors, right? So, when we create a new branch, we're creating a duplicate of our Master Sketch library file, add colors, and then merge that branch (or copy) back to our Master Sketch file. If you ever need to change one of your global colors in your project, you can create another new branch and do so. But because we used version control the whole time, we can always open up Abstract, go back to our very first branch, "first color symbols", open it up, and get an in-depth look at the work we did back then. This is merely the tip of the iceberg for the value that version control brings.

Library project with a linked library set up.

With our "first color symbols" branch pulled up in Abstract, we see that our purple icon Master Sketch library file is there. Perfect. Click the "EDIT IN SKETCH" button to begin work on adding colors. 

Fair warning: This is going to be uncomfortable at first, but if you want to use Abstract for versioning your design work, you have to embrace opening your Sketch files exclusively through Abstract. Gone are the days of hunting and pecking in a bunch of local or cloud directories for your Sketch files and opening them there. Keep your design files in Abstract, complete new design work in a project by creating and merging branches, and maintain your design system/symbols in your linked library projects. You will get used to it eventually - and it's worth it!

Establishing a Global Color Palette for the Library 

Now that we have Sketch open, let's fire up an artboard and draw some swatches. Then we'll make some symbols out of 'em.

I've drawn 64x64 color swatches for both fill and stroke symbols here. I've renamed the layers to reflect how I want my symbol library hierarchy to be named. Let's go ahead and commit our changes to Abstract for this branch, using the Commit Changes button at the bottom of our Sketch window.

Your commit “staging area.” Abstract will save your work in Sketch here, and “committing” will earmark this work to be saved for later.

You can see that we renamed our default page to "Colors" and added those swatches. Abstract forces you to type a commit message before you can push changes to your branch, to encourage you to keep track of what you're doing visually. We'll call this commit "draws color swatches," because that's what the commit does. 

No harm, no foul here; you have committed your swatches but nothing is permanent until you merge to Master. Let's go ahead and turn these swatches to symbols to be nested and reused later. 

Keeping Your Library Clean

Alright, now that our swatches are symbols, let's clean up the Sketch file. After all, this is a library - we don't want anything but the bare necessary documentation, and all of our components / symbols. I'll delete our "Colors" page and all of its contents, leaving only the symbols page with our swatches. 

I'm going to use a plugin called Artboard Tricks to arrange the symbols for swatches into a nice grid.

Sketch Runner and Artboard Tricks plugins in action.

Sketch Runner and Artboard Tricks plugins in action.

Your symbols page, with swatches now organized.

So, we now have colors we can use as part of this library. Any project that uses this library as a linked library will have access to them once we merge these changes into our Master Sketch library file. Let's do so now. 

Commit the changes we've made, and write a commit message, something like "creates swatch symbols, cleans up Sketch file." 

Now it's time to tell Abstract we want to update our Master Sketch file with these changes. Let's go ahead and hit the big blue "MERGE BRANCH" button on our "first color symbols" branch. 

Confirm and Document Your Merge 

Here's your opportunity to tell your stakeholders, teammates, or simply just Future You™ what you were doing when you made this branch and merged it. I'll keep it simple for this merge, but don't be afraid to go semi-buckwild to buckwild on your merge documentation. We as creators owe it to the fellow designers or stakeholders we work with to justify and explain our process and thinking. The more you document, the more you maintain the long-term creative integrity and process of your project.

Add a merge message before you push all the color swatch work up. This documents the context of the work for future collaborators.

You've left your proverbial "mark" on this branch. Hit "merge and archive.”

Your commit history, now with a merge of all your color work that just happened.

Poof – now your Master Sketch library file has color swatches in it. When looking at Master in our Abstract library project now, you see the commits that were made, and the merge that was made. Pretty cool, huh? 

Earlier, I mentioned the true magic of Abstract linked libraries. Hop in the DeLorean and fire it up to 1.21 gigawatts, because I'm going to show it to you now. Where we're going, we don't a symbols page. 

No Symbols Page in My Design Files?


Let's back out of the designtech-library Abstract project and open the designtech Abstract project.

We have no Master Sketch file here, so we'll have to create one. This will be where the comps live for the layout we're building. You can think of this as where your main project for an app would live, and it will be fed by the Abstract linked library in our library project.

Just like we did in the library project, hit the "Add File" dropdown, but this time click "Create Sketch File" rather than "Create Sketch File as Library." Call it designtech-web-master (or yourprojectname-web-master). We are saying: this is where our designtech web app comps live, this is the Master Sketch file for the designtech web app.

Before we do any comps, let's link our library from the library project. Click "Add File" again, and click "Link Library."


In the pop-up, click our designtech-library project, then click the Master Sketch library file. Click the "Link Library" button. Boom.  

You now have your library “linked” to your design project.

It's Not Delivery Magic, It's Abstract-o

I'm going to now create a new branch in designtech Master named "setup." Normally, you would want to keep your branches small and specific. But in the case of this tutorial, I'll only have three artboards I plan on using, so I'm just going to keep this branch very broad. 

On the "setup" branch, I'm going to hit the "Edit in Sketch" button to open this branch up in Sketch, just like we did before. I'll generate an artboard on Page 1, and - what's that?

When inserting a symbol, you see there is everything in our linked library - albeit just some color swatches, for the moment. When changes get merged to master on our Master Sketch library file, they'll propagate through to whatever design files are using that library as a linked library in Abstract (say “library” one more time). 

I want to really dial the importance of this in: when you maintain a linked library separately from your design files, you are effectively decluttering your design file. There is simply no need to keep a symbols page in your ongoing design work, because your Sketch symbols are being held and maintained in a completely separate project. 

Have you ever shared the same Sketch file across Dropbox with three designers as part of a two-day iterative prototyping session with 10 users? Ever had that Sketch file's symbol page quickly turn into a Kafkaesque wasteland of deprecated nested symbols from your design system, or 100+ instances of the same gray swatch? All under the sweat of a deadline with users to test with, and client budgets in the mix? 

I have. It isn't fun. I won't sit here and pretend I am the most diligent symbol page maintainer in the world - far from it. In fact, I'd argue I'm one of the worst offenders I know in that regard. But, using one Abstract project for your design system library, linked to all of your other design work, solves most or all of this problem. 

I'm going to discard these changes on the "setup" branch (but keep the branch) since they were just for demo purposes on the above video, and move on. 

Building Layouts Using a Linked Library 

We're going to hop in the DeLorean again and fast-forward to a time in which this linked library for designtech now is built out with a vastly larger array of components and styles. The purpose of this part of the tutorial is to show how to build with Abstract, and not necessarily the construction of a design system. 

With a linked library full of components and a project scope in mind, we're ready to put some comps together for our dashboard layout. 

But, before we do that, I'd like to slam the brakes and pivot to talk about CSS Grid, since we'll be using it to set up our comps and, later on, prototype our layout in code. 

Section 2: CSS Grid Layout — The Basics

Expectation vs Reality: How You Design Your Grids in Sketch vs. How a Developer Implements Them

For many teams, there is a fundamental disconnect in how designers specify grids vs. how developers implement them. Why specify widths in hard pixel values across 3-4 breakpoints when a developer will simply use bootstrap or some other column-based grid system that is mostly an approximation of your designs? Is it really worth it to measure container widths out to 264px on mobile, 400px tablet, etc for every set of comps you make? Why worry about course-correcting accidental subpixel values in redlines if you don't have to? Is it efficient to describe layouts as "6 columns nested inside 12 on small screens, 12 columns on tablet, 10 columns on large"? Do we even want to be limited to 12 columns if we don't have to be? 

CSS Grid Layout and Flexbox are two native browser capabilities that are being adapted widely to build responsive layouts by developers. Developers like them, for one reason, because they already work in almost every browser. There's no need to install any external dependency and no need to build a custom grid system from scratch. CSS Grid Layout gives developers a way to build your responsive design work out in a more semantic and flexible way. From a designer's perspective, CSS Grid Layout opens up a Pandora's box of possibilities for you creatively. The browser becomes a lot like a canvas to paint on again, rather than a system churning out the same three-column responsive layout. As an example, I really love this article from Smashing Mag on art directing with CSS Grid.

Web layouts like this are now much simpler to build responsively with no hacks required by your developers. Credit:    Smashing Magazine

Web layouts like this are now much simpler to build responsively with no hacks required by your developers. Credit: Smashing Magazine

And that's maybe the biggest point of these designtech tutorials. The truth is, there is a lot that happens after designer to developer handoff to make interfaces happen. Your developer not just has to understand the design intent, but how the browser will interpret it. 

As a designer, if you understand some of these rules, you can make life easier for both you and your development team. You'll save time, be able to discuss handoff more precisely with developers, and contribute to greater overall efficiency in your company's development lifecycle. 

In the end, it's going to come down to what works for your team - it's important to call out, for example, that CSS Grid Layout doesn't have full support for Internet Explorer. That could be a barrier to entry for your team. In my experience, however, knowing the high-level details on the options your development team could use is only a skill that makes you more well-rounded as a designer.

So for our tutorial project, we'll take a high-level look at CSS Grid. In part 2, we'll apply those concepts to a dashboard design we have in Sketch and Abstract. 

CSS Grid Layout Concepts

Display: Grid, Columns, Rows

OK, admittedly, there's a lot of verbiage to learn at first for CSS Grid layout. Fortunately, I believe these terms are usually pretty self-evident. Most of the concepts of the grid are common sense terms like "rows" and "columns", it's simply a matter of understanding the context.

If you are a designer, CSS Grid  - conceptually - will be very easy for you. It's simply a matter of using the right terms at the right time to accomplish the layout *you* want to build.

When we talk about "using CSS Grid," we are talking about setting an HTML object or layout to have the class of display: grid. So, let's simplify, and say your project breaks down like this under the hood:

<div class="container">
<div class="header"></div>
<div class="sub-nav""></div>
<div class="main"></div>

If we want to tell the browser to use CSS Grid layout, we open our .CSS file and write:

.container {
display: grid;

Now the browser knows that it has to listen to you tell it about CSS Grid. It knows all the lingo and verbiage to apply CSS Grid already, but now we've  made it official in our CSS file.

Once we have a grid set up, we can start to add rows and columns, and then give those areas designation for components or content areas. You can see the end result of this process in a diagram like this:


We have an overarching div container that has display: grid applied, a header nav row that spans all five grid columns and one grid row, a subnav column that spans one grid column and four grid rows, and the main content container which takes up all of the rest of the space. 

CSS Grid Rows & Columns 

You can write CSS to accomplish the above image's layout by using grid-template-rows and grid-template-columns.


We start with our div class "container," and we give it the CSS property of display with a value of grid. We are telling the browser that with this container, we will use CSS Grid Layout.

Next, let's set our grid's columns. The most basic way to do this is to give our container the property grid-template-columns, and set the columns width values explicitly. Since we want five columns, we'll give it the value of "20% 20% 20% 20% 20%."

You can give grid-template-columns percentage values, pixel values, ems/rems, and more. 

.container {
Display: grid;
Grid-template-columns: repeat(5, 20%);

To create the rows for our grid, you guessed it - there's a property called grid-template-rows, and you can define its value explicitly just like we did for the columns.

Helpful hint: If you want to shorthand your grid-template-columns or grid-template-rows values, you can optionally give the value repeat(number of rows, size). If it helps you to visualize by seeing the amount of columns or rows typed out, use the notation I have in the examples below.

We now have a 5x5 20% column and row grid layout using CSS Grid. We've set them explicitly using 20% for all of our grid items. This is fine, but not really ideal because the second you start adding more columns or rows that math starts breaking. So let's talk about the fractional unit, which is a big part of CSS Grid's handiness. 

Lines, Items, Tracks, Areas: Anatomy of a Grid


Now that we have our rows and columns, let's explain the anatomy of CSS Grid Layout a little further. 

●         Lines

Lines are simply the name for the demarcation between columns and rows. They do not take up any space in your layout, and are merely used to distinguish one row or column from another. Grid lines get assigned numbers automatically. In the above case, we'd have grid lines 1 2 3 4 5 and 6 for both rows and columns. This is important to know, because it will directly play into how you define the sizes of your grid items.

●         Items

A grid item is any piece of content in your grid. One way to think of it: any child of your grid container is a grid item. A nav bar, sub nav, or body area inside a container with display: grid is a grid item.

●         Tracks

A track is used to describe an area of space in a column or row. Almost like a gradient tool in Sketch or Photoshop, you assign "start" and "stop" values to a grid item to tell the browser how wide or tall an item should be.

●         Areas

You can define a grid area as any rectangular content area in your grid. It can be one cell in a column, one cell in a row, or four cells in a column and four cells in a row. You can then give these grid areas names, of whatever you'd like (e.g., "footer" or "magicalnavbar"). This is incredibly important to earmark for later, when we start building our responsive dashboard layout.

The Fractional Unit (fr)

Let's talk about widths and heights in the grid some more. Earlier, we set up our grid by divvying up the space amongst five 20% columns and five 20% rows. We also know that this doesn't scale long-term, because if you add or take away a column or row, our math falls apart.

The fr unit mitigates this problem by letting you define space in the grid as distributed leftover space or, in more common terms, "whatever space is left over." If you set up your grid-template-columns with the value of "20% 1fr," you now have two columns. You could also use a pixel value if you wanted, like 72px.


Back to Design 

I think we've touched on enough of the basic bits of CSS Grid for now. Let's go back to Abstract and continue designing our layout, and we'll get further into the CSS Grid Layout weeds when we pick up coding again. Simply keep this stuff in the back of your mind for now. 

Section 3: Putting Together Layouts in Sketch Using Abstract Linked Libraries 

Adding a New Symbol to Our Design System 

Let's go back to the setup branch in Abstract in our designtech project. 

We have some desktop and tablet mockups set on our dashboard. These were constructed using symbols from our linked library. I have design system components pulled in for the navigation, tables, etc. They have constraints built in, so resizing to fit our scoped breakpoints is no problem.

But there's an issue. Our design system doesn't have a mobile navigation instance yet. So, we'll create one as part of our dashboard design work and push it back up to the master library in Abstract. This way, we can use that mobile nav symbol now, but, it can also be consumed for any future work that requires it. 

Let's close our Sketch file, commit our changes to Abstract, and move to our library project.

We'll create a new branch called "mobile navigation" in our library and edit it in Sketch. 

Next, we'll draw a background for our mobile nav, assign a layer style to it from our design system, and give it a menu icon. We'll also set a text style layer for the nav's wayfinding text.

We'll then set this mobile nav as a symbol and commit our changes to Abstract.

Now that we've committed those changes, let's hit "merge to master" in Abstract and push our new mobile nav to our design system.  

Alright, let's get out of the library project, go back to our dashboard design project and pull in the mobile nav for our mobile layout.

And there you have it. We created a new branch in our library project to make a mobile nav symbol, merged it to our Library Master, and then it appeared, ready to go in our design project.

You can see how truly powerful linked libraries can be on a multi-designer team, or if you have one designer who maintains a design system full-time to support other designers. 


I'm going to wave the magic design wand and put the final touches on our mobile layout in Sketch:

So we now have a layout prepared. In practicality, I am certain there would be 10 times as much documentation and component states, etc., but for the purposes of this tutorial, we're going to keep the design details at a high level. 

We'll merge our "setup" into our design project for designtech's master, with a comment to the tune of "sets up mobile layout." Normally, you would want to branch a lot smaller than one big "setup" branch - e.g., a branch for desktop, a branch for tablet, a branch for mobile. But with the scope of this tutorial, since we're just setting up a design with a couple of layouts, one branch called "setup" will do. 

We now have our dashboard design set. In part 2, we'll use React and CSS Grid to prototype it in the browser.

Published Oct. 16, 2018


projekt202 is the leader in experience-driven software strategy, design and development. We have a unique and established methodology for understanding people in context — we reveal unmet needs — which drives everything we do. This leads to a crisp, clear understanding of the customer, which shapes the design and development of new solutions and experiences. We have the expertise, teams, skills and scale to deliver sophisticated software solutions that improve any and all touchpoints across the user journey.

projekt202 has spent over 15 years bringing to life and to market compelling experiences through our Experience Strategy & InsightUser ExperienceSoftware DevelopmentMarketing & Analytics, and Program Management practices. Our talented team has delivered emotionally-rich and intuitive solutions for global brands and clients such as 7-Eleven, Allstate, Canon, Capital One, Dell, McKesson, Mercedes-Benz Financial Services, Neiman Marcus, Samsung Electronics, Subway and The Container Store, among many others.

projekt202 has offices in AustinChicagoDallas and Seattle.