creating-an-interactive-report-with-google-data-studio

We recently held our first Data workshop here at the Wiredcraft office, focusing on the basics of Google Data Studio so that attendees could understand its uses, tools, and create their first reporting dashboard.

The class had limited spots so that we could give each attendee the guidance they needed to complete the 5 exercises we assigned them – in case you missed out, here’s a quick summary of the workshop, along with the slides and exercises so you can try it out for yourself.

What is Google Data Studio?

Data Studio is a free reporting and data visualization tool from Google. It works best with data from Google Analytics, but it can be connected up to any data source, including raw CSV or Google Sheets. There are also partner connectors that allow you to use data from sites such as Twitter, Facebook or HubSpot.

It allows you to create a reporting dashboard that pulls from your data source in real-time, and create tables and charts that best fit your needs.

Why should I use it?

The biggest reason is automation. There are often standard reports that are regularly requested by our clients that use the same metrics, but are just for a different time period or user segment. By creating a dashboard, clients can self-serve that data, so that they have easier and quicker access to what they need.

Dashboards are linked to the data in real-time, so can pull whatever date range you need.

The second reason is visualization. Tables of data are fine for analysts who are looking for specific numbers, or are used to working with data in this way, but our brains are more suited to seeing patterns using charts instead. Using a dashboard can help to uncover seasonal or long-term insights that may have been missed.

Data Studio offers a range of chart types to visualize your data:

  • Table
  • Scorecard
  • Time Series
  • Bar
  • Pie
  • Geo Map
  • Line
  • Area
  • Scatter
  • Pivot Table
  • Bullet
  • Treemap
Some of the chart types available in Data Studio.

The third reason is accessibility. Google Analytics, while easier to use than other similar platforms, still has a fairly steep learning curve in learning how data is recorded and where reports are kept. By creating a dashboard, clients do not need to learn how to use the GA admin, instead having all data they need in one single report.

So how do I get started creating my first dashboard?

Luckily, the slides from the workshop can be downloaded here. There are step by step instructions to help you get started:

  • Getting access to the Google Demo account (in case you don’t have an existing data set)
  • Creating a blank dashboard
  • Connecting your data source

From there, we have 5 exercises, building up in difficulty:

  • Creating a scorecard
  • Adding various charts and understanding how metrics and dimensions interact
  • Exploring data with a heat map to spot trends
  • Understanding calculated fields to create your own metrics
  • Custom conversion funnels to see how users drop off at each shopping stage

There are hints given for each exercise, but the last one in particular can be a little tricky! Let me know at [email protected] if you get stuck.

Samantha Cheah


Online Marketing & Analytics


Posted on September 04, 2019
in Data

Stay tuned

Follow our newsletter or our WeChat account; every other week you’ll receive news about what we’re up to, our events and our insights on digital products, omnichannel, cross-border ecommerce or whatever the team fancies.

  • Add us on WeChat

  • Subscribe to our newsletter

creating-a-maintainable-icon-system-with-sass

One of my favorite ways of adding icons to a site is by including them as data URL background images to pseudo-elements (e.g. ::after) in my CSS. This technique offers several advantages:

  • They don’t require any additional HTTP requests other than the CSS file.
  • Using the background-size property, you can set your pseudo-element to any size you need without worrying that they will overflow the boundaries (or get chopped off).
  • They are ignored by screen readers (at least in my tests using VoiceOver on the Mac) so which is good for decorative-only icons.

But there are some drawbacks to this technique as well:

  • When used as a background-image data URL, you lose the ability to change the SVG’s colors using the “fill” or “stroke” CSS properties (same as if you used the filename reference, e.g. url( 'some-icon-file.svg' )). We can use filter() as an alternative, but that might not always be a feasible solution.
  • SVG markup can look big and ugly when used as data URLs, making them difficult to maintain when you need to use the icons in multiple locations and/or have to change them.

We’re going to address both of these drawbacks in this article.

The situation

Let’s build a site that uses a robust iconography system, and let’s say that it has several different button icons which all indicate different actions:

  • A “download” icon for downloadable content
  • An “external link” icon for buttons that take us to another website
  • A “right caret” icon for taking us to the next step in a process

Right off the bat, that gives us three icons. And while that may not seem like much, already I’m getting nervous about how maintainable this is going to be when we scale it out to more icons like social media networks and the like. For the sake of this article, we’re going to stop at these three, but you can imagine how in a sophisticated icon system this could get very unwieldy, very quickly.

It’s time to go to the code. First, we’ll set up a basic button, and then by using a BEM naming convention, we’ll assign the proper icon to its corresponding button. (At this point, it’s fair to warn you that we’ll be writing everything out in Sass, or more specifically, SCSS. And for the sake of argument, assume I’m running Autoprefixer to deal with things like the appearance property.)

.button {
  appearance: none;
  background: #d95a2b;
  border: 0;
  border-radius: 100em;
  color: #fff;
  cursor: pointer;
  display: inline-block;
  font-size: 18px;
  font-weight: 700;
  line-height: 1;
  padding: 1em calc( 1.5em   32px ) 0.9em 1.5em;
  position: relative;
  text-align: center;
  text-transform: uppercase;
  transition: background-color 200ms ease-in-out;

  &:hover,
  &:focus,
  &:active {
    background: #8c3c2a;
  }
}

This gives us a simple, attractive, orange button that turns to a darker orange on the hover, focused, and active states. It even gives us a little room for the icons we want to add, so let’s add them in now using pseudo-elements:

.button {

  /* everything from before, plus... */

  &::after {
    background: center / 24px 24px no-repeat; // Shorthand for: background-position, background-size, background-repeat
    border-radius: 100em;
    bottom: 0;
    content: '';
    position: absolute;
    right: 0;
    top: 0;
    width: 48px;
  }

  &--download {

    &::after {
      background-image: url( 'data:image/svg xml;utf-8,' );
      }
    }

  &--external {

    &::after {
      background-image: url( 'data:image/svg xml;utf-8,' );
    }
  }

  &--caret-right {

    &::after {
      background-image: url( 'data:image/svg xml;utf-8,' );
    }
  }
}

Let’s pause here. While we’re keeping our SCSS as tidy as possible by declaring the properties common to all buttons, and then only specifying the background SVGs on a per-class basis, it’s already starting to look a bit unwieldy. That’s that second downside to SVGs I mentioned before: having to use big, ugly markup in our CSS code.

Also, note how we’re defining our fill and stroke colors inside the SVGs. At some point, browsers decided that the octothorpe (“#”) that we all know and love in our hex colors was a security risk, and declared that they would no longer support data URLs that contained them. This leaves us with three options:

  1. Convert our data URLs from markup (like we have here) to base-64 encoded strings, but that makes them even less maintainable than before by completely obfuscating them; or
  2. Use rgba() or hsla() notation, not always intuitive as many developers have been using hex for years; or
  3. Convert our octothorpes to their URL-encoded equivalents, “#”.

We’re going to go with option number three, and work around that browser limitation. (I will mention here, however, that this technique will work with rgb(), hsla(), or any other valid color format, even CSS named colors. But please don’t use CSS named colors in production code.)

Moving to maps

At this point, we only have three buttons fully declared. But I don’t like them just dumped in the code like this. If we needed to use those same icons elsewhere, we’d have to copy and paste the SVG markup, or else we could assign them to variables (either Sass or CSS custom properties), and reuse them that way. But I’m going to go for what’s behind door number three, and switch to using one of Sass’ greatest features: maps.

If you’re not familiar with Sass maps, they are, in essence, the Sass version of an associative array. Instead of a numerically-indexed array of items, we can assign a name (a key, if you will) so that we can retrieve them by something logical and easily remembered. So let’s build a Sass map of our three icons:

$icons: (
  'download':    '',
  'external':    '',
  'caret-right': '',
);

There are two things to note here: We didn’t include the data:image/svg xml;utf-8, string in any of those icons, only the SVG markup itself. That string is going to be the same every single time we need to use these icons, so why repeat ourselves and run the risk of making a mistake? Let’s instead define it as its own string and prepend it to the icon markup when needed:

$data-svg-prefix: 'data:image/svg xml;utf-8,';

The other thing to note is that we aren’t actually making our SVG any prettier; there’s no way to do that. What we are doing is pulling all that ugliness out of the code we’re working on a day-to-day basis so we don’t have to look at all that visual clutter as much. Heck, we could even put it in its own partial that we only have to touch when we need to add more icons. Out of sight, out of mind!

So now, let’s use our map. Going back to our button code, we can now replace those icon literals with pulling them from the icon map instead:

&--download {

  &::after {
    background-image: url( $data-svg-prefix   map-get( $icons, 'download' ) );
  }
}

&--external {

  &::after {
    background-image: url( $data-svg-prefix   map-get( $icons, 'external' ) );
  }
}

&--next {

  &::after {
    background-image: url( $data-svg-prefix   map-get( $icons, 'caret-right' ) );
  }
}

Already, that’s looking much better. We’ve started abstracting out our icons in a way that keeps our code readable and maintainable. And if that were the only challenge, we’d be done. But in the real-world project that inspired this article, we had another wrinkle: different colors.

Our buttons are a solid color which turn to a darker version of that color on their hover state. But what if we want “ghost” buttons instead, that turn into solid colors on hover? In this case, white icons would be invisible for buttons that appear on white backgrounds (and probably look wrong on non-white backgrounds). What we’re going to need are two variations of each icon: the white one for the hover state, and one that matches button’s border and text color for the non-hover state.

Let’s update our button’s base CSS to turn it in from a solid button to a ghost button that turns solid on hover. And we’ll need to adjust the pseudo-elements for our icons, too, so we can swap them out on hover as well.

.button {
  appearance: none;
  background: none;
  border: 3px solid #d95a2b;
  border-radius: 100em;
  color: #d95a2b;
  cursor: pointer;
  display: inline-block;
  font-size: 18px;
  font-weight: bold;
  line-height: 1;
  padding: 1em calc( 1.5em   32px ) 0.9em 1.5em;
  position: relative;
  text-align: center;
  text-transform: uppercase;
  transition: 200ms ease-in-out;
  transition-property: background-color, color;

  &:hover,
  &:focus,
  &:active {
    background: #d95a2b;
    color: #fff;
  }
}

Now we need to create our different-colored icons. One possible solution is to add the color variations directly to our map… somehow. We can either add new different-colored icons as additional items in our one-dimensional map, or make our map two-dimensional.

One-Dimensional Map:

$icons: (
  'download-white':  '',
  'download-orange': '',
);

Two-Dimensional Map:

$icons: (
  'download': (
    'white':  '',
    'orange': '',
  ),
);

Either way, this is problematic. By just adding one additional color, we’re going to double our maintenance efforts. Need to change the existing download icon with a different one? We need to manually create each color variation to add it to the map. Need a third color? Now you’ve just tripled your maintenance costs. I’m not even going to get into the code to retrieve values from a multi-dimensional Sass map because that’s not going to serve our ultimate goal here. Instead, we’re just going to move on.

Enter string replacement

Aside from maps, the utility of Sass in this article comes from how we can use it to make CSS behave more like a programming language. Sass has built-in functions (like map-get(), which we’ve already seen), and it allows us to write our own.

Sass also has a bunch of string functions built-in, but inexplicably, a string replacement function isn’t one of them. That’s too bad, as its usefulness is obvious. But all is not lost.

Hugo Giradel gave us a Sass version of str-replace() here on CSS-Tricks in 2014. We can use that here to create one version of our icons in our Sass map, using a placeholder for our color values. Let’s add that function to our own code:

@function str-replace( $string, $search, $replace: '' ) {

  $index: str-index( $string, $search );

  @if $index {
    @return str-slice( $string, 1, $index - 1 )   $replace   str-replace( str-slice( $string, $index   str-length( $search ) ), $search, $replace);
  }

  @return $string;
}

Next, we’ll update our original Sass icon map (the one with only the white versions of our icons) to replace the white with a placeholder (%%COLOR%%) that we can swap out with whatever color we call for, on demand.

$icons: (
  'download':    '',
  'external':    '',
  'caret-right': '',
);

But if we were going to try and fetch these icons using just our new str-replace() function and Sass’ built-in map-get() function, we’d end with something big and ugly. I’d rather tie these two together with one more function that makes calling the icon we want in the color we want as simple as one function with two parameters (and because I’m particularly lazy, we’ll even make the color default to white, so we can omit that parameter if that’s the color icon we want).

Because we’re getting an icon, it’s a “getter” function, and so we’ll call it get-icon():

@function get-icon( $icon, $color: #fff ) {

  $icon:        map-get( $icons, $icon );
  $placeholder: '%%COLOR%%';

  $data-uri: str-replace( url( $data-svg-prefix   $icon ), $placeholder, $color );

  @return str-replace( $data-uri, '#', '#' );
}

Remember where we said that browsers won’t render data URLs that have octothorpes in them? Yeah, we’re str-replace()ing that too so we don’t have to remember to pass along “#” in our color hex codes.

Side note: I have a Sass function for abstracting colors too, but since that’s outside the scope of this article, I’ll refer you to my get-color() gist to peruse at your leisure.

The result

Now that we have our get-icon() function, let’s put it to use. Going back to our button code, we can replace our map-get() function with our new icon getter:

&--download {

  &::before {
    background-image: get-icon( 'download', #d95a2b );
  }

  &::after {
    background-image: get-icon( 'download', #fff ); // The ", #fff" isn't strictly necessary, because white is already our default
  }
}

&--external {

  &::before {
    background-image: get-icon( 'external', #d95a2b );
  }

  &::after {
    background-image: get-icon( 'external' );
  }
}

&--next {

  &::before {
    background-image: get-icon( 'arrow-right', #d95a2b );
  }

  &::after {
    background-image: get-icon( 'arrow-right' );
  }
}

So much easier, isn’t it? Now we can call any icon we’ve defined, with any color we need. All with simple, clean, logical code.

  • We only ever have to declare an SVG in one place.
  • We have a function that gets that icon in whatever color we give it.
  • Everything is abstracted out to a logical function that does exactly what it looks like it will do: get X icon in Y color.

Making it fool-proof

The one thing we’re lacking is error-checking. I’m a huge believer in failing silently… or at the very least, failing in a way that is invisible to the user yet clearly tells the developer what is wrong and how to fix it. (For that reason, I should be using unit tests way more than I do, but that’s a topic for another day.)

One way we have already reduced our function’s propensity for errors is by setting a default color (in this case, white). So if the developer using get-icon() forgets to add a color, no worries; the icon will be white, and if that’s not what the developer wanted, it’s obvious and easily fixed.

But wait, what if that second parameter isn’t a color? As if, the developer entered a color incorrectly, so that it was no longer being recognized as a color by the Sass processor?

Fortunately we can check for what type of value the $color variable is:

@function get-icon( $icon, $color: #fff ) {

  @if 'color' != type-of( $color ) {

    @warn 'The requested color - "'   $color   '" - was not recognized as a Sass color value.';
    @return null;
  }

  $icon:        map-get( $icons, $icon );
  $placeholder: '%%COLOR%%';
  $data-uri:    str-replace( url( $data-svg-prefix   $icon ), $placeholder, $color );

  @return str-replace( $data-uri, '#', '#' );
}

Now if we tried to enter a nonsensical color value:

&--download {

  &::before {
    background-image: get-icon( 'download', ce-nest-pas-un-couleur );
  }
}

…we get output explaining our error:

Line 25 CSS: The requested color - "ce-nest-pas-un-couleur" - was not recognized as a Sass color value.

…and the processing stops.

But what if the developer doesn’t declare the icon? Or, more likely, declares an icon that doesn’t exist in the Sass map? Serving a default icon doesn’t really make sense in this scenario, which is why the icon is a mandatory parameter in the first place. But just to make sure we are calling an icon, and it is valid, we’re going to add another check:

@function get-icon( $icon, $color: #fff ) {

  @if 'color' != type-of( $color ) {

    @warn 'The requested color - "'   $color   '" - was not recognized as a Sass color value.';
    @return null;
  }

  @if map-has-key( $icons, $icon ) {

    $icon:        map-get( $icons, $icon );
    $placeholder: '%%COLOR%%';
    $data-uri:    str-replace( url( $data-svg-prefix   $icon ), $placeholder, $color );

    @return str-replace( $data-uri, '#', '#' );
  }

  @warn 'The requested icon - "'   $icon   '" - is not defined in the $icons map.';
  @return null;
}

We’ve wrapped the meat of the function inside an @if statement that checks if the map has the key provided. If so (which is the situation we’re hoping for), the processed data URL is returned. The function stops right then and there — at the @return — which is why we don’t need an @else statement.

But if our icon isn’t found, then null is returned, along with a @warning in the console output identifying the problem request, plus the partial filename and line number. Now we know exactly what’s wrong, and when and what needs fixing.

So if we were to accidentally enter:

&--download {

  &::before {
    background-image: get-icon( 'ce-nest-pas-une-icône', #d95a2b );
  }
}

…we would see the output in our console, where our Sass process was watching and running:

Line 32 CSS: The requested icon - "ce-nest-pas-une-icône" - is not defined in the $icons map.

As for the button itself, the area where the icon would be will be blank. Not as good as having our desired icon there, but soooo much better than a broken image graphic or some such.

Conclusion

After all of that, let’s take a look at our final, processed CSS:

.button {
  -webkit-appearance: none;
      -moz-appearance: none;
          appearance: none;
  background: none;
  border: 3px solid #d95a2b;
  border-radius: 100em;
  color: #d95a2b;
  cursor: pointer;
  display: inline-block;
  font-size: 18px;
  font-weight: 700;
  line-height: 1;
  padding: 1em calc( 1.5em   32px ) 0.9em 1.5em;
  position: relative;
  text-align: center;
  text-transform: uppercase;
  transition: 200ms ease-in-out;
  transition-property: background-color, color;
}
.button:hover, .button:active, .button:focus {
  background: #d95a2b;
  color: #fff;
}
.button::before, .button::after {
  background: center / 24px 24px no-repeat;
  border-radius: 100em;
  bottom: 0;
  content: '';
  position: absolute;
  right: 0;
  top: 0;
  width: 48px;
}
.button::after {
  opacity: 0;
  transition: opacity 200ms ease-in-out;
}
.button:hover::after, .button:focus::after, .button:active::after {
  opacity: 1;
}
.button--download::before {
  background-image: url('data:image/svg xml;utf-8,');
}
.button--download::after {
  background-image: url('data:image/svg xml;utf-8,');
}
.button--external::before {
  background-image: url('data:image/svg xml;utf-8,');
}
.button--external::after {
  background-image: url('data:image/svg xml;utf-8,');
}
.button--next::before {
  background-image: url('data:image/svg xml;utf-8,');
}
.button--next::after {
  background-image: url('data:image/svg xml;utf-8,');
}

Yikes, still ugly, but it’s ugliness that becomes the browser’s problem, not ours.

I’ve put all this together in CodePen for you to fork and experiment. The long goal for this mini-project is to create a PostCSS plugin to do all of this. This would increase the availability of this technique to everyone regardless of whether they were using a CSS preprocessor or not, or which preprocessor they’re using.

“If I have seen further it is by standing on the shoulders of Giants.”

– Isaac Newton, 1675

Of course we can’t talk about Sass and string replacement and (especially) SVGs without gratefully acknowledging the contributions of the others who’ve inspired this technique.

5-secrets-for-creating-successful-mid-level-pages

When information architecture design is done well, your website will have a clean, organized feel that better represents your brand. As a result, your website will be positioned to rank higher on Google, increase traffic and convert more sales.

Designing mid-level feature pages is one of the hardest parts of building or revamping your website. How do you divide your business into neat, tidy sections? How many categories should you use? Does it make sense to combine this feature with that one? How do you find the optimal balance of text, images and graphics? What keywords should you target? Are you building these pages for humans to buy your products or search engine crawlers to rank you higher? 

I could go on, but it’s a safe bet that your head is already spinning. Developing the optimal information architecture design for your business can be a major struggle — but it’s definitely one worth putting the time, energy and resources into getting right.

Here are six tips to design better mid-level feature pages:

1. Organise Your Information Architecture into the Right Categories

Instead of rushing to get a new website up as fast as you can, spend some time thinking deeply about natural categories that align with your products, services, and core values. An hour’s brainstorm and quick sketch will probably not suffice here.

proper due-diligence before building out mid-level pages will save you countless headaches down the road

Discuss with your team. Look at your competitors’ sites. Consult an SEO consulting service. Think about providing your customer with the best possible browsing experience. Consider the most important keywords that you want to rank for. Doing proper due-diligence before building out mid-level pages will save you countless headaches down the road.

When we started building mid-level feature pages for our PDF SaaS app, we thought long and hard about how to organise mid-level feature pages so users could access the information that they were seeking quickly and intuitively. After a ton of research and countless conversations with people who brought different vantage points, we decided on three overarching feature page categories: “Create PDF,” “Edit PDF,” and “Convert PDF.” These broad categories covered the three main services that we provide and allowed the flexibility for us to build out 22 more specialised mid-level pages for specific features like compression, and format conversion.

2. Keep it Simple 

You are passionate about your business and want to share your whole story with prospective clients. It’s natural to try to include everything on your mid-level feature pages, but that is a recipe for clutter and confusion. Design a clean, consistent markup that includes a healthy balance of text, images and infographics. Readers tend to skim (or completely skip) text-heavy sections. Try to use bullets, integrate graphics and err on the side of brevity whenever possible.

Make sure that your layouts are consistent across all mid-level pages. People usually notice different layouts on similar level pages. Whether they note the differences consciously or not, the inconsistencies give off an unprofessional vibe and should be smoothed out before going live. We developed a template that was easy to replicate for each additional mid-level page. Each mid-level page follows the same blueprint which simplifies navigation:

  • a header
  • a drag-and-drop upload button
  • three steps of directions
  • two or three images
  • a brief explanation of the specific feature
  • options to explore other features near the bottom of the page

3. Match Each Mid-Level Page With a Primary Keyword That You’re Targeting

Keyword research is an essential step in constructing effective information architecture. Knowing the most important search terms that you want to rank for will help you develop site structure and content that drives the right traffic to your site and keeps it there. There are lots of good tools out there to research search volume and identify related keywords. We used Google Keyword Planner, SEMRush, CanIRank and a few other keyword research tools to figure out the most valuable keywords we should go after. One of the nice things about these three tools is that they give you search volume reports on related keywords as well. Oftentimes, the keyword you expected to be best actually isn’t, and a similar iteration turns out to be a better fit. 

Most of us seasoned website architects aim to match each mid-level feature page with a high-volume keyword that is valuable to our business. By targeting specific related keywords, you are signalling to Google and other search engines what your website is about, and building topical relevance for your site. As you build out multiple mid-level pages targeting specific keywords related to your business, you will boost both your page relevancy (for each individual page) and overall website relevancy. This will help you improve your SERP rankings for the keywords that matter most to your business and drive traffic into your conversion funnel.

Remember to have only one primary keyword per page. The primary keyword should be featured prominently in your H1 header and also used consistently throughout the page. In addition, you should include several “secondary” keywords that are related to the primary keywords. Using your favorite keyword research tool, identify a primary keyword, several secondary keywords, and other related keywords to build your page around. Be cognizant not to have separate mid-level pages targeting similar keywords. It’s easy to have two pages “cannibalisze” each other — which will drive both pages’ rankings down.

4. Include a Clear, Catchy, Concise Call-to-Action

You’ve designed the perfect information architecture, done your keyword research, matched each page to a high-volume keyword, and written stellar content that includes the right balance of keywords. Finally, it’s time to let out a big sigh of relief, right? Well, not exactly. After doing all this work, it would be a shame not to nail your call-to-action. 

After doing all this work, it would be a shame not to nail your call-to-action

After all, your goal is not merely to get traffic to visit and stay on your mid-level page; it’s to move them further down the conversion funnel and actually buy your product or service! Be strategic with your language and graphics to encourage users to try out your service, sign-up for your newsletter, enter a contest, share on social media or take whatever action you want them to take. We have a big “Click to upload” button at the top of the page for users who just want to take action quickly without reading in more detail about the feature. For more investigative readers, we have other “Upload your file” buttons conveniently positioned in the middle of the page content. Our goal is to make using our software so simple and intuitive that users always can easily navigate their way further down the conversion funnel.

5. Design For Your Audience(s)

So in this long haul of building mid-level pages, are search engines or humans our primary audience? Reasonable minds disagree on this one, but for our purposes today, I recommend targeting both — because you will not be successful targeting one but not the other. 

Think about the key steps in your customer’s journey. She hears about a cool new product that you sell and decides to check it out. She searches for it on Google. If your page isn’t optimized properly to rank highly and catch her eye, it really doesn’t matter how amazing or persuasive your content is. Conversely, if your page is optimized to rank atop page 1 but includes a lacklustre call-to-action, you will have a high bounce rate and fail to convert in ways that bring your business tangible value.

Always keep the big picture in mind and design your mid-level feature pages to meet the needs of search engines and humans.

Featured image via DepositPhotos.

5-steps-to-creating-a-ux-design-portfolio

by

Rachel Krause

on

August 4, 2019

Topics:

Summary: A portfolio highlighting your design process and past work shows others who you are as a designer. The process of creating a UX-design portfolio allows you to reflect on your skills and achievements.


The word “designer” can mean many different things and a designer role comes with many possible skills and responsibilities. UX-design portfolios showcase who their owners are: the areas in which they specialize, their strengths, their processes, and their design styles.

In this article, I refer to a ‘designer’ as anyone who designs one or several components of the user experience — interaction flows, discrete interface elements, visuals, or omnichannel journeys, whether on a desktop, a touchscreen, or on some other device.

Many of our top 10 recommendations for UX-research portfolios also apply to design portfolios. A common misconception about design portfolios is that they are only made up of final UI designs and screenshots. This article will guide you through the steps of creating a UX-design portfolio that encompasses your entire UX process and not just the shiny artifacts.

What Hiring Managers Are Looking For

As part of our current research on user-experience careers, we surveyed 204 UX professionals in charge of hiring about what they look for in a portfolio. Here are some things they mentioned:

  • “Show me how you started with an opportunity and produced real value for a user and the organization.”
  • “I’m curious to know what isn’t in the design and why, just as much as I’d like to know why elements made it in.”
  • “Don’t just show me the finished product. I want to see the messy process and all the work and research that was put in to land on that shiny polished design. Tell me the problem you were trying to solve, your role, any constraints, project timeline, changes from iteration to iteration and how the research informed the design.”

The “users” of your portfolio will be hiring managers, recruiters, or fellow UX professionals, so your portfolio must appeal to these different groups of people. Think about which capabilities you want to showcase and how each group will understand this information. Very rarely will hiring managers take the time to read your entire portfolio word for word — which is one reason why your portfolio should be scannable and not contain unnecessary detail.

Before designing your portfolio, prioritize what you want to communicate. What are the top three things about you and your work that a reader of your portfolio should take away? Revisit this question once your portfolio is completed to make sure you achieved your goal.

Putting It Together

Step 1: Take Inventory of All Your Projects

UX professionals work on many types of projects and tasks. Therefore, it may be difficult to narrow down what to include in a portfolio. The first step is to take inventory of the projects you’ve worked on.

You’ll want to showcase your specialties through multiple types of work. To do this, consider all your projects and ask yourself the following questions:

  • What am I really good at?
  • Which UX activities do I really like to do?
  • What differentiates me from other designers?
  • On which projects did I bring the most value?
  • From which projects did I learn the most?
  • What interesting stories can I tell about the work that I did?

Prioritize projects that align to the work you’re looking for. When seeking a new job, tailor your project selection to the job duties you want to perform. For example, if you really enjoy prototyping, showcase projects where you created prototypes and how they benefited the ultimate outcome. You don’t want to promote work that you don’t like doing, so be sure to avoid adding in projects that don’t align with your future career goals.

Step 2: Choose 3–5 Projects as Detailed Case Studies

Quality over quantity is the best rule to follow when putting together your portfolio. Since hiring managers don’t have a lot of time to dedicate to each candidate’s portfolio, it’s best to choose a few of your best projects to showcase from your prioritized list you made in the previous step. The projects you choose should align to the work that is described in the job description.

The number of projects you include is not important per se. What’s important is that your portfolio showcases a wide variety of work and skills — so, if you had substantial, varied contributions to a small set of big projects, emphasize the many different activities that you were involved in. 

In addition to visuals for each project, create a case study that includes the following information:

  1. The problem(s) you had to solve or the hypothesis you came up with for solving it
    1. Example: Our application got negative reviews because users weren’t receiving alerts about new sales on the site. Based on the content of the reviews, we hypothesized that users were not aware that they could adjust notification settings in the application.
  2. Your specific role in the project and how you collaborated with others
    1. Example: I was the sole UX designer on an Agile team comprised of 3 developers, a product owner, a scrum master, and a quality engineer. I was responsible for determining the overall design direction of the project, while collaborating with the rest of the team on ideation.
  3. How you came to your proposed solution(s)
    1. Example: Usability testing showed that users did not realize that they could adjust their notification settings. We decided to design the notification settings to be more prominent in the site navigation.
  4. How your proposed solution(s) solved the problem
    1. Example: We conducted additional usability testing with the same tasks and our new design, which showed an increase in findability compared to the previous round of testing. Users were able to adjust their notification settings, which gave them access to new sales alerts.
  5. Challenges you faced, including design concepts that were ultimately not pursued
    1. Example: During ideation, we went through several different design concepts that ultimately did not completely satisfy user needs. One design concept that we prototyped displayed the notification settings in a modal when users logged in, but it caused frustration because people had to close it to complete their original task.
  6. How the project affected the users and the business
    1. Example: Because users were now able to turn on new-sales notifications, sales increased by 15%. Our application reviews have skewed positive and customer-satisfaction survey scores have increased.
  7. What you learned
    1. Example: Because of this project, we realized the importance of prototype testing for exploring new design concepts. It made us test new designs to make sure they were viable solutions before putting in development effort.

These case studies should be displayed in a way that is scannable and easy to follow. Include relevant photos and screenshots that tell the story, including early sketches, whiteboards, research documentation, or final images.

Remember, the final screenshots only tell part of the story. Hiring managers want to understand how you work and giving them a glimpse of your process will help them envision how you fit in with their teams.

Step 3: Choose Your Desired Format

Regardless of format, your portfolio should tell a story. Break up text with visuals and make a clear distinction between projects.

There are three common formats for designer portfolios:

Web-Based

A web-based portfolio is a website or online service that displays your work. Web-based portfolios are the most common medium for designers. Resist the urge to go overboard on a flashy template. Your content should be the main focus and your site should be easy to navigate and consume.

Web Portfolio
A typical web-based portfolio has some form of navigation along with a collection of projects. Users are able to click each project individually to learn more about it.

PDF / Slide Deck

Another popular medium for portfolios is a digital PDF or slide deck, which acts as a presentation of your projects. When creating a digital portfolio, keep a master PDF or slide deck with all of your projects included so you can hide projects depending on the job you’re applying for or the skills you want to highlight.

PDF or Slide Deck Portfolio
Keeping a PDF portfolio based on a slide deck allows you to tailor the projects you show to different audiences. Simply hide the projects that are not relevant to the job.

Physical Artifacts

Physical portfolios are more common with print designers, but you can bring physical artifacts that you use during your design process — such as sketches or paper prototypes — into an interview. Couple your physical pieces with either a web-based or PDF portfolio so that hiring managers can see your work prior to an interview.

Physical Artifacts
Physical artifacts allow you to show rough sketches and process diagrams, including design options that didn’t make it to the final product.

When deciding between formats, ask yourself the following questions:

  • Did the hiring manager specify a format?
  • What costs are associated with this format?
  • How much knowledge do I have of the software that I’ll be using?

If the answer still isn’t obvious, below are some pros and cons of the possible formats.

Medium

Pros

Cons

Web-based

Easy for hiring managers and UX professionals to find and view organically

Many options for setup that don’t require coding knowledge

More difficult to tailor your portfolio to different job types

May force you to adapt your info to a predefined template

PDF / slide deck

Allows you to have multiple unique, job-tailored portfolios 

Harder to access (e.g., may have to be explicitly shared with the hiring manager)

Physical artifacts

Can be brought along to interviews to help you talk through your process

Very limited access, hard to share with hiring managers

Step 4: Create Your Portfolio

Now that you have a plan for your projects and format, you can start putting everything together. Regardless of which format you’ve chosen, create a basic template that you’ll follow so that all of your projects look cohesive.

Example templates for the 5 basic components of a UX-design portfolio: title page, project introduction, images with captions, and results
Example templates for the 5 basic components of a UX-design portfolio: title page, project introduction, images with captions, and results

Step 5: Get Feedback and Iterate

Once your portfolio is created, send it to others to provide feedback. Another set of eyes on your portfolio will catch spelling or grammar errors, confusion about content, and the overall usability of your format.

As you interview with hiring managers, make note of what resonates with them and what is unclear. Then iterate on your portfolio.

As you work on new projects going forward, save any artifacts or process documents to use as future case studies in your portfolio. Your portfolio will always be a work in progress and having an efficient method for keeping track of projects will make updates simple.

Navigating Roadblocks

“My work is under a nondisclosure agreement (NDA).”

Nondisclosure agreements are common when doing UX work — and even more so if you’re doing government work. These contracts prohibit you from displaying identifying information about the company, its users, or the project details. Restrictions can be frustrating when you’re crafting your portfolio, but there are ways to show your work without violating the NDA.

Show process images. Rather than showing the polished UI and visual designs that display company-specific information, showcase your process for these projects. Highlight communication skills like workshop facilitation or early design concepts through sketches or black-and-white wireframes.

Workshop whiteboard
Workshop photos give potential employers insight into your design process.

Redact or blur out information. If you have wireframes or prototypes that you’d like to show, blur out identifying information. (Blurring is especially important for applications displaying financial or medical information.)

Redacted information
Redacting personal information like names and contact information protects privacy of individuals while still allowing you to show your designs.

Make it generic. Recreate your designs using different styles. While this approach is time-consuming, it ensures that you are not using brand colors or styles that would identify the client.

Generic design elements
Remove company logos, change branding, and update copy in order to show the layout and design without compromising company information.

“I don’t have a lot of time. What should I focus on?”

If you’re short on time but still want to make a big impact, focus on a project or two where you had to incorporate a wide variety of UX and design skills. These case studies will be in depth and will show off your versatility.

“I had great ideas/designs, but they were never implemented.”

As designers we often generate many candidate solutions for a single problem and ultimately choose only one. In this process, many great ideas are left on the cutting-room floor. As you’re writing your case studies, include candidate solutions and explain the thought process behind the designs. Hiring managers want to know that you’ll be able to navigate challenges and constraints, and you can show them that your work lives in reality instead of an ideal world.

“I’m a student.”

The first job is the hardest to get. It’s difficult to present a compelling design portfolio if all you can show for yourself is student projects. We strongly recommend having an internship in a company, so that you have at least one real-world project to show.

A key aspect of any design is the ability to deal with constraints. Student projects often have made-up constraints — including made-up users and personas — which make them uncompelling proof of your ability to design for the real world. If you’re still working on your student projects, select problems that have business relevance (i.e., will make money) and realistic constraints. If you’re already done, at least acknowledge any unrealistic elements of your student projects in your portfolio description, so that managers don’t conclude that you don’t know any better.

Conclusion

Portfolios will always be a part of a designer’s process. Creating a portfolio that showcases your strengths in a way that appeals to your audience will help you land your next UX-design job. The act of creating a portfolio allows you to identify your skills and achievements while reflecting on the work you want to do in the future.

When creating your UX design portfolio, remember these tips:

  • Curate, curate, curate
  • Show real work, even if it’s messy
  • Highlight collaboration with teams
  • Reflect on who you are as a designer and where you want to be


creating-my-logo-animation

Last week I posted my new logo animation on twitter.

Amongst everyone saying a ton of lovely things, (thankyou) there was a resounding cry of “tutorial”. So I’m going to try and break it down for you. Hope this helps someone, I had a ton of fun making it!

There’s a few things going on in this logo animation. We’ve got –


I won’t dive too much into Greensock for this article. But as Sara Soueidan has said

Greensock is the best thing that happened to SVG animations since SVG animations.

Greensock provides better cross browser support for SVG animation than we get with CSS. It also, crucially, gives you the ability to chain animations and group animations on timelines. This is invaluable for longer and more complex animation.

They also have a bunch of fun plugins, some of which have been made specifically for SVG, like Draw SVG and Morph SVG.

I’ve been side-eying their custom bounce plugin for a while, so when I saw an chance to use it to give the little dot some character I jumped (bounced? ?) at the chance.

Although I love Greensock, you don’t need to learn a whole Javascript animation library to do SVG path animations.

We can do them with CSS too. So I’ll run through a couple of different ways to create the same effect.

Let’s get going. First up…


SVG stroke-dasharray permalink

stroke-dasharray is a SVG presentation attribute (which we can use as a CSS property) to make our SVG paths dashed instead of solid. The higher the number is, the the bigger the gap between dashes.

<path stroke-dasharray="10" ... />
.dashedPath {

stroke-dasharray: 10;

}

You can play around with what these values look like in this pen.

See the Pen SVG stroke dasharray demo by Cassie Evans (@cassie-codes) on CodePen.

As well as making the dashes different lengths with stroke-dasharray, we can also offset the stroke position with stroke-dashoffset. If we change this property it looks like our dashes are moving along the path.

Like so…

See the Pen SVG stroke dashoffset demo by Cassie Evans (@cassie-codes) on CodePen.

If we make the gap between the dashes big enough and then change the offset we can create a path “drawing” effect.

See the Pen SVG stroke dashoffset demo – animating by Cassie Evans (@cassie-codes) on CodePen.

Up until now we’ve been changing the value using a range input, but dashoffset and dasharray are animatable properties, so we can animate them with CSS like so –

See the Pen SVG stroke dashoffset demo – animated with CSS by Cassie Evans (@cassie-codes) on CodePen.

We can also use Greensock’s draw svg plugin to animate the stroke.

See the Pen SVG stroke dashoffset demo – animated with GSAP by Cassie Evans (@cassie-codes) on CodePen.

Under the hood, this is how my logo animation works, but rather than having one continuous line I’ve broken the path up into nine separate sections. This gives me more control over the timing and helps to avoid any clipping overlaps, which we’ll get to in a minute.

See the Pen Cassie! – without clip paths – break down by Cassie Evans (@cassie-codes) on CodePen.

Chaining animations in CSS is a bit of a nightmare as we have to do it with animation-delay. With Greensock, you can line these animations (or tweens) up on a timeline and easily tweak the timings of each tween in relation to the others.

You may have noticed that this version of my logo looks a little… messy though? SVG paths are a consistant width the whole way along. We can change the overall stroke-width and the shape of the stroke-linecap but we can’t do much more than that.

Enter , we can use clip path to “cut out” a more stylised shape.

SVG permalink

SVG clip path can be used to clip (or hide) parts of SVG elements according to a certain path. The parts of the shape inside the are visible, and the parts outside are hidden.

This is a great CSS tricks article if you want to know more.

Lets go back to our little line animation.

In illustrator I drew out the path that we animated (purple), and then I drew a shape over the top (black). This will be used as a clip path.

This is what the syntax for a clip path looks like in SVG

<svg>

<clipPath id="myClipPath">

<circle cx="40" cy="35" r="35" />

clipPath>



<path clip-path="url(#myClipPath)"... />

svg>

Anything you put inside the clip path element will be used as a clipping object. You reference a clip path on the clipping target using an ID

You can also reference a clip path in CSS like this:

.element {

clip-path: url("#myClipPath");

}

This is what the line animation looks like with a clip path applied. Much Nicer!

See the Pen SVG stroke dashoffset demo – clip-path by Cassie Evans (@cassie-codes) on CodePen.

For my logo animation I created a clip path for each stroke.

So the end result looks like this!

See the Pen Cassie! – with clip paths – break down by Cassie Evans (@cassie-codes) on CodePen.


The duotone effect permalink

I’ve created the duotone effect by animating two paths instead of one along each section, one purple and one green.

These paths are grouped together in a element which is the target for the clipping area.

See the Pen SVG stroke dashoffset demo – Stagger – animated with GSAP by Cassie Evans (@cassie-codes) on CodePen.

Squash and stretch. permalink

The final cherry on top is the little dot on the i. ?

In order to make a realistic bounce, the element needs to abide by the squash and stretch animation principle.

This helps make the movement feel more lifelike. The i should squash and stick to the ground at the bottom of the bounce and stretch out at the top. You can definitely achieve this with some really fine tuned keyframes or individual, overlapping tweens. But Greensock make it easier for us with their Custom Bounce plugin.

Using the plugin you set a few parameters and it creates an ease for the bounce and for the squash and stretch.

strength determines how bouncy the ease is and squash determines how long the squash should last.

CustomBounce.create("myBounce", {strength:0.7, squash:3, squashID:"myBounce-squash"});

You can then use that bounce ease the same way you would use a normal ease in a Greensock tween, by referring to it in your tween parameters. The squash ease ID will be whatever the ID of the bounce is plus -squash appended to the end, for example, ease:"myBounce-squash"

tl.to("#ball", duration, {y:550, ease:"myBounce"})

.to("#ball", duration, {scaleY:0.5, scaleX:1.3, ease:"myBounce-squash"}, 0)

See the Pen Video: CustomBounce from GreenSock by Cassie Evans (@cassie-codes) on CodePen.

The final animation permalink

Put all of that together along with a bit of timing finetuning and easing tweaks and we have our final logo animation!

See the Pen Cassie! by Cassie Evans (@cassie-codes) on CodePen.

If you make an SVG path animation I would love to see it! My twitter DM’s are also always open if you get stuck.

Just pop me a message!