You are here

thinktime

Practical SVG

a list apart - Wed 10th Aug 2016 00:08

A note from the editors: We’re pleased to share an excerpt from Chapter 6 of Chris Coyiers’s new book, Practical SVG, available now from A Book Apart.

You’ll probably want to exert some sizing control over any graphic you put on a website. Hey! You! Logo! You should be this size:

<img src="logo.png" class="logo" /> .logo { width: 220px; height: 80px; }

And so shall it be.

But if the element you are resizing happens to be svg, the result might not be exactly what you expect. Sizing svg is a little more complicated than sizing an img. I’m not saying this to scare you. It’s almost complicated in a good way, because it gives you more control and opens up some interesting possibilities.

Keep these two concepts in mind when you’re working with the size of SVG images:

  • The viewport is simply the height and width of the element: the visible area of the SVG image. It’s often set as width and height attributes right on the SVG itself, or through CSS.
  • The viewBox is an attribute of svg that determines the coordinate system and aspect ratio. The four values are x, y, width, and height.

Say we’re working with some SVG like this:

<svg width="100" height="100" viewBox="0 0 100 100"> <!-- alternatively: viewBox="0, 0 100, 100" -->

In this case, the viewport and viewBox are in perfect harmony (Fig 6.1). The SVG will be drawn in the exact area it visually occupies.

See the Pen adqEmQ by Chris Coyier (@chriscoyier) on CodePen.

Fig 6.1: Viewport and viewBox in perfect harmony. This happens when you apply no width or height to the svg (either via attribute or CSS), or if you do, they match the aspect ratio of the viewBox.

Now say we double the width and height, like this:

<svg width="200" height="200" viewBox="0 0 100 100">

Will the svg just draw in a 100 by 100 space in the upper left side of the 200 by 200 element? Nope. Everything inside the svg will scale up perfectly to be drawn in the new, larger space (Fig 6.2).

See the Pen VeQyQY by Chris Coyier (@chriscoyier) on CodePen.

Fig 6.2: With the viewport enlarged and viewBox kept the same, the graphic scales up to fit the viewport.

The square aspect ratio still matches perfectly. That’s why it’s not particularly useful to think of the numbers anywhere in SVG as pixels, because they aren’t pixels; they’re just numbers on an arbitrary coordinate system.

What if the aspect ratios don’t match, though?

<svg width="300" height="75" viewBox="0 0 100 100">

What happens now, by default, is that the SVG will draw itself as large as it can, centered along the longest dimension (Fig 6.3).

See the Pen vLdpdN by Chris Coyier (@chriscoyier) on CodePen.

Fig 6.3: The viewport is enlarged, but no longer matches the aspect ratio of the viewBox. So by default, the image is drawn as large as possible without being cut off, and centered on the long dimension.

If you want to regain some control over this behavior, there’s an attribute for the svg element that can help!

preserveAspectRatio

It looks like this:

<svg preserveAspectRatio="xMaxYMax">

The x and Y parts of that value are followed by Min, Mid, or Max. The reason SVG normally centers in the viewport is because it has a default value of xMidYMid. If you change that to xMaxYMax, it tells the SVG: Make sure you go horizontally as far to the right as you can, and vertically as far to the bottom as you can. Then be as big as you can be without cutting off.

The “without cutting off” part is another aspect of preserveAspectRatio. The default value is xMidYMid meet—note the “meet.” You can replace meet with slice to say instead: Fill the area entirely; cutting off is okay.

There are nine possible alignment values combined with meet (Fig 6.4).

Fig 6.4: Examples of preserveAspectRatio values with meet.

There are also nine possible alignment values combined with slice (Fig 6.5).

Fig 6.5: Examples of preserveAspectRatio values with slice.

I made a testing tool for playing with this idea. Sara Soueidan also wrote an in-depth article on this subject, where she makes an excellent observation relating this idea to CSS. The background-size property has two keywords it can take: contain and cover. The contain value means “make sure this entire image is viewable, even if you have to shrink it,” which makes it just like meet. The cover value means “make sure this covers the entire area, even if you have to cut parts off,” which makes it just like slice.

Even the alignment part of the value has a matching CSS counterpart: background-position. The default background-position is 0 0, meaning “top left.” That’s just like xMinYMin. If you were to change that to, say, 50% 100%, that would be like xMidYMax!

Fig 6.6 has some examples to make that connection a little clearer.

preserveAspectRatio values and CSS properties preserveAspectRatio= "xMinYmax meet" background-position: 0 100%; background-size: contain; preserveAspectRatio= "xMidYMid meet" background-position: 50% 50%; background-size: contain; preserveAspectRatio= "xMinYmax slice" background-position: 100% 0; background-size: cover; preserveAspectRatio= "xMidYMid slice" background-position: 50% 100%; background-size: cover;

Fig 6.6: preserveAspectRatio values and the CSS properties they are similar to.

Remember: these aren’t interchangeable bits of code; they are just conceptually related.

What if you want to throw aspect ratio out the window and have SVG scale to the viewport, like a raster image would? Turn preserveAspectRatio off (Fig 6.7)!

<svg preserveAspectRatio="none" viewBox="0 0 100 100">

See the Pen yevpvj by Chris Coyier (@chriscoyier) on CodePen.

Fig 6.7: Example of preserveAspectRatio="none". Poor little buggers.

Amelia Bellamy-Royds wrote a comprehensive article on scaling SVG, in which she covers things like the fact that svg can essentially contain other svg with different aspect ratios and behavior, so you can make some parts of an image scale and others not, which is pretty cool and unique to SVG.

Approaches to artboard sizing

When you draw SVG in editing software, that software likely gives you some kind of artboard to draw on. That’s not a technical SVG term; it’s essentially a visual metaphor for viewBox.

Let’s say you’re working with a whole set of icons for a site. One approach is to make all artboards hug each edge of the icon (Fig 6.8).

Fig 6.8: Example of graphics in Adobe Illustrator cropped to their edges.

Here’s a quick trick to get that artboard cropping in Illustrator: select the Artboard tool and then “Fit to Artwork Bounds” from the Presets menu (Fig 6.9).

Fig 6.9: The menu option in Adobe Illustrator for resizing an artboard to the edges of a graphic.

The big advantage to this technique is alignment (Fig 6.10). If you want to align any edge of any of these icons to anything else, that’s easy to do. There is no mysterious space you need to contend with, or tweaky positional CSS.

.icon.nudge { position: relative; right: -2px; /* UGHCKKADKDKJ */ } Fig 6.10: Icons aligning to edges without little bits of extra space you have to account for.

The big disadvantage to the cropping technique is relative sizing. Imagine you take the practical step of sizing your icon’s width and height, like this:

.icon { width: 1em; height: 1em; }

A tall, skinny icon will shrink to fit in that space and potentially appear awkwardly small. Or perhaps you’re trying to have an intentionally small star shape as an icon, except the star has a squarish aspect ratio and thus grows to fill the space, appearing bigger than you want it to.

Here’s an example where two icons are sized identically as a square (Fig 6.11). The “expand” icon looks right at home, since it has a square aspect ratio to match. But the “zap it” icon has a tall and narrow aspect ratio, so it looks wimpy, like it’s floating in the same square area.

Fig 6.11: Two icons sized in the same square space within a button. The top one fits nicely, but the bottom one floats awkwardly in space.

The other approach here is to make consistently sized artboards (Fig 6.12):

Fig 6.12: Example of Illustrator graphics whose artboards are equal in size.

The advantages and disadvantages are exactly inverse here. You might have alignment issues, because not all edges of the icons touch the edge of the viewBox, which can be frustrating and might require tweaking sometimes (Fig 6.13).

Fig 6.13: You can adjust icons’ relative sizing, but that can make alignment more difficult.

You won’t have relative sizing issues, though, because the viewBox is the same for all of them. If any particular icon looks too big or small, you can adjust the artwork to bring it more in line with the set.

Since we’re learning about sizing, now is the perfect time to bring up how SVG fits into the flexible world of responsive design.

Responsive SVG

One of the hallmarks of responsive design is fluid layout. Content—images included—is designed to fit its containers and the screen. If responsive design is new to you, Ethan Marcotte’s seminal 2010 article on the subject is a fine place to start learning about it. SVG jibes extremely well with responsive design:

  • Responsive designs are flexible. So is SVG! It renders well at any size.
  • Responsive web design is a philosophy of caring about how a website looks and behaves in any browser. Comparatively smaller SVG files and performance-responsible tactics like an SVG icon system can be a part of that.

But perhaps SVG’s most obvious connection to responsive design is the possibility to react to CSS @media queries. Media queries move, hide, or show elements with CSS based on things like the width or height of the browser window. Those elements can be anything: sidebars, navigation, ads, what have you. They can be SVG elements as well.

Imagine a logo that displays different levels of detail depending on how much space is available. That’s exactly what Joe Harrison was thinking when he created a really neat demo using well-known logos, (Fig 6.14).

Fig 6.14: Joe Harrison’s demo of the Disney logo at different sizes.

On the web, we’ve always had the ability to swap out images with other ones. What’s appealing here is that we aren’t swapping out images; these are all the same image. Or at least they could be. That signature “D” all by itself could be the same exact “D” used in the most complex version of the logo. Easy-cheesy in CSS.

Say we organize the SVG like so:

<svg class="disney-logo"> <g class="magic-castle"> <!-- paths, etc --> </g> <g class="walt"> <!-- paths, etc --> </g> <g class="disney"> <path class="d" /> <!-- paths, etc --> </g> </svg>

This, by the way, is pretty easy to do in Illustrator (Fig 6.15). The groups and names you create there turn into IDs in the SVG output, and you can use those IDs to do the styling. Personally, though, I prefer using classes because they aren’t unique (so you don’t accidentally end up with multiple identical IDs on the page) and because classes have a lower and more manageable level of CSS specificity. It’s easy enough to change IDs to classes with a bit of find-and-replace maneuvering in a code editor.

Fig 6.15: Named layers and named shapes in Adobe Illustrator.

The corresponding CSS could be something like this:

@media (max-width: 1000px) { .magic-castle { display: none; } } @media (max-width: 800px) { .walt { display: none; } } @media (max-width: 600px) { .disney > *:not(.d) { display: none; } }

Mind you, this is a contrived example of hiding parts of the images at different breakpoints, but that’s exactly how you would do it, along with some likely sizing adjustments. Anything you can do with CSS is on the table here. Perhaps some animation is appropriate at some breakpoints but not at others. Perhaps you change stroke sizes to beef up or trim down icons at different sizes. Perhaps you change some fill colors to simplify adjacent shapes.

And things can get even fancier! Depending on how the SVG is used, those media queries might actually be different. SVG used as img, iframe, or object has its own viewport. That means CSS embedded inside of it reacts to media queries based on that, rather than the whole browser window viewport. That means you would write, say, width-based media queries based on the width of the image, not of the entire page.

That’s a very appealing idea: an element that arranges itself based on attributes of itself, rather than the page. Am I this wide? Do this. Am I this tall? Do this. That way, the SVG reacts to the situation it’s in rather than the arbitrary document it happens to be part of.

As I write, this is referred to as “element queries” in CSS, but it doesn’t actually exist yet in regular HTML/CSS. Once again, SVG is ahead of the curve.

Graduation into animation

Speaking of things SVG is good at, let’s move into animation next. Everything we have been building on so far has prepared us for this. Hang on tight!

Categories: thinktime

A parody of yourself

Seth Godin - Tue 09th Aug 2016 18:08
A simple test for brands, organizations and individuals: When you exaggerate the things that people associate with you, your presence and your contribution, does it make you a better version of yourself?        Seth Godin
Categories: thinktime

The two risk mistakes

Seth Godin - Mon 08th Aug 2016 19:08
Risk mistake number one: Risk means failure. This worldview equates any risk, no matter how slim, with a certainty. If the chances of hurting yourself skydiving are 1%, it's easy to ignore the 99% likelihood that it will go beautifully....        Seth Godin
Categories: thinktime

It happens around the edges

Seth Godin - Sun 07th Aug 2016 18:08
At any gathering of people, from a high school assembly to the General Assembly at the UN, from a conference to a rehearsal at the orchestra, the really interesting conversations and actions almost always happen around the edges. If you...        Seth Godin
Categories: thinktime

Scientist, Engineer and Operations Manager

Seth Godin - Sat 06th Aug 2016 19:08
A career is often based on one of these three stances: The Scientist does experiments. Sometimes they work, sometimes they fail. She takes good notes. Comes up with a theory. Works to disprove it. Publishes the work. Moves on to...        Seth Godin
Categories: thinktime

Conservation and concentration of effort

Seth Godin - Fri 05th Aug 2016 19:08
The woman sitting next to me on the plane is successful by any measure--she's happy, engaged, making a difference. And she confessed that she doesn't buy anything from Amazon, doesn't use Facebook, rarely connects online. How is this possible? I...        Seth Godin
Categories: thinktime

Enough small moments

Seth Godin - Thu 04th Aug 2016 18:08
Shortcuts taken, corners cut, compromises made. By degrees, inch by inch, each justifiable (or justified) moment adds up to become a brand, a reputation, a life.        Seth Godin
Categories: thinktime

"I think we are an outfit headed for extinction"

Seth Godin - Wed 03rd Aug 2016 19:08
(So said Hemingway on seeing fake books in his fancy hotel room.) Of course we are. We always are. We're always headed down for the count. It's unsustainable. We corrupt our best stuff, don't take good enough care of each...        Seth Godin
Categories: thinktime

Finding Opportunities in the Mistakes We Make

a list apart - Wed 03rd Aug 2016 00:08

Roughly six years into my software development career, I had worked on interesting projects, met amazing people, and had the opportunity to travel to exotic cities. Yet I was frustrated. I was burning the candle at both ends to get things done. I didn’t look back to see if I could improve on how things were being done; I had no time. Deep down I knew it wasn’t feasible. I was working hard, not smart; I felt like I wasn’t working toward anything; I was falling behind with technology. I was burning out.

I started searching for an opportunity to facilitate my technical growth. Two years later I was based at an enterprise client who adopted agile software development methodologies, and everything changed for me. This new world exposed me to a diverse working environment and new perspectives, and encouraged me to ask even more questions than before. This is when I discovered the power of the words “reflect, inspect, and adapt.”

It wasn’t a walk in the park with unicorns and rainbows, but the experience has aided me in officially branding my career as one exciting journey of professional and self-discovery. Now ten years into my career, I realize that for most of that time I have been in survival mode. After looking back, I’d like to share how I found opportunities in the mistakes I made.

Define clear career and personal goals

Computers weren’t a household name when I was growing up in South Africa, but I was lucky to have access to my dad’s Pentium 386. I was amazed at this technology. When we got internet access, I was immediately hooked on the online world. I taught myself HTML and later built my own machine with the money I made from designing a website for the local newspaper.

When I chose my higher education path I had one goal—I wanted to make websites. I didn’t want a degree; I wanted experience. I studied at a college for two years, then excitedly entered the workforce to follow my passion.

As I entered the workforce, I wasn’t prepared for the politics: managers expecting things to be done almost immediately; clients who don’t engage and are unsure of what they want; clients who express urgency, yet wait for the last minute to provide you with everything you need; an increased workload due to colleagues who stay well inside their comfort zone. These are just some examples of the politics that initiated my frustrations.

I wondered if this is where I’d still be in five or ten years and if I would be able to sustain it. I didn’t know the answer to the former, but to the latter it was definitely no.

Coupled with turning thirty, the new perspectives I developed in the agile environment made me really evaluate my future. I realized that I didn’t have goals; I was only chasing my passion. Granted, it is fun and I gained a lot of experience in many different areas in IT, but I don’t have anything tangible to show for it now.

After much reflection, I discovered these goals for myself:

  1. Increase productivity. I minimize distractions like email, social media, and uninvited guests to improve my productivity. To make sure I am working on the right tasks, I need to have a clear understanding about what I am working on and why.
  2. Develop software that has a positive impact on people. It is important to understand business thinking and impact on users. I need to ask appropriate questions, and I need to guide and negotiate with product stakeholders.
  3. Share my knowledge. I can create an online identity (publish articles, blog), possibly speak at events, and contribute to open-source software. I can find projects on GitHub of libraries and tools that I regularly use and create a pull request.
  4. Better my craftsmanship. I can learn through code reviews and peer conversations, listen to podcasts, read up on best practices, read more craft-related reference books, and reflect on my implementation.
  5. Learn to live mindfully. To have a positive impact on people, I can make small adjustments and engage those around me to help me grow. Meditation, reflection, and motivational books are tools I could use to guide me.
  6. Showcase my career. Create a tangible timeline of projects I have worked on including screenshots, descriptions, technologies, and learnings.

These goals feel more defined to me than just making cool websites. I wish I had set some goals a little sooner but luckily — as cliché as it sounds — it’s never too late. Goals give you direction and purpose. Like me, you may have worked many late nights on personal projects that never materialized. It helps to have focus and something definite to achieve. I find what’s best of all is that I don’t feel constrained by having these goals. They represent what’s important to me now but if my values change, I can inspect and adapt my goals.

Put people before technology

For too long, I worked alone on my own codebases and wondered if I was doing things the right way. I had little to no exposure to working in teams and dealing with industry buzzwords like agile, TDD/BDD, Gang of Four, SOLID, code reviews, continuous integration/delivery, DevOps, and <insert your favorite technical jargon here>. I was in a bubble falling further behind in the fast-paced technical world. I was focused on working with technology and never realized how important it is to collaborate.

If you work in a company with a silo-based culture or one- or two-people teams, try not to accept things for what they are:

  • Get involved with your coworkers by communicating and collaborating on projects.
  • Try introducing knowledge-sharing sessions and code reviews.
  • Reflect on what worked and what didn’t and also unpack why, so that you can learn from it.
  • Approach management with suggestions on how you and your colleagues can produce more solid and effective software.
  • Attend conferences or smaller community meetups. Not only can you learn a lot through the content but you have the chance to network and learn from an array of people with different skills.
Prioritize your tasks

I often worked about twelve to sixteen hours a day on projects with short deadlines. I spent my official work hours helping colleagues with problems, immediately responding to email, attending to people with queries or friendly drop-ins, supporting projects that were in production, or fighting fires resulting from errors that usually came from miscommunication. This left me with very little time to be productive. When I finally got to work on my project, my perfectionism only increased my stress levels. Regardless, I never missed a deadline.

I thought everything was important. If I didn’t do what I was doing the world would end, right? No! The reality is that when everything is important, nothing is important.

This working behavior sets unrealistic expectations for the business, your colleagues, and yourself. It hides underlying issues that need to be addressed and resolved. If you are working at an unsustainable pace, you can’t deliver your best work plus you end up missing out on actually living your life.

The power of retrospectives

The most important ceremony (or activity) I was introduced to in the agile environment was the retrospective, which is “the process of retrospecting at the heart of Scrum (Inspect and Adapt), eXtreme Programming (fix it when it breaks) and Lean Software Development (Kaizen or Continuous Improvement)”.1

Through retrospection you are granted the opportunity to reflect on how you — and the team — did something, so that you can improve the process. Let’s run through this technique to identify some pain points using the situation I had found myself in:

  • Working unsustainable hours because there was too much to do. I helped everyone else before I worked on my own tasks, I worked on things that didn’t add much value, and I thought that all the features needed to be ready for launch. I was blind to asking for help when I needed it.
  • Dealing with too many distractions. I allowed the distractions by immediately switching context to help others because it was important to them.
  • Key-person dependency. I was the only person working on one of the projects.
  • Miscommunication resulting in errors. Communication was done via email and the stakeholders were off-site. There wasn’t quick feedback to indicate if the project was going in the right direction.

Once the pain points are identified, adjustments need to be made in order to see improvement. Large adjustments could take too long to implement or adjust to, which leads to disruptions. Smaller adjustments are better. These adjustments may or may not work in the long haul, so we can look at them as experiments.

  • To work more sustainably I need to know what I need to work on — and why — so that I can add value without wearing myself out. Perhaps I could find out what needs to be available for launch and create a prioritized list of things to do. This list could help me focus and get into the “zone.”
  • To manage client expectations, we can try open communication. This can also help me prioritize my tasks.
  • To overcome some of the distractions I could reap the benefits of being selfish by saying no (within reason). This could help me stay in the zone for longer. If anything must be expedited I can start offering trade-offs: if I do X now, can Y wait?
  • To alleviate the pressures of being the sole person able to do certain things, I could have more conversations with my manager and train a colleague so that they are aware of what is going on and someone can take over in the event that I get sick or am on vacation.
  • To reduce errors from miscommunication, perhaps we could create visibility for stakeholders. Introduce a physical workflow board and have constant feedback loops by requesting frequent reviews to demonstrate what we have done.

Experiments run for a period of time and need to be measured. This is a grey area. Measurements aren’t always accurate, but it always boils down to the pain. If the pain is the same or has increased, then the experiment needs to be adjusted or a new experiment introduced. If it has been alleviated, even slightly, then there is improvement.

Learning through experimentation

Many of the experiments mentioned above already form part of the agile Scrum framework, so let me introduce you to real-world experiments we did in our team.

Based on the way our development stories were deployed, we experienced pain with testing stories in the appropriate order. We were using Jenkins for automated deployments and each one got a number incremented from the previous one, but the testers weren’t testing the stories in any particular order. If a story was ready to be deployed, they wouldn’t know if there was another, untested story that they were unwittingly promoting to production along with it, or if the story they tried to deploy was being held back by other stories still awaiting testing.

Without waiting for a retrospective we had a conversation to highlight the pain. We chose to write the build number on a note stuck on the story card on our wall and add a comment to our digital storyboard. This created quick visibility on the chronological order of the possible deployments of our stories.

A change control process was later introduced that required details of a production deployment and a rollback plan for that change. We couldn’t quickly access the last few production build numbers, so we started writing them on stickies and put those onto a new section on our physical board. Now we didn’t have to search through email or log in to Jenkins to find these numbers. One day, we were asked when we last deployed and had to go back to email for the answer, so we started adding the date to the deployment number stickies.

These were simple experiments but they added a lot of value by saving time. We acted on alleviating pain as it happened.

Don’t be afraid to experiment if you are not in an Agile world. If you simply run to business with problems and offer no solutions then business will frown at you. The goal here is simple: identify your pain points and find simple solutions (or improvements) to try to alleviate the pain. Experiment, inspect, and adapt often.

Believe in yourself

Survival mode never did me any good. I didn’t get an award for working long hours to make deadlines. Letting my mistakes and frustrations build up over the years made me stop believing in myself.

I was stuck in a rut; technology was changing around me fast and I was burnt out and falling behind. I’d scroll through Stack Overflow and instantly feel stupid. I’d spend time looking at all the amazing websites winning awards on Awwwards and feel inadequate. I didn’t have a life as it was consumed by my obsession for work. I didn’t know what I wanted anymore, or what I wanted to aspire to.

Introspection helped me. By inspecting my behavior, I was able to make minor adjustments that I would then inspect again to see if they worked. This simple activity can show you what you are capable of and lead you to learning more about yourself and those around you. I am applying what I have learned in software in a personal capacity. I have my life back, and I feel empowered and freed.

My final thoughts

I’ve definitely made a lot of mistakes in my career. What I have shared with you is probably only a fraction of them. I don’t regret my mistakes at all; that is how I got my experience. The only regret I have is that I wish I had begun reflecting on them sooner.

When a mistake is made, an opportunity is born: learn from that mistake to do something differently next time. Take time to step out of the subjective into the objective, so that you can reflect and consider what you could do to change it. (And don’t be too hard on yourself!)

My journey has taught me to implement small experiments that can be measured and to run them for short periods of time. If something works, keep it. If not, adjust it or throw it away. By making small changes, there are fewer disruptions. If you too are in survival mode — stop and breathe now! Reflect, inspect, and adapt.

Footnotes
Categories: thinktime

Reviewing a contract

Seth Godin - Tue 02nd Aug 2016 19:08
A deal, whether in writing or orally, is not to be considered lightly, because you fully expect to keep your end of the bargain. Three things to consider before saying, "yes": What happens now: Who owes who what? What, precisely,...        Seth Godin
Categories: thinktime

The struggle to raise money

Seth Godin - Mon 01st Aug 2016 17:08
When your small business is struggling, the thought of raising money feels like a life preserver. That possible infusion of cash is a beacon of hope, the thing you can work on tirelessly. It's the one thing that appears as...        Seth Godin
Categories: thinktime

Narratives keep the feeling going

Seth Godin - Sun 31st Jul 2016 17:07
Our feelings (anger, shame, delight) appear almost instantly, and, left alone, they don’t last very long. But if we invent a narrative around an event or a person, we can keep the feeling going for a very long time. Pavlov...        Seth Godin
Categories: thinktime

Empathy is difficult

Seth Godin - Sat 30th Jul 2016 18:07
If you believed what he believes, you'd do precisely what he's doing. Think about that for a second. People act based on the way they see the world. Every single time. Understanding someone else's story is hard, a job that's...        Seth Godin
Categories: thinktime

Just because you're right...

Seth Godin - Fri 29th Jul 2016 19:07
You may be right, but that doesn't mean that people will care. Or pay attention. Or take action. Just because you're right, doesn't mean they're going to listen. It takes more than being right to earn attention and action.        Seth Godin
Categories: thinktime

Your best shot

Seth Godin - Thu 28th Jul 2016 19:07
Should you put all your best material up front? Later seems really far away. Now is far more urgent. But what if it's a marathon, not a sprint? A fast start is often overestimated. If you're truly capable of delivering...        Seth Godin
Categories: thinktime

Profit and loss

Seth Godin - Wed 27th Jul 2016 19:07
One of the easiest ways to build a positive personal P&L is to re-establish your monthly expenses at a dramatically lower level. If you cut your burn rate to the bone, you suddenly will find the freedom to say 'no'...        Seth Godin
Categories: thinktime

Resurrecting Dead Personas

a list apart - Wed 27th Jul 2016 00:07

Being a user-centered designer means that you deliberately seek out the stories, data, and rationale behind your users’ motivations. You endeavor to keep user concerns at the forefront of every design decision, and regularly conduct research and collect data.

But collecting facts about users isn’t the same as knowing your users. Research and data need to be regularly aggregated, analyzed, and synthesized into a format that is both understandable and accessible at critical moments. You need to turn user facts into user wisdom, and one of the most common methods for doing this is to develop user personas.

Type “how to build user personas” into your favorite search engine and you will get thousands of results outlining different templates and examples of personas. Across the tech industry, personas “put a human face on aggregated data,” and help design and product teams focus on the details that really matter. Studies have shown that companies can see 4x the return on investment in personas, which explains why some firms spend upwards of $120,000 on these design tools.

However, while it is common for design teams to spend considerable amounts of time and money developing personas, it is almost as common to see those personas abandoned and unused after a while. Everett McKay, Principal at UX Design Edge, has pointed out that user personas can fail for a number of reasons, such as:

  • They do not reflect real target users.
  • They are not developed with product goals in mind.
  • They are not embedded into team processes.

I agree with everything McKay suggests, but I would add that personas fail largely because of one common misconception: the false idea that once you build a persona, you’re done. As designers, we know that the first version of a product is never perfect, but with multiple rounds of design and research it can be made better. Personas are no different.

To recover personas that have become lifeless, here’s how you can iterate on them with periodic research and use them to achieve tangible goals. The following steps will help ensure you see value from the investment you made developing them in the first place. Let’s put your personas (back) to work and incorporate them into your design and development process.

How a persona dies

Let’s imagine you work at a company called Amazing Childcare that creates tools to help parents find childcare options for their children. Let’s also say you have the following data and statistics for AmazingChildcare.com:

  • 82% of customers are between the ages of 30 and 35, and 73% of those are female.
  • The most common concerns around finding childcare (as reported in user interviews) are cost and quality of care received.
  • AmazingChildcare.com has a homepage bounce rate of 40%.
  • Customer satisfaction survey shows an average satisfaction rating of 6.5 (out of 10).

While this data is interesting, it is hard to process and assimilate into your design practice. You still need to go through the arduous work of understanding why the majority of users are who they are, what problems they are trying to solve, and how you can better meet their needs. So, you decide to create a persona.

The persona you create is Susan, a 34-year old working mother of a two-year-old. She is interested in finding a qualified nanny that has passed a background check. Susan, like all freshly made personas, is a much more thought-provoking platform for crafting design solutions than a spreadsheet of numbers. She is someone we can imagine, remember, and empathize with.

This is the point in the story when Susan dies.

At first, the design team enjoys thinking about and designing for Susan. Having her “in the room” is thought provoking and interesting, but over time, Susan is talked about less and less. She starts to feel irrelevant to the products you’re building. You realize that Susan has “died,” leaving a lifeless, zombie Susan sitting in her place. You consider all the research and work your team put into creating Susan and wonder “what went wrong?”

The problem is that your personas remained static and unmoving while the company, Amazing Childcare, grew and changed.

Review, research, repeat

As your product and marketing strategies change over time, so do your target users. In our example, Amazing Childcare may have started with a large user base of parents looking for full-time childcare options for their toddlers, but over time, the demographic changed. Now, it’s most frequently used by parents of school-age children looking for one-time, “date night” babysitters. When this happens, your original personas—like Susan—are no longer useful for thinking through design problems. Unless you periodically validate your personas, you’ll be responding to old assumptions (based on your outdated personas) rather than who your customers really are. In other words, your real-world users changed, but Susan didn’t.

To remedy this, you should regularly conduct persona research, using a variety of methods to evaluate whether your personas still reflect:

  • The most common demographic, budget, and purchase scenarios of your users
  • The main behavior patterns of your users
  • The motivations and goals of your users.

You can conduct your persona research on a schedule, such as once a quarter, or you can opportunistically work it into the usability research you already do. Either way, you need to make a commitment to keeping your personas relevant.

If we go back to our example at Amazing Childcare, your personas would change based on the new research. Susan may still be a valid persona for your company, but your research would show that she no longer represents its core users, and should therefore no longer be your primary persona. Based on the updated research, you could develop a new persona named Beverly. Beverly is a 42-year-old mother of a 10-year-old boy and 7-year-old girl. Unlike Susan, Beverly is interested in finding an inexpensive babysitter for occasional date nights with her husband. You would use Beverly to think about the needs of the core user base, but only use Susan when you’re designing tools that directly cater to the demographic she represents.

It is natural and necessary for personas to evolve and change; personas like Susan can drift out of the limelight of “primary persona” and make room for new friends like Beverly. Your ecosystem of personas should be as dynamic as your ecosystem of users, and regular persona research will ensure that they evolve in sync.

Set goals

Personas can help you do more than think about and design for target users. They can (and should) be used to help you reach real, tangible goals. Goals that reflect ways of increasing business, creating better user experiences, or both, will help you update your personas and develop your product. Even if you are not sure what is possible to achieve with personas, you should make an attempt at setting goals. Goals (even unachievable ones) provide a means for tracking the return on investment of your efforts.

To get started, try using this format from Tamara Adlin and John Pruitt.

The Persona Lifecycle   Goal or issue How things are today How we want things to be tomorrow Ways to measure change Description A problem you would like your personas to solve. A description of the current state of affairs. A description of the “first step” in achieving your goal. A description of analytics, research, or other methods you can use to measure progress.

Figure 1: Tamara Adlin and John Pruitt’s Essential Persona Lifecycle format

For each goal, you will need to identify how you’ll measure progress toward that objective. You may need to create surveys and interview scripts for some, while for others, you may need analytics tools.

Here is an example of a persona goal we could set at Amazing Childcare.

Amazing Childcare Persona Goal Goal or issue How things are today How we want things to be tomorrow Ways to measure change Use our primary persona to drive feature development. We have just started our business and believe users like “Susan” (our primary persona) will want certain features (like nanny search and background checks) to be truly satisfied. However, the Susan persona needs to be validated and tested. We want to thoroughly research and validate our Susan persona and better understand how Amazing Childcare can meet our primary users’ needs. We can validate the Susan persona and measure customer satisfaction through a series of surveys and interviews. We will know we’ve succeeded when the next feature release increases customer satisfaction with Amazing Childcare.

Figure 2: Example persona goal for Amazing Childcare

Once you have created a set of goals for your personas, you can evaluate them as part of your regular research plan. If you find that you’re falling behind on any of your goals, you can research and recalibrate your personas based on the metrics you care about.

For instance, if we evaluated the Susan persona in the ways we’ve outlined above, the data we would uncover indicates that Susan doesn’t actually represent the majority of our users. We would then reevaluate our personas and ultimately develop our new primary persona, Beverly.

Putting personas (back) to work

While research and goal setting are good practices, in and of themselves, the real benefit of personas can be seen when you put them to use. Here are some suggestions for how to incorporate personas into your design practice:

  • Start putting the face of your target persona at the top of every sketch, wireframe, and prototype. Encourage others to do the same.
  • Put a comment in every product story or ticket that states the target persona for that feature.
  • Shake up regular design meetings by asking a few people to roleplay as your personas. Throughout the rest of the meeting, have them look at every new design through the lens of their assigned persona.
  • Conduct a workshop. Activities such as Persona Empathy Mapping reinvigorate and add detail to personas.

One of my favorite ways to utilize personas is to write scenarios in which they are the main character, then use them to explain research results. For example, let’s say we’re evaluating a new interface for the sign-up and login process on our website. Instead of presenting raw numbers (e.g., “10% of new users couldn’t find the sign-up interface”), we can present the data in a scenario, providing a way to understand a design problem that goes beyond statistics. Here is an example:

Beverly came to the Amazing Childcare website to evaluate whether the company would actually be useful in helping her find reliable babysitters for her family. She decides that she would like to try the product and wonders if there is a free trial available. She searches the content of the web page for the words “free trial” or “sign-up,” but is unsuccessful. She does not think the “login” button applies to her, since she is a new user and does not yet have an account. She does not think to click on the “login” button, so she fails to find the new-member sign-up interface.

In the example above, we’re using Beverly to describe feature requirements, usage statistics, and study results. The benefits of using personas to explain these components is that you are simultaneously making messy and complex details easier to understand, and forcing yourself to deeply consider who you’re really designing for. According to Alan Cooper, you should “[d]esign each interface for a single, primary persona.” Focusing on a persona like Beverly forces us to define the parameters of what our design should accomplish and helps us ultimately evaluate its success.

Keeping personas alive

Developing personas and keeping them alive can be difficult. Without regular care and feeding, they can waste away and your investment in them will be lost. In The User Is Always Right, Steve Mulder described it best:

“It’s very easy to create personas, then think your work is done. But just having personas doesn’t mean people will accept them. Just accepting the personas doesn’t mean people will remember them. Just remembering the personas doesn’t mean people will actually use them. Your job is to keep the personas alive so they show their worth.”

To ensure your personas are accepted, remembered, and used, you need to be the persona advocate on your team. As the persona advocate, you need to:

  • Regularly conduct persona research.
  • Set goals.
  • Make sure there is always a place for your personas at the design table.

With creativity and persistence, you can cultivate a suite of well-researched, battle-tested user personas.

While being a persona’s advocate may seem like a lot of work, it’s worth doing. Personas are more than just a document, they are an experience. Taking the time to draft a set of user personas, use them, evaluate them, research them, and refresh them, forces you to consider who your users are, what their goals are, and how your product fits into their lives.

If you’re ready to become the persona advocate on your team, here are some additional resources to help you along:

Books Articles
Categories: thinktime

In search of palliatives

Seth Godin - Tue 26th Jul 2016 18:07
A palliative is a treatment that soothes even if it can't cure the illness. By all means, whenever you can, fix the problem, go to the root cause, come up with a better design... But when you can't (and that's...        Seth Godin
Categories: thinktime

What have we become? (And what are we becoming?)

Seth Godin - Mon 25th Jul 2016 19:07
Every day, we change. We move (slowly) toward the person we'll end up being. Not just us, but our organizations. Our political systems. Our culture. Are you more generous than the you of five or ten years ago? More confident?...        Seth Godin
Categories: thinktime

"So simple it doesn't need instructions"

Seth Godin - Sun 24th Jul 2016 19:07
Eager (and less-talented) designers often get confused about this instruction, turning it into: "It doesn't have instructions, therefore it's simple. Consider a hotel shower. It has 11 things that might be dials, and five that actually are. The alert person,...        Seth Godin
Categories: thinktime

Pages

Subscribe to kattekrab aggregator - thinktime