Web Development Network  |  Sites:    Capital Tutorials    Internet Marketing Books    Arcade Games
Depiction- Webmaster Resources
Stock Image


Contributors: SSD VPS in Europe  |  SEO Las Vegas |  EsqRank |  Colorado Springs SEO

Dental SEO Marketing  |  Best Las Vegas SEO Company  |  Internet Marketing Companies.com

Misc Links: Submit Tutorials (Earn $$) l Advertising l Privacy Policy | Site Map

RSS News Feeds



A List Apart: The Full Feed

Articles for people who make web sites.

This is the most recent feed available as of 03/01/2017 at 03:01 PM

Big Data Visualization with Meaning

The web is not the traditional home of data visualization. You might come across a bar chart here or there in your online journey on any given day, but they’ve never been an artifact of web history. It seems like that’s been changing.

With the world becoming increasingly data-driven, we’re seeing more and more visualizations make their way onto our web pages and into our design briefs. They help us tell stories that better engage our users, and can even get them to take some kind of meaningful action.

The problem is that these datasets—sometimes so large they’re literally called “big data”—can make visualization with meaning difficult. But that’s something we as designers are equipped to tackle. We just have to know what our users are hoping to gain from viewing and interacting with visualizations, and what we have to do to make their effort worthwhile.

Data has a very strong power to persuade—powerful enough to change users’ everyday behavior, especially when data is informative, clear, and actionable. We should be putting data visualizations to work on our sites, enhancing our designs to show users how data is in service to the story they’ve come to learn about.

Data visualization on the web can be meaningful through allowing people to discover the smaller stories that resonate with them, customizing their user experience instead of putting them on a predetermined path.

Users attempting to interact with large and generally disconnected sets of data while navigating a site or trying to access relevant information end up facing a difficult, if not impossible, task. Our sites lose a certain measure of usability if they aren’t well-designed, even though the web is a natural medium for delivering truly interactive data. 

As with all design, the approach we take when creating a user-minded visualization is based on the context and the constraints we have to work with. Good data visualizations—those with meaning—need to be accessible and human even though data is rarely described with those words.

Telling a story

The key to designing visualizations is to focus on something in the dataset that is relatable to and resonates with your users. I stumbled upon this while creating a visualization from the publicly available Open Food Facts dataset, which contains crowd-sourced information on food products from all over the world.

Although the dataset covers an extensive range of information (even down to packaging materials and number of additives), I chose to focus on comparing average sugar consumption among different countries (Fig. 1) because I was personally concerned about that topic. It turned out to be a concern for others as well and became the most popular project for the dataset on Kaggle.

Bar graph depicting quantities of sugar consumption by country
Fig. 1: Average national sugar consumption

Even though I didn’t make extensive use of the dataset in my rough and ugly visualization, what I chose to focus on told a story that resonated with people because most were from the countries listed or had a growing general awareness of high sugar consumption and its effect on health. In retrospect, what’s more personal and important than your health?

Selecting data points that strengthen a story with a positive result (whether that’s eating less sugar or reducing large-scale chemical emissions) can be great, but it’s important to present a story that is as unbiased as possible and to make ethical decisions about which parts of the data we want to use while telling the story.

But what exactly is a story in the context of a data visualization? We can’t kick it off with “once upon a time,” so we have to approach the idea in a different way.

Whitney Quesenbery and Kevin Brooks provide these definitions of a story in their book Storytelling for User Experience:

  • Stories describe the context of a situation
  • Stories can illustrate problems
  • Stories can be used to help people remember
  • Stories can be used to persuade and entertain.

And I would add to the list:

  • Stories can make you question the state of a situation.

Addressing some or all of these attributes is a particular challenge for big datasets because the sheer amount of information can make finding a narrative difficult. But big or not, the principles remain the same. Visualizing any kind of data-driven story that resonates can have a powerful influence on users’ decisions.

It also stirs other questions the user might ask.

For instance, why do certain countries consume higher quantities of sugar? Are they the ones we expected? The information could challenge an assumption or two someone may have had prior to seeing the results. Just remember that visualization can be a stepping stone to further discovery, increasing the user’s knowledge and possibly affecting their everyday choices going forward.

If you’re trying to embed meaning into a large visualization through the story of a dataset’s subsection, it’s important to:

  • Discover what your users care about in the dataset. Make it relevant to their personal needs, desires, and interests.
  • Focus on that subsection ruthlessly. Get rid of anything that doesn’t further the story your visualization is telling.
  • Take care to make ethical, unbiased decisions about which data points you use to create visualizations that might influence your users.
  • Be careful not to give people all the answers; allow them to ask their own questions and make their own discoveries about the data.

This approach allows you to create something that not only resonates at a personal level, but also presents meaning in a way that encourages and allows users to take action.

But we already have a story

Though large, some big datasets already revolve around a single story. An interesting way of dealing with this particular issue is to simultaneously display different aspects of such a dataset, allowing the user to discover that meaning. This is called the “small multiples” technique. (Fig. 2)

Assorted graphs visually illustrating data as seen from memory view, code view, and process view
Fig. 2: Memory stall visualizations from the Rivet project at Stanford.

The cluster of visualizations above, for example, deals with the “story” of memory stall issues on a computer. What I find interesting about the cluster is that the heading of every visualization starts with some variation of “memory stall time.” Despite being separate visualizations, they are linked by the single story they tell and they’re presenting it from simultaneous, distinct perspectives.

It’s possible for perspectives to look completely different from one another if they visualize different kinds of data. For instance, bar charts and area charts can harmoniously coexist if the representations are appropriate for the data they’re showing. The Australian Census Explorer illustrates how this might work (Fig. 3). It allows the user to establish their own narrative through choice of topic, such as language or place.

Screenshot of the native languages list in the Australian Census Explorer
Fig. 3: Given freedom to explore, users inherently craft a personal narrative.

Framing visualizations around a personal topic (like someone’s native language) affects all associated small multiples appropriately; reframing serves to personalize the data. (Fig. 4)

Screenshot comparing two horizontal bar graphs depicting gender and age data for Australians and English-speaking Australians
Fig. 4: Comparison of gender and age data for Australians and English-speaking Australians
Screenshot depicting Country of Birth data, listing percentages for various countries and a global map with lines linking from Australia to each country
Fig. 5: Country of Birth breakdown for Australian citizens
Screenshot comparing two vertical bar graphs depicting income ranges by gender for Australians and for English-speaking Australians
Fig. 6: Income ranges by gender for Australians and English-speaking Australians

Storytelling through interaction

It can be very useful with this approach to include an interaction in one design that is capable of affecting the others—something to help the user see relationships between data points they might not have considered before. This example from essay site Polygraph shows all Kickstarter projects across space, organized here by category and American city. (Fig. 7)

Dot graphs depicting categories, number of projects, and size of projects in a selection of American cities
Fig. 7: Well-designed data visualizations can convey multiple concepts and information in parallel

The visualization is particularly interesting because it allows users to view the relationship of one variable (in this case, the project category) to others, such as American cities or project sizes. (Notice the prevalence of music projects in Nashville and game projects in Austin and Seattle). 

The Lens does something similar in its visualization of the human genome (Fig. 8) by allowing users to change views by way of various filters.

Horizontal bars aligned with their respective segments of a human genome sequence
Fig. 8: Data can be filtered to display different views of the human genome.

This can be even more effective for small multiples shown across time. Fig. 9 shows how this approach is used on a fund manager’s website. Changing the time period of an investment fund’s performance also shows how risk rating and the growth of an investment change during that period. By leveraging intuitive web animation, we can view snapshots of the data at precise moments in time.

A stack of overlaid line graphs illustrating different tracking items, plus a vertical slider that reveals changes in the tracking items when moved to different points along the line
Fig. 9: Interacting with one “small multiple” affects others, revealing relationships at distinct points of time

If the dataset is already centered around some kind of overarching story, it can be a good idea to:

  • Display different parts of the dataset in separate visualizations simultaneously
  • Treat these separate visualizations as individuals tailored to the data they’re presenting. (Bar charts and area charts can live together in harmony if the data makes it appropriate.)
  • If there is interaction, ensure that it affects the entirety of your visualization approach so that the relationships between data points are more apparent
  • Apply well-considered web animation techniques to ensure that the interaction is intuitive.

There are too many stories

What do we do when a dataset doesn’t have a single, big story to tell, yet we still need to visualize everything in it?

Although some datasets lack a specific focus (e.g., “memory stall time,” “fund performance,” or “all-Kickstarter-projects-ever”), data points may have internal relationships that reveal bite-sized stories. How do we create actionable meaning for those visualizations?

Simply showing data as-is, even in a visualization that seems to fit, rarely works well. In Fig. 10 we see relationships between Python code packages, but in a way that’s just as messy and incoherent as the data in its natural state. The lack of focus and narrative is notable. (That said, the dataset is extremely large, so a single narrative isn’t actually possible.)

A chart illustrating numerous types of data, with lines from type to type to show relationships
Fig. 10: This visualization presents nothing actionable, despite the tremendous amount of data

Since a single story isn’t possible in this situation, a better approach is to allow users to discover their own story. Your job is to facilitate that via the interaction design of the visualization.

This browser-based design in Fig. 11 (you can explore it here) visualizes code package relationships, too (in this case, JavaScript), but gives users what they need to explore the data in a meaningful way.

A computer-generated 3-D depiction of data relationships
Fig. 11: Use well-designed interactions to help users work with large, multi-narrative datasets.

Again, at first glance the visualization seems to be messy and incoherent—but look closer. Users can investigate any individual package of code, including its personal relationships (listed in the bottom left). A handy search bar has also been incorporated in the top left corner.

What makes this particular visualization more meaningful is that the user can explore it in 3D space via keyboard and mouse. Leveraging this uniquely digital capability in the browser allows users to start discovering their own story in the enormous swarm of data, “moving” toward areas in the visualization that they find more relevant to their interests or needs. (Fig. 12)

Detail view of specific data nodes in a computer-generated 3D depiction of data relationships
Fig. 12: “Moving” intuitively through the data allows users to find meaning that’s personally relevant to them

Once the user finds a package or groups of packages they’re interested in exploring, they can click on one for a specific and focused view of the package in isolation, including its relationships with other packages. A full breakdown of these relationships is posted on the left of the screen, including visual nodes linking directly to the Github page for that code package. (Fig. 13)

Isolated close-up of a specific data note and its associated information in a computer-generated 3-D depiction of data relationships
Fig. 13: Isolation view of a specific package.

This visualization, like the one shown before it, uses the idea of a network in order to display the immensity of the data, but it also uses intuitive interaction and lets the user explore in order to extract personally relevant meaning. It uses the modern advantages of the web to deal with the modern problems of big datasets, much like the following visualization from OpenCorporates. (Fig. 14)

Computer-generated display of country silhouettes sized according to the provided data and depicting lines of relationship from country to country and city to city
Fig. 14: Look for ways to “translate” data into simple and relatable concepts and simple explanations.

This design allows users to zero in on data they care about, choosing where they go and which breadcrumbs offer meaningful insight.

If a dataset needs to be fully visualized but has smaller stories within it, it may be useful to:

  • Show all data, but give users the ability to create chunks or segments they wish to explore
  • Leverage the advantages of being digital. For example, explore how input devices (e.g., keyboard and mouse) can facilitate how users interact with the data.
  • Use visual metaphors that support extensive and intricate relationship associations, such as a tree or network.

Visualization with meaning

Data is powerful in the right hands, and something we’re skilled at presenting in our websites. But toss in words like “big data” or “data visualization” and we second-guess ourselves instead of owning it as part of our workflow. The web is actually a great place for data visualization.

Leveraging the benefits of “digital” environments and tools, we can help users get what they need from large, complicated datasets. They are looking for insights, for meaningful information presented simply, for stories that resonate—for data stories they care about. We can help them find those stories by blending in a few new techniques on our end, such as sub-selections of data, use of small multiples to show relationships between data points, or even allowing user-driven focus on the full dataset.



This week's sponsor: Hotjar

Hotjar, see how your visitors are really using your site. Try it free.



I Don’t Need Help

We have no excuse…admit it. UX may brag about intuitive and pretty, but we sure suck at helping people—this one thing that most defines, most embodies great user experience.

Throughout history, there’s one recurring theme: people need help. For all we know, the need for assistance might have triggered the development of communication. It could have led to bonding among tribes and our existence today. In the future, it might be the only thing that staves off human extinction and promotes societal evolution.

But if so, that begs the question: why do we find it so difficult to ask for help or offer guidance to one another? Do we prefer to figure things out for ourselves? Are we afraid that any request for assistance would be fraught with obligations to reciprocate? Are we worried that we’ll be rejected? Or that we might not get the help we need?

People do need help. It’s a given—and a problem in the field of UX. We claim to do so much for users, but treat help as an afterthought. How come it isn’t our primary consideration?

A glance at most websites, including those for large and small organizations, suggests that user assistance is treated as a cursory option—often relegated to a question mark symbol tacked onto a corner. The assumptions are:

  • Users won’t need help; the design is intuitive.
  • If users do want help, they’ll look for it (somewhere).
  • Once users figure out where to look, they’ll seek help when they need it.

If the same scenario were layered on real-world interactions, it would be analogous to visiting a large museum, with maps, tours, guides, and program schedules hidden in a locker at some end far off the main entrance.

Why offer help before it’s requested?

Taking the guesswork out of a customer’s experience is beneficial to all involved.

Consider that you’re walking into a new casual diner. Initially you may wonder if everything is self-service, and if you are expected to clear your own table. You could just stare at folks around the room and make your move based on what other diners are doing. Or, the franchisee could help you get up to speed right away. Ikea solves the what-do-I-do problem with a “Why should I clear my own table?” sign right at the center of its popular store restaurant. The sign solves two problems—it gives the customer needed information immediately and it promotes Ikea’s aim to cut costs.

Designers create user interfaces through careful planning, so one popular conclusion is that if a design has been a success, no explanation—no prominent sign—is required.

But help is often sought or needed for a variety of reasons. Help could be required to explain certain fields in a form, to define the meaning of a specific icon, to parse highly technical terms, to identify new features, to illuminate hidden gestures, or to detail policies that are obtuse.

A user may immediately understand that a pencil icon opens an editing pop-up. If he doesn’t, he may well figure it out eventually but only after moments wasted in confusion.

No matter how smart a design is, unless it is customized to every user’s personality, needs, working conditions, device, domain knowledge, technical expertise, and mood, it will need some explaining. A good designer empathizes with unique concerns and takes users as they are, from practiced online mavens to casual browsers. A good design includes user assistance that is given due consideration. 

When help goes wrong

Sometimes websites do make dedicated attempts to help. And sometimes those attempts smack of overkill.

There are video tours expertly created to take users through each feature in the product. There are slideshows with custom fonts and colorful characters that highlight everything new and promising in the release. There are translucent overlays of clever pointers to indicate where useful action commands are located.

Analytics and studies show that when presented with any of the above on launch of an application, a user either:

  1. Rushes through it with no interest in its content, or
  2. Closes it.

The main issue with providing informational assistance as the first screen is that users do not care yet. They have not seen enough of the product to want to learn about its intricacies.

Users want to get to the product as soon as possible; they’ve already read the marketing material, gone through the registration process, perhaps even read the “Terms and Conditions.”  They do not want anything else to lengthen the delay. If forced to read through preliminary content or go through tours, they do so while disengaged and hence, promptly forget all they learned.

Some applications have book-length help manuals. Immense thought and work goes into writing and creating these documents. But they exist in a separate world, removed from the application itself, expecting the user to click away from her task at hand to read and learn. Often, they are poorly designed, making the process of finding information in the “help” website a chore.

Can help intrude?

Handholding, intrusive help is as frowned upon in the design world as lack of intuitiveness. Examples of this include forcing open an overlay with offers of help while the user is engaged in a task; loading screens full of product descriptions without context; or launching a product tour that must be completed before the user can access the product. This is where the need to understand the goals of the application comes in.

Is this an enterprise application with cloud-based storage, multiple server connections, and sensitive data transfers? In that case, help should become a visible priority. What if it’s an app built with a strong gamification approach? In that case, help can probably take a passive backseat.

Consider user behavior patterns while designing the help function. Some users prefer an uninterrupted reading experience—they like to dive deep into the subject matter, read every instruction, perhaps even download the content for offline reading. They rely on in-depth topic descriptions. On the other end of the spectrum, some users prefer to scan the text. They only seek help after they’ve made a mistake and will rarely go to a dedicated off-context help website. Short bites of support within the application work best for them.

Instructions offered in a non-intrusive manner can enhance an experience, whether real or virtual. Hiking on a trail with clear path markers, distance indicators, wildlife cautions, and plant and foliage descriptions would be safe and informative and hence, helpful. The “x minute read” tag in Medium posts, the Slackbot messenger in Slack, and the delineations of simple steps in Google Apps Learning Center are all examples of help offered to users without distracting fanfare.

How to help

Simply ensuring your user assistance function is visible can be enough to provide comfort. In the same way a good interface doesn’t make users think too hard, a good help function should be easy to find and access.

Help can be designed to be contextual or stand-alone (a mix of both works best).

Contextual help is any form of user assistance that is embedded within the product’s screens. It prevents disruption from user’s immediate focus. It is concise and quick to read and access. It is available when the user requests or—even better—expects it.

A few examples:

  • Tooltips that appear on hover indicating the name of an icon or button.
  • Info-tips that open after clicking an “i” or “?” next to a form or field or any part of UI worth explaining. These should have brief content that explains the purpose/meaning of the relevant element.
  • Ghost text that appears within a text field or next to the UI element to help users learn about the element.
  • A panel that functions an an overlay within the product screen, providing users with more detailed help information.
  • Quick “Getting Started” guides that merge with the interface and take users through the actions flow.
  • Tooltips indicating feature upgrades within the UI.
  • Hint text that demonstrates search protocols—such as suggested keywords that actually work in the application.

Stand-alone help can take a more detailed approach.

Designing the help center for an application is usually a challenge. Should information architecture match the application’s architecture? How will users approach the content? Would they want every action and interface element documented? If so, how should the content be structured for easy perusal? If they don’t, how do writers prioritize topics? How much is too much?

Effective search functionality can help save users from getting lost in content; a prominent search box makes it simple to locate the right topic before users get overwhelmed. And if the application’s search option is internet friendly, it will appeal even more to those users who prefer using a “real” search engine (like Google or Bing).

Documentation categorized by features or tasks allows users to filter more quickly. It is also important to identify which information warrants greater visibility—help users solve their most pressing concerns, and quickly. Customer feedback, analytics, and user research can help determine which topics your users are looking for most.

The myth of technical proficiency

Enterprise applications as well as consumer applications can benefit from a well thought out help system. It’s poor logic to say that an interface is designed for “technically proficient” users who therefore won’t need any help.

A well-designed help function is more than a set of instructions in an emergency. It is thoughtful, approachable, and considerate. It knows that no quest for assistance is too small, no needed explanation is too big. It’s time we uprooted the precedents of cumbersome or “barely there” help functions. It is time to make Help helpful.

After all, needing help is part of the human condition.

 



This week's sponsor: Hired

HIRED, where companies apply to you. Over 6,000 innovative companies are looking for you on Hired. Get Hired today.



Considering How We Use HTTP/2

A note from the editors: This article is part two of a two-part series exploring the new HTTP/2 protocol and using it responsibly. Be sure to read part one, Using HTTP/2 Responsibly: Adapting for Users.

It’s important to remember that HTTP/2-specific optimizations may become performance liabilities for HTTP/1 users. In the final part of this series, we’ll talk about the performance implications of such a strategy and how build tools can help you manage HTTP/1- and HTTP/2-specific assets.

Our generalized example from the previous article shows how we can adapt delivery of site assets to a user’s connection. Now let’s see how this affects performance in the real world.

Observing performance outcomes

Developing a testing methodology

Low speed mobile connections are quite common in the developing world. Out of curiosity, I wanted to simulate HTTP/1 and HTTP/2 scenarios with my own site on an actual low speed mobile connection.

In a strangely fortuitous turn of events, I ran out of high speed mobile data the month I was planning to test. In lieu of extra charges, my provider simply throttles the connection speed to 2G. Perfect timing, so I tethered to my iPhone and got started.

To gauge performance in any given scenario, you need a good testing methodology. I wanted to test three distinct scenarios:

  1. Site optimized for HTTP/2: This is the site’s default optimization strategy when served using HTTP/2. If the detected protocol is HTTP/2, a higher number of small, granular assets is served.
  2. Site not optimized for HTTP/1: This scenario occurs when HTTP/2 isn’t supported by the browser and when delivery of content isn’t adapted in accordance with those limitations. In other words, content and assets are optimized for HTTP/2 delivery, making them suboptimal for HTTP/1 users.
  3. Site optimized for HTTP/1: HTTP/2-incompatible browsers are provided with HTTP/1 optimizations after the content delivery strategy adapts to meet the browser’s limitations.

The tool I selected for testing was sitespeed.io. sitespeed.io is a nifty command line tool—installable via Node’s package manager (npm)—that’s packed with options for automating performance testing. sitespeed.io collects various page performance metrics each time it finishes a session.

To collect performance data in each scenario, I used the following command in the terminal window:

sitespeed.io -b chrome -n 200 --browsertime.viewPort 320x480 -c native -d 1 -m 1 https://jeremywagner.me

There are plenty of arguments here, but the gist is that I’m testing my site’s URL using Chrome. The test will be run 200 times for each of the three scenarios, and use a viewport size of 320x480. For a full list of sitespeed.io’s runtime options, check out their documentation.

The test results

We’re tracking three aspects of page performance: the total time it takes for the page to load, the amount of time it takes for the DOMContentLoaded event to fire on the client, and the amount of time it takes for the browser to begin painting the page.

First, let’s look at total page load times for each scenario (Fig. 1).

Stacked bar chart of “Total Page Load Times” testing results for each of the three scenarios
Fig. 1: Total Page Load Times test results indicate a significant difference in performance for HTTP/1 Unoptimized scenarios.

This graph illustrates a trend that you’ll see later on. The scenarios optimized for HTTP/1 and HTTP/2 demonstrate similar levels of performance when running on their respective versions of the protocol. The slowest scenario runs on HTTP/1, yet has been optimized for HTTP/2.

In these graphs, we’re plotting two figures: the average and the 95th percentile (meaning load times are below this value 95% of the time). What this data tells me is that if I moved my site to HTTP/2 but didn’t optimize for HTTP/2-incompatible browsers, average page load time for that segment of users would be 10% slower 95% of the time. And 5% of the time, page loading might be 15% slower.

For a small and uncomplicated site such as my blog, this may seem insignificant, but it really isn’t. What if my site is experiencing heavy traffic? Changing how I deliver content to be more inclusive of users with limited capabilities could be the difference between a user who sticks around or one who decides to leave after waiting too long.

Let’s take a look at how long it takes for the DOM to be ready in each scenario (Fig. 2).

Stacked bar chart of “DOM Content Loaded Time” testing results for each of the three scenarios
Fig. 2: DOMContentLoaded Time test results indicate a significant difference in performance for HTTP/1 Unoptimized scenarios.

Again, we see similar levels of performance when a site is optimized for its particular protocol. For the scenario in which the site is optimized for HTTP/2 but runs on HTTP/1, the DOMContentLoaded event fires 10% more slowly than either of the “optimal” scenarios. This occurs 95% of the time. 5% of the time, however, it could be as much as 26% slower.

What about time to first paint? This is arguably the most important performance metric because it’s the first point the user actually sees your website. What happens to this metric when we optimize our content delivery strategy for each protocol version? (Fig. 3)

Stacked bar chart of “First Paint Time” testing results for each of the three scenarios
Fig. 3: First Paint Time test results indicate a significant difference in performance for HTTP/1 Unoptimized scenarios.

The trend persists yet again. In the HTTP/1 Unoptimized scenario, paint time is 10% longer than either of the optimized scenarios 95% of the time—and nearly twice that long during the other 5%.

A 10– 20% delay in page paint time is a serious concern. If you had the ability to speed up rendering for a significant segment of your audience, wouldn’t you?

Another way to improve this metric for HTTP/1 users is to implement critical CSS. That’s an option for me, since my site’s CSS is 2.2KB after Brotli compression. On HTTP/2 sites, you can achieve a performance benefit similar to inlining by using the protocol’s Server Push feature.

Now that we’ve examined the performance implications of tailoring our content delivery to the user’s HTTP protocol version, let’s learn how to automatically generate optimized assets for both segments of your users.

Build tools can help

You’re busy enough as it is. I get it. Maintaining two sets of assets optimized for two different types of users sounds like a huge pain. But this is where a build tool like gulp comes into the picture.

If you’re using gulp (or other automation tools like Grunt or webpack), chances are you’re already automating stuff like script minification (or uglification, depending on how aggressive your optimizations are.) Below is a generalized example of how you could use the gulp-uglify and gulp-concat plugins to uglify files, and then concatenate those separate uglified assets into a single one.

var gulp = require("gulp"),
   uglify = require("gulp-uglify"),
   concat = require("gulp-concat");

// Uglification
gulp.task("uglify", function(){
   var src = "src/js/*.js",
       dest = "dist/js";

   return gulp.src(src)
       .pipe(uglify())
       .pipe(gulp.dest(dest));
});

// Concatenation
gulp.task("concat", ["uglify"], function(){
   var src = "dist/js/*.js",
       dest = "dist/js";

   return gulp.src(src)
       .pipe(concat("script-bundle.js"))
       .pipe(gulp.dest(dest));
});

In this example, all scripts in the src/js directory are uglified by the uglify task. Each processed script is output separately to dist/js. When this happens, the concat task kicks in and bundles all of these scripts into a single file named script-bundle.js. You can then use the protocol detection technique shown in part one of this article series to change which scripts you serve based on the visitor’s protocol version.

Of course, that’s not the only thing you can do with a build system. You could take the same approach to bundling with your CSS files, or even generate image sprites from separate images with the gulp.spritesmith plugin.

The takeaway here is that a build system makes it easy to maintain two sets of optimized assets (among many other things, of course). It can be done easily and automatically, freeing you up to focus on development and improving performance for your site’s visitors.

Reflection

We’ve seen how an HTTP/2-optimized site can perform poorly for users with HTTP/2-incompatible browsers.

But why are the capabilities of these users limited? It really depends.

Socioeconomic conditions play a big role. Users tend to buy the quality of device they can afford, so the capabilities of the “average” device varies significantly, especially between developing and developed nations.

Lack of financial resources may also drive users to restricted data plans and browsers like Opera Mini that minimize data usage. Until those browsers support HTTP/2, a significant percentage of users out there may never come on board.

Updating phone applications can also be problematic for someone on a restricted data plan. Immediate adoption can’t be expected, and some may forego browser updates in favor of preserving the remaining allotment of data on their plans. In developing nations, internet infrastructure quality is significantly behind pace with what’s in the developed world.

We can’t change the behavior of every user to suit our development preferences. What we can do, though, is identify the audience segment that can’t support HTTP/2, then make an informed decision whether or not it’s worth the effort to adapt how we deliver content to them. If a sizeable portion of the audience uses HTTP/2-incompatible browsers, we can change how we deliver content to them. We can deliver an optimized experience and give them a leg up, and we can do so while providing performance advantages for those users who can support HTTP/2.

There are many people out there who face significant challenges while browsing the web. Before we fully embrace new technologies, let’s figure out how we can do so without leaving a significant segment of our audience in a lurch. The reward in what we do comes from providing solutions that work for everyone. Let’s adopt new technologies responsibly. It behooves us all to act with care.

Further reading

Learn more about boosting site performance with Jeremy’s book Web Performance in Action. Get 39% off with code ALAWPA.



Using HTTP/2 Responsibly: Adapting for Users

A note from the editors: This article is part one of a two-part series exploring the new HTTP/2 protocol and using it responsibly. Be sure to read part two, Considering How We Use HTTP/2.

With HTTP/2 ticking up steadily in use, it’s clear that there’s something to this long overdue update to the protocol. Implementing it, however, not only changes how websites are delivered to the user, it demands that we think critically about how we migrate existing sites to the protocol. More importantly, it demands that we consider our users’ capabilities.

Whether you’ve already migrated your site to HTTP/2 or you’re bracing yourself to take the plunge, there are challenges when it comes to tuning your site’s front end architecture to be the most performant it can possibly be for all your users. Perhaps you’ve read about what it takes to get your site ready for HTTP/2. Perhaps you haven’t. If the latter describes you best, it’s not worth getting into the weeds here. The gist of it is that HTTP/2 optimization patterns are the opposite of those for HTTP/1. Your site will perform better on HTTP/2 if you avoid practices that combine files, because caching for those resources will be more efficient when they change.

In order to cope with the limitations of the aging HTTP/1 protocol, we were more than willing to sacrifice some degree of caching effectiveness for return visitors in order to speed up the initial loading of a site. Thus, techniques like scripts and CSS concatenation, image sprites, and inline assets were embraced. In a world that’s creeping toward HTTP/2, however, we’re told to abandon these practices —and for the most part, rightly so.

The reality of the situation can be more complex than we initially thought. While HTTP/2 support on both the server and client side is steadily increasing, browsers that can’t understand the new protocol will linger on for some time yet—and that doesn’t just mean Internet Explorer. It also includes browsers like Safari on older versions of OS X, UC Browser, older versions of Android Browser, and Opera Mini.

Sometimes we hurt the ones we love

HTTP/2 support is not a one-sided affair. In order for it to work, the server must not only implement it, but the browser must also be capable of understanding the new protocol. When a browser that understands HTTP/2 begins requesting content from an HTTP/2 server, the exchange will predictably occur in, well, HTTP/2. In the case of an older browser like Internet Explorer on Windows 7 (or even a current browser such as Opera Mini), the conversation proceeds in HTTP/1. The underlying mechanism that drives this behavior is nuanced, but it can be considered progressive enhancement in that we’re not breaking the experience for users on platforms that can’t use HTTP/2. They’re merely getting a less optimal experience.

Whether you’ve made the jump and optimized your site for HTTP/2 already, considering the jump from HTTP/1, or somewhere in between, it can pay (sometimes quite literally) to understand how these optimizations can impact your site’s users. Depending on your audience’s capabilities, a site optimized for HTTP/2 may well be detrimental for a segment of your audience.

HTTP/2 enjoys broad support among users in the global sense. According to the popular feature support index site caniuse.com, HTTP/2 currently enjoys support of roughly 78% of all browsers currently in use. Some fringe browsers such as IE 11 below Windows 10, and Safari on OS X below El Capitan muddle the picture a bit. You can count on at least 72% of users globally to support HTTP/2 (at least at the time of this writing).

Of course, this is just the big picture, and it isn’t an indicator of what your specific audience looks like. You need to consider the source of your visitors and what browsers they tend to use. You also need to consider where your users reside in the world.

In the rudimentary statistics I’ve compiled from caniuse.com, I’ve found that users in developing nations tend to use browsers that don’t support HTTP/2 more often than those in developed nations. Following that up with statistics from Akamai’s Q3 State of the Internet Report, developing nations generally have a lower quality of internet infrastructure than developed nations. I won’t get into the data here (though you can have a look for yourself), but if you’re curious, you can check out this short write-up I’ve done on the subject to get some context.

The confluence of these two truths creates a challenge in how we optimize sites for our visitors.

  • Even if you set up a web server that uses HTTP/2, there’s a segment of your audience that won’t receive the benefits because their connection to your server will be over HTTP/1.
  • Even worse, if you’ve optimized your site for the best performance on HTTP/2, you’ve likely made your website slower for users with older browsers.

“Aw, hell! They should just upgrade their browser!” While some of us have said this at one time or another out of utter frustration in the face of solving a challenging problem, this is a terrible sentiment. It presupposes that the user has the ability to upgrade their browser, but they’re just too damn lazy to get around to it.

The more likely problem is that users in developing nations are reliant on antiquated infrastructure or bound to a restricted data plan that makes this impractical. We need to be empathetic to this reality. It behooves you to know how many of your users are running HTTP2-capable browsers, and how many aren’t. All you need to determine this is a Google Analytics account and caniuse.

caniuse is able to comb through your site’s visitor data, then give you the status of support for a particular browser feature in the context of your site’s visitors, rather than for a particular country. Perfect for determining browser support for HTTP/2 in your audience! By opening the settings panel in the site and then clicking the “Import” button under the “From Google Analytics” header, you’ll be prompted to allow caniuse to access your analytics.

Here’s a real world scenario in which I’ve used this tool to determine an audience’s HTTP/2 support: My friend runs a reasonably popular blog about guitars and guitar accessories that receives roughly 30,000 pageviews per month. When I fed the site’s Google Analytics data into caniuse, it showed that the site’s audience over the most recent 30 day period had about 91% support for HTTP/2 (Fig 1).

Visual comparison of two equations: All Web Site Data (78.47% + 12.27% = 90.74%) and Global (70.13% + 5.95% = 76.08%)
Fig. 1: caniuse.com’s support threshold for HTTP/2 for a specific site, labeled “All Web Site Data.”

91% seems like a high level of support for HTTP/2 —and it is! Despite that fact, you must take into consideration the raw number of pageviews from browsers fetching resources over HTTP/1 because they don’t support HTTP/2.

Some basic math reveals that this segment represents 2,700 pageviews per month. Furthermore, the quoted support of 91% includes browsers that partially support HTTP/2. In this specific example, we can only be absolutely certain that around 78% of this site’s visitors support HTTP/2. This means that anywhere from 2,700 to 6,600 pageviews may be served over HTTP/1. The actual number is somewhere in between, and even though this is a minority of users, it’s still a significant number of pageviews on its own, and it may be too large for you to simply ignore.

Adapting your users’ limitations

By this point, we know three things:

  1. HTTP/2 servers will downgrade to HTTP/1 when responding to HTTP/2-incompatible browsers.
  2. HTTP/2-specific front-end architecture optimizations are usually detrimental to users on browsers that are HTTP/2-incompatible.
  3. Users in developing nations tend to have a lower level of support for newer browser features like HTTP/2, and tend to have slower internet connection speeds.

The only thing we don’t know at this point is how to fine-tune our content delivery so that it’s beneficial for everyone. Before we can really think about modifying how content is delivered to the user, there are a couple of things we should consider first.

Is HTTP/2 right for you?

Assuming you haven’t already migrated to HTTP/2, there are a few things to take into account before you invest time and resources into making the switch:

  1. While the HTTP/2 specification doesn’t explicitly require SSL, it is a de facto standard in that browsers require it. If you implement HTTP/2 on your server and fail to install a valid SSL certificate, the connection will always downgrade to HTTP/1. For the budget-conscious, certificates range from reasonably priced to 100% free via Let’s Encrypt. Even with free certificates, implementing SSL still represents a cost to your organization. It takes time and effort in the form of QA testing to ensure that existing sites aren’t broken in the migration.
  2. If your site’s footprint is very small, HTTP requests are few, and upgrading to SSL isn’t pragmatic, you may already be well-served by HTTP/1. This is especially true if you’ve implemented HTTP/1-specific optimizations and it would cost significant developer time to unravel them into HTTP/2 optimizations. This doesn’t mean that you shouldn’t upgrade to SSL, though.
  3. If most of your site’s audience uses browsers that can only support HTTP/1 and your site is well-optimized for it, you’re probably already well-served by HTTP/1. But again: consider SSL anyway.

Let me be totally clear: HTTP/2 is an excellent performance enhancement for large, complex sites with lots of assets that would otherwise perform poorly on HTTP/1. We just need to talk about how you might be able to mitigate some of the pain for users with less capable browsers, and that begins with identifying those users when they visit.

Checking for HTTP/2 and adapting to users’ needs

How you deliver content based on a given user’s HTTP protocol version depends on what technologies you have available on your host. You’ll usually use a back end language like PHP to modify the markup you send to the client. Regardless of the technology you use, there are two conditions you’re covering:

  1. If the user is on HTTP/2: You’ll serve more and smaller assets. You’ll avoid stuff like image sprites, inlined CSS and scripts, and concatenated style sheets and scripts.
  2. If the user is on HTTP/1: You’ll do the opposite. You’ll bundle files, use image sprites, and inline small assets.

The specific mechanism by which you detect HTTP/2 support will depend on the back end language you use. In PHP, we can determine the protocol version of a given connection by checking the $_SERVER["SERVER_PROTOCOL"] environment variable. Below is a one-liner that stores the HTTP/2 connection status in a variable named $isHttp2:

$isHttp2 = stristr($_SERVER["SERVER_PROTOCOL"], "HTTP/2") ? true : false;

Using the stristr function, the $_SERVER["SERVER_PROTOCOL"] environment variable is checked for the presence of the substring "HTTP/2". If the substring exists, $isHttp2 is set to true. If not, it’s set to false. From here, it’s up to you to apply this logic to your site, but let’s look at a couple of things you could do. For instance, you could add a class of http1 to the

tag:

<?php
if ($isHttp2 === false) {
	?><html class="http1"><?php
} else {
	?><html><?php
}
?>

Using this class, you can adapt your CSS to serve an image sprite for HTTP/1 users, and individual images for your HTTP/2 users. Or maybe serve a separate CSS file with inlined assets using the data URI scheme. Speaking of serving different files, you could change your markup based on the user’s protocol version to change how you serve assets to the client:

<?php
if ($isHttp2 === true) {
	<script src="/js/script-1.js"></script>
	<script src="/js/script-2.js"></script>
	<script src="/js/script-3.js"></script>
} else {
	<script src="/js/script-bundle.js"></script>
	<?php
}
?>

Or you could change your markup to inline some critical CSS for HTTP/1 users with the handy file_get_contents function:

<?php
if ($isHttp2 === true) {
	<link rel="stylesheet" href="css/critical.css">
} else {
	<style><?php echo(file_get_contents("css/critical.css")); ?></style>
	<?php
}
?>

Of course, on HTTP/2 sites, you would take any content that you’d normally inline and use server push to confer the benefits of inlining without actually inlining content. How you specifically adapt your site’s content delivery based on the visitor’s protocol version really depends on your specific situation.

This concludes the first article! In part two of this series, we’ll:

  • Apply these techniques to a real world scenario
  • Use a performance testing tool to check for meaningful comparisons se a build system to generate HTTP/1-friendly assets so you can keep your workflow clean and efficient.

Further reading

Learn more about boosting site performance with Jeremy’s book Web Performance in Action. Get 39% off with code ALAWPA.



This week's sponsor: FullStory

FullStory, the CX platform that captures every interaction on your site for pixel-perfect playback. Get it free, forever. For real.



Gaming the System…and Winning

Good intentions usually drive the “gamification” of websites—adding points, badges, and leaderboards to make them more engaging. It sounds like a great idea, but borrowing game design elements out of context is a risky way to design experiences, especially experiences intended to bring users back to a site.

Not everyone wants to spend more time on your site just to get a badge; some people simply aren’t motivated by such extrinsic rewards. When game designers include elements intended to promote deeper engagement, they look at their users through a very different lens than those of us in web design. Understanding how and why they do this can help us craft more engaging web experiences.

A game designer and a web designer looking at the same user research will most likely come up with totally different personas. Talking about many people as though they were one person can be a strength;it gives a clear vision of who we need to serve. But it’s also a limitation because this method of clustering requires us to pick certain axes and disregard others. Web designers cluster people by their needs and abilities, but in doing so, we tend to disregard their personalities. Game designers are more likely to fixate on interaction styles; they embrace personality.

Let me show you what I mean. Pokémon Go has seen a meteoric rise in popularity since its release, possibly because of how well it caters to people with different personalities. In Pokémon Go, people who like to compete can “battle” in gyms; those who prefer to collaborate can go on “pokéwalks” together; and anyone with a drive to explore and push boundaries can try to “catch ’em all.” Even if a player enjoys all of these options, they’re likely to find one more motivating than the others. Ensuring that the game caters to each interaction preference enhances its appeal to a wide audience.

The same is true of web design. Adding gamification elements to draw in more visitors—but only elements that cater to competitive people—can overlook the wider audience. UX design that doesn’t target a variety of interaction styles is going to be hit-or-miss.

Game designers (and educators and psychologists) segment people in ways that complement web design and user experience. I’ve put together this guide to show you how they think and how (and where and why) we can use their models. Along the way, I’ll show how those models might overlap to create one bigger framework that we can use to pinpoint strengths and weaknesses in our designs.

Making it fun

Emotional design—the practice of moving interfaces beyond merely usable—is a growing field of interest among UX designers. (I highly recommend Designing for Emotion and Seductive Interaction Design.) Unsurprisingly, game designers have a theory of fun, too.

A recent study performed a contextual inquiry of hardcore and casual gamers, plus interviews with their friends and family members, identifying four types of fun (PDF) that relate to interaction preference.

  • Hard Fun comes from pursuing a goal—earning rewards according to progress.
  • Easy Fun focuses on something other than winning. It encourages learning and emphasizes feelings of wonder, awe, and mystery.
  • The People Factor caters to interaction with others; the interface becomes a mechanism for social engagement.
  • Altered States attract people to engage in a social context to feel something different (e.g., to gain pleasure from acting upon or inciting those around them).

These styles are easy to spot on social networking sites:

  • Competing for likes or followers (as on Twitter) is Hard Fun.
  • Casually browsing to find humorous new posts (as on Tumblr) is Easy Fun.
  • Engaging with a social network to connect with other people (as on Facebook) is a People Factor.
  • People who experience excitement from messing with other people (as on Reddit) are enjoying Altered States.

Bartle’s four player types

There are numerous ways of grouping people by interaction style, including Hallford and Hallford’s six categories of player behavior and Yee’s statistical clustering of three player types (PDF), but I find that these approaches roughly map to Richard Bartle’s 4 player types (particularly the three non-Troll ones). Bartle’s theory is among the most common approaches chosen by game designers (Fig 1).

Fig 1: Bartle’s player types are one common way that game designers segment player experiences.

Suppose you have an ecommerce site for people to buy snakes. An Achiever may be motivated to engage by extrinsic factors: How many snakes can she collect? How many reviews of snakes can she write? The Explorer may be motivated by learning more about snakes: What’s the length specification on the new python? Where can she read more about novel uses of snakeskin? The Socializer will be motivated by interactions with others: What types of snakes are her friends buying? Is there a discussion forum where she can connect with others over her love of snakes? And you’ll probably have to deal with a couple of teenaged Trolls who just want to make fun of everyone else’s snake-buying experience.

Bartle also examines pairwise interactions between player types. This leads him to the following sorts of conclusions:

  • The ratio of Achievers to Trolls is like the ratio of rabbits to wolves. When there are too many Trolls, the Achievers leave, but without interesting victims, the Trolls leave and the Achievers return.
  • Providing opportunities for exploration is key. When there aren’t enough Explorers finding new things and telling others about them, the Achievers eventually get bored and leave, causing the Socializers and Trolls to leave, as well.
  • Trolls keep the Socializer population in check. To reach the widest audience possible, a few Trolls are necessary because they keep the Socializer population from expanding exponentially and pushing out the Achievers and Explorers. (The only other stable equilibria involve fewer player types: either a balance of just Trolls and Achievers or else a community almost exclusively composed of Socializers.)

Motivating people

Another way of segmenting people is by identifying what motivates them. At a recent conference, I saw a presentation of a study of a mobile fitness coach. The presenters said that people’s motivations for exercise tend to cluster into distinct categories. Bartle himself didn’t focus much on motivation, so it was fascinating to see how closely the presenters’ categories align with Bartle’s: one extrinsically motivated, one self-motivated, one socially motivated.

In addition to the two dimensions considered by Bartle (Players versus World and Acting versus Interacting), a third axis should be taken into account: the players’ motivations for choosing to engage. Unlike the binary nature of acting OR interacting with the player OR the world, motivations fall along a spectrum of intrinsic and extrinsic motivation (Fig 2).

Fig 2: Each player type falls on a spectrum from intrinsic to extrinsic motivation.

Ryan and Deci’s Self Determination Theory (PDF) is a framework illustrating how player types vary according to source of motivation (Fig 3).

Fig 3: Ryan and Deci represent levels of motivation.
(adapted from Ryan & Deci, 2000, p. 61)

How we can motivate people to engage with a site or app depends on where their interaction style falls along this spectrum. What player type we cater to also determines how likely people are to stick around.

  • We can motivate Achievers (or the Achiever side of people) by adding extrinsic metrics they can use to compete with others. Achievers, being extrinsically-motivated, will eventually grow bored and leave. Gamification techniques like points, badges, or leaderboards motivate Achievers extrinsically but can also give them a way to measure their growing competence (encouraging intrinsic motivation).
  • Explorers set their own goals and are self-motivated to interact with your website. Because they’re intrinsically motivated by enjoyment of the task itself, they tend to stick around longer. (Bartle says that changes in numbers of other player types doesn’t usually impact the number of Explorers.) To promote long-term engagement of Explorers, it helps to introduce unexpected achievements. Hinting that there are some Easter Eggs hidden in your site could be a great way to encourage explorers to stick around.
  • Socializers will stick around as long as there’s enough social interaction for them. We can motivate them by adding ways to add their own thoughts to site content, such as comments on an epublishing site or reviews on an ecommerce site. If they don’t get enough external feedback from other people, they’ll leave. Adding a way to “Like” reviews or respond to other users’ comments can help to provide this feedback.
  • Trolls set their own goal of annoying other users, but they require feedback from others to know that they’re actually being annoying. The expression “Don’t feed the Trolls” means removing this feedback loop, which we can do with moderation tools and community posting guidelines.

How you choose to present rewards will encourage people with different preferred interaction styles to engage with your product. Conventional cognitive psychology wisdom suggests that irregular rewards at irregular intervals motivate continued engagement most effectively. (Expected rewards can be problematic because if people know that a reward is coming, they may work for the reward rather than focusing on the task itself.) Yet, having a variety of expected rewards can help people set goals, thus promoting Achievers.

Helping people learn to use your site

When we make fairly complicated sites, people may cycle through different player types as they learn to engage with them.

To see what I mean, consider the Experiential Learning Cycle of Kurt Lewin, which contains four stages (Fig 4).

Fig 4: Lewin shows how we learn.

Viewing this cycle through Bartle’s player types, it’s possible to align player characteristics with aspects of Lewin’s cycle: Achievers concretely experience the world, Explorers reflect upon what they see, Socializers abstract the world into a context they can discuss, and Trolls premeditate their approach to interactions. This mapping also works with Bartle’s axes (Fig 5).

Fig 5: Lewin’s learning model can be overlaid upon Bartle’s player types.

For example, someone coming to a large content site focused on do-it-yourself projects might initially be motivated to engage by their own experience with home improvement. Once they’ve engaged regularly with the site for a time, they might move to a more reflective mode, exploring more of the site. If they really get interested, they might join in the discussion forum, discussing projects with others, and this discussion will give them new ideas for projects they can create in their own life. Application of the ideas to the real world moves back to the Achiever quadrant, but may impact people in that world as well (the Troll quadrant). Thus, if we want people to engage deeply with a site or app over time (learning different aspects of it) it helps to support the many different interaction styles that people may use to engage while learning.

Making it engaging

Of course, when we make websites, we often talk about supporting immersion through an experience of flow. Game designers again bring light to this form of interaction. Salen and Zimmerman, authors of the seminal textbook on game design, note that four parts of Mihaly Csikszentmihalyi’s flow model are necessary for flow to occur:

  • Challenge
  • Goals
  • Feedback
  • Control

All four player types need all four of these to engage fully, yet each prerequisite of flow might be aligned with a player type and learning stage (Fig 6). 

Fig 6: Csikszentmihalyi’s four prerequisites of flow can be mapped to the same axes as Bartle’s player types.
  • Achievers seek challenge. (They don’t set their own goals as much as Explorers, but will tackle whatever extrinsic challenge you put in front of them.) Challenge is actively experienced.
  • Explorers set their own goals to create challenge for themselves. These goals project into the future with reflection upon observation.
  • All players need feedback from the game, yet Socializers thrive upon feedback from other players.
  • Trolls seek control. (To prevent trolls, building in some form of moderation system is a way of taking away their control.)

For example, a photo-sharing site might create an immersive experience by challenging people to upload a certain number of photos, letting them set their own goals for organizing content, allowing other people to give feedback about the quality of the photos or collections, and giving everyone a comfortable sense of control over their own photos and collections. Introducing artificial difficulties, like saying “Try only uploading black and white photos this week” can make the experience more game-like, presenting a challenge that people can choose to use as their own goal or not.

Bringing it all together

Here is a fully overlaid model based on my own interpretation of how they’re related (Fig 7).

Fig 7: All of the models can be overlaid upon each other to form a diagnostic tool.

This model might be expanded further using other four-part models from game design such as Hallford and Hallford’s four reward types or Callois’s four game types. To examine how people progress through the learning stages, we might overlay David Kolb’s Experiential Learning Cycle (which is built upon Lewin’s model for learning).

I haven’t tested all the variables here, but I hope that this grouped model can be a useful diagnostic tool, as I’ll show with the following three examples. (If you encounter evidence supporting or refuting this way of overlaying the models in your own work, please leave a comment at the end of the article explaining what you’ve found.)

The model suggests that if a new feature does not succeed right away, it may largely be due to the interaction styles of the people engaging with the site or app. For example, on a start-up site I worked on, the most engaged users were the ones who had created their own reviews. When we added a discussion forum, it initially didn’t get a lot of use. One possible diagnosis of this slow beginning is that most of the people we’d attracted were Achievers, who learned through their own experiences and enjoyed the challenging hard fun of seeing who could write the most reviews. We dialed back the discussion experience to focus the site more directly on these Achievers. Another approach might have been to add a competitive element to the discussion itself; you’ve probably seen forums that rank their participants, which is a way of luring Achievers to be more social (and thus creating a more diverse community for Socializers).

The Troll quadrant is certainly the one least directly mapped to by other models. One possible explanation of this is that we try not to design for Trolls. An explanation I consider more likely is that in a socially-moderated setting, there’s little opportunity for Trolls to exist. If your site is having difficulty with Trolls, the model suggests that making it more difficult for people to act upon people can mitigate the problem. Moderation tools can take away the control that trolls require, making it difficult for them to create altered emotional states.

Bartle found that Explorers are rare and difficult to attract, but necessary for the long-term survival of a site. They’re the ones who try out new features to give the rest of the community things to do and discuss. One conventional approach to trying to increase site engagement is to add “gamified” elements, such as points, badges, and leaderboards. But such an approach may actually harm long-term engagement because such extrinsic motivators are unappealing to the Explorers who help the community evolve. Looking at what interaction types a site appeals to and then adding elements to appeal to others can help the site to grow a well-rounded, sustainable audience.

There’s much more that can be brought from games to make the web fun and meaningful. I hope that a greater understanding of how game designers make experiences engaging can empower web designers to craft a more intriguing and inviting web for a wide variety of people.



This week's sponsor: GatherContent

GATHER CONTENT: Stop content delaying website launches with custom collaborative online templates and workflow. Try it free!



Guerrilla Innovation

In a culture like Google’s, having paid time to innovate is celebrated. But most of us don’t work at Google; most of us work at places that are less than thrilled when someone has a bright new idea that will be amazing.

After all, who has time to try new things when the things we’re doing now aren’t broken? No one wants to be forced to use another app, to have yet another thing they are expected to log into, only to see it die out in six months.

So how do you push an idea through? How can you innovate if you work in a less-than-innovative place?

It takes more than a big idea

Let’s say you just saw a demo of someone using a prototyping tool like UXPin and you’ve got this big vision of your team incorporating it into your development process. With a tool like this, you realize, you can quickly put some concepts together for a website and make it real enough to do user testing within two days! Seems pretty invaluable. Why haven’t we been using this all along?

You create an account and start exploring. It’s pretty damn awesome. You put a demo together to share with your team at your next meeting.

Your excitement is completely drained within five minutes.

“Seems like a lot of extra work.”

“Why would we create a prototype just to rewrite it all in code?”

“Let’s just build it Drupal.”

Knife. In. Heart.

You can see the value in the product, but you didn’t take the necessary steps to frame the problem you want to solve. You didn’t actually use this exciting new tool to build a case around the value it will have for your company.

So right now, to your coworkers, this is just another shiny object. In the web development world, a new shiny object comes along every couple seconds. You need to do some legwork upfront to understand the difference between what shiny object is worth your team’s time and what is, well, just another shiny object.

Anyone can come up with an idea on the fly or think they’re having an Oprah Aha! Moment, but real innovation takes hours of work, trying and failing over and over, a serious amount of determination, and some stealth guerrilla tactics.

Frame the problem

The first step in guerilla innovation is making sure you’re solving the right problem. Just because your idea genuinely is amazing doesn’t mean it will provide genuine value. If it doesn’t solve a tangible problem or provide some sort of tangible benefit, you have little or no chance of getting your team and your company to buy into your idea.

Coolness alone isn’t enough. And “cool” is always up for interpretation.

Framing the problem allows you to look at it from many different angles and see different solutions that may not have occurred to you.

By diving deep into the impact and effects your idea will have, you will start to see the larger picture and may even decide your idea wasn’t so amazing after all. Or, this discovery could lead you to a different solution that truly is innovative and life-changing.

Start at the end

When your idea is implemented and everything goes as planned, what benefit will it provide?

Make a list of people who would theoretically benefit from this idea. Write down who they are and how the idea would help them.

Let’s go back to our prototyping tool example. Who would benefit from it the most? The end user looking for specific content on your website. Using a prototyping tool would allow you to do more user testing earlier in the process, letting you tweak and iterate your design based on feedback that could improve the overall site experience. An improved experience would, ideally, allow visitors to find the content they are looking for more easily; the content would therefore be more useful and usable for them.

If visitors have a better experience, that could result in a better conversion rate—which in turn would help your manager’s goals as web sales improve.

That benefit could extend to your team as a whole, too: a prototyping tool could improve communication between the marketing group and the development group. Using a prototyping tool would help quickly visualize ideas so that everyone can see how the site is evolving. Questions could be asked and addressed sooner. A prototyping tool could be just the thing you need to get everyone on the same page about content and identified goals.

Identify your target audience(s)

The top two audiences with the potential to get the most benefit from your innovative idea are your target audiences. If the end user of the website will receive the most benefit, then that is your primary target audience. If your manager receives a benefit as a result, then that is your secondary target audience.

Take some time to develop a persona around each of your top target audiences. A persona is a document that summarizes research trends and data that have been collected about a key audience segment. Although a persona depicts a single person, it should never be based on one real individual; rather, it’s an amalgam of characteristics from many people in the real world. A persona is usually one page and includes characteristics such as attitude, goals, skill level, occupation, and background. For more on developing personas to improve user experience, check out Usability.gov.

When you’re waist deep in this idea in the next six months and your coworkers are complaining about the extra workload, and you’re wondering why you ever decided to do this you will look at your white board where you have your personas displayed and you will remember they are your target audience, not you. All of this extra work is for their benefit.

As you implement a workflow using a prototyping tool and the decision gets made to only do only one round of user testing instead of the three rounds that were initially discussed, you can reference your personas and ask who stands to benefit from that decision. Are you just saving time for the developers and the stakeholders in an attempt to pump out websites faster? Or will this really benefit the target audience?

Do a pre-postmortem

Understanding the risks of innovation does not mean backing away from your idea and giving up. When you understand the obstacles in front of you, you can more easily identify them and develop solutions before potential failures take place.

One useful exercise is to do a postmortem report even before you begin. Start anticipating the reasons the tool or project will fail so you can avoid those pitfalls. Some questions you might ask in a postmortem:

  • Who was involved in the project?
  • What went well with the project?
  • What did not go well?
  • What can we do next time to improve our results?

With our prototyping example, a possible reason for failure might be the team not adopting the tool and it never gaining traction. You need the team to be on the same page and using the same workflow; lack of adoption could be detrimental to progress.

Analyze your current situation

What sorts of effects are you seeing right now because of this identified problem? Gather some data to prove there is an actual problem that needs to be addressed. If your help desk continually receives calls about users unable to find a specific button on your website, for example, then you have some evidence of a bad user experience.

Do some research

Ask your coworkers what they know about prototyping. Ask if they have ever experimented with any prototyping tools.

Ask your end users about the content on your site. Gather some information about just how bad the user experience really is.

This is not the time to pitch your idea. You are in complete listening/observation mode. Save the elevator pitch for later, when you have all the information and are confident this is the right solution to a very specific problem and you are prepared to answer the questions that will come.

Assess your tools

Are there any tools you use now that are similar to the tool you are proposing? If so, what are their benefits and downfalls?

Take the UXPin example. Does your team use paper to do prototypes right now? Does the graphic designer use Photoshop to start with wireframes/prototypes before doing a high-res layout?

Having a ready list of pros and cons for the tools you currently use will help you build a case around why your solution is superior and will show that you’ve done your homework.

Check your ego

Scrutinize your motivations for wanting to introduce a new tool. Do you want to try something new just to take control of a situation? If the graphic designer does a fine job using Photoshop to develop a prototype but you don’t know how to use Photoshop, that’s not a great reason to try a new tool.

However, if you have a team of six and only one person knows how to use Photoshop, choosing a more accessible tool with a shorter learning curve could be the right move.

Explore other solutions

Are there other tools out there that will solve the problem you discovered?
If you don’t yet have room in the budget for UXPin, can something else get you by while you prove the value of this type of tool? can you use paper prototypes for a few months while the team adjusts to this new part of their workflow?

Sometimes starting with something less complex can be beneficial. Anyone can use pen and paper, but learning new software can be daunting and time-consuming.

Still think this is an awesome idea?

You now understand the tangible benefits of implementing your innovative idea and you know who stands to gain from it. You can foresee both the rewards of implementing it and the potential risks of not implementing it.

Your motives are good, you’ve analyzed your current situation for similar tools or processes that may already be in place, and you’ve explored other potential solutions. You are well on your way to building a strong case around your innovative idea. At this point, you’ve put a lot of time and effort into developing it. Do you still think it’s a good idea, and are you as excited as you were when you started?

If you’ve lost your drive and excitement at this point, or have been unable to visualize any real benefit, the idea may not be worth implementing. That’s okay. The way you will land on a really great idea is by testing many not-so-great ideas until you find one that fits.

Your continued excitement and drive will be necessary as you start to implement your idea and work toward gaining supporters.

Start small and fail as soon as possible

Even if you’re still quite sure this idea is amazing, start small and keep an open mind. A thousand questions will come to mind as you begin using an actual product with real users.

As you start running a couple of tests, use language like “experiment” instead of “implementation.” This leaves room for error and growth. You want to know what’s not going to work as much as you want to know what is going to work. And if someone asks what you’re doing, it sounds way more innocent if you say you’re running a few experiments that you’re going to share with the team than if you say you’re implementing a prototyping tool into our web development process.

If you’re working on a current website project, try creating just one page using the prototyping tool on your own time, not as a part of the official project process. See how it goes building just one page for now. Even better, try making just one element of the page, like the header or navigation. By starting small you will have fewer variables to take into consideration. Remember, right now you’re evaluating the tool itself, not necessarily the user experience of your website.

Then take your prototype and see what kind of feedback you can get by testing it with real end users.

Is the prototype responsive? What URL did you need to use to access it? Was it easy to direct users to this URL? Can you record mouse movements or clicks, and do you need to? How are you documenting their feedback to the site? Were they able to use their own device, or did you need to provide it? What are you going to do with the feedback and observations you’ve gained?

Do several tiny experiments like this, making adjustments as you go, until you’re more comfortable with the tool, its features, and the results you get from it. Your confidence with the tool will give your team confidence with it as well.

Don’t get fired

Most companies don’t mind their employees doing research about their work on company time. Unfortunately, some do mind. Using your own device on your lunch hour or before and after work may be your only option.

Even if your job does allow you to research and learn on the clock, be respectful of time. Spending several months straight iterating on one idea might not be good for your next employee review. 3M designates 15 percent time for employees to focus on innovation; Google has famously allowed up to 20 percent of employee time to focus on new innovative ideas. Try to gauge what percentage of time you could reasonably spend on your research without neglecting your real job.

Be transparent about what you’re doing. Hiding it and sneaking around will give the wrong impression. Let your boss know you’re curious about a new tool and you’re just running a few experiments to explore it more. Curious, experiment, explore—as I suggested earlier, these are all safe words implying no level of commitment or pressure.

Win allies

Presumably you have a few friends in the office; take them out to lunch and toss them the idea. Let them know about the experiments you’re running and the results you’re getting. Ask if they want to see what you’ve been working on.

It might take a while for anyone to show some interest. Don’t give up if your excitement isn’t mirrored immediately and don’t be pushy. Remember, you want your colleagues to be in your corner.

Also, bouncing your idea off your coworkers is great practice for telling your boss. Your coworkers will definitely ask you a bunch of questions you haven’t thought of yet and will express viewpoints you haven’t considered.

Listen to their opposition and use their concerns to build your case. Do they think adding a new tool to the workflow will slow down the process? Explore that concern; next time you talk, offer some data and insight about how that assumption might not be true.

Having your team on your side will go a long way when presenting this to your boss, but it doesn’t have to be a deal-breaker if they’re not. Sometimes our coworkers are just so scared of change that no amount of data will make them comfortable. They will likely express their concerns when you bring your idea up in front of the boss; having a prepared response makes you look confident.

Get your boss’ support

Time to go up a level. Please do not put together a giant presentation, wear your best power suite, and pour your heart out onto the line. If your experience is anything like mine, you’ll just spend the rest of the day crying off and on in the bathroom.

A definitive, polished presentation can be offputting. It makes you look like you’ve already solved the whole problem. You want to appear open to suggestions—because you are.

The approach

You know your relationship with your boss, and how to approach them, better than anyone else. For me, the best way is to wait for the right opening and mention the new idea in passing. Be prepared to show all of your progress and make some sort of proposal right on the spot. Make it seem easy and low-risk, with clear next steps. I’ve found it beneficial to address the concerns of your team up front to show you value their opinion and input. Bosses love teamwork.

If there isn’t clear interest from your boss, ask them what other data or information they would like to see to help support this idea. What are their concerns or hesitations?

At this point, consider asking for permission to continue to experiment on a broader level. The word “implement” really freaks people out. Trying a prototyping tool in the web-development process for three months instead of implementing it forever sounds a lot less risky.

Persevere

If you can’t stick with your idea long enough to do some research and run some experiments, why should anyone else? If it truly matters to you and you can see your idea making a real change in your company or within your work environment, hang in there for the long haul.

When the graphic designers agree to use UXpin as a prototyping tool and the User Experience team (if you’re lucky enough to have a UX team, really I’m not jealous) says they will give it a try for end user testing, ask to be a part of their process. Ask them to invite you to the end-user testing sessions and the design reviews with the stakeholders.

Be in those sessions and meetings as the the idea is implemented so you can continue to reference your personas and make sure decisions are made for the right reasons. That way, you’ll be in the front row to see positive change happen as you guide your idea and hard work into something truly innovative.

As your idea starts to gain traction and your experiments turn into a real process—see things through. Don’t just hand off your idea and hope for the best like a child waiting for the school bus. Drive the damn bus.

 



A Dao of Product Design

When a designer or developer sets out to create a new product, the audience is thought of as “the user”: we consider how she might use it, what aspects make it accessible and usable, what emotional interactions make it delightful, and how we can optimize the workflow for her and our benefit. What is rarely considered in the process is the social and societal impact of our product being used by hundreds of thousands—even millions—of people every day.

What a product does to people psychologically, or how it has the power to transform our society, is hard to measure but increasingly important. Good products improve how people accomplish tasks; great products improve how society operates. If we don’t practice a more sustainable form of product design, we risk harmful side effects to people and society that could have been avoided.

The impact of product design decisions

In 1956, President Eisenhower signed the U.S. Interstate Highway Act into law. Inspired by Germany’s Reichsautobahnen, Eisenhower was determined to develop the cross-country highways that lawmakers had been discussing for years.

During the design of this interstate network, these “open roads of freedom” were often routed directly through cities, intentionally creating an infrastructural segregation that favored affluent neighborhoods at the expense of poor or minority neighborhoods. Roads became boundaries, subtly isolating residents by socioeconomic status; such increasingly visible distinctions encouraged racist views and ultimately devastated neighborhoods. The segmentation systematically diminished opportunities for those residents, heavily impacting people of color and adversely shaping the racial dynamics of American society.

Such widespread negative consequences are not limited to past efforts or malicious intentions. For example, the laudable environmental effort to replace tungsten street lamps with sustainable LEDs is creating a number of significant health and safety problems because the human impact when applied at scale was not thought through sufficiently.

In each example, we see evidence of designers who didn’t seriously consider the long-term social and moral impacts their work might have on the very people they were designing for. As a result, people all around suffered significant negative side effects.

The ur-discipline

Although the process is rarely identified as such, product design is the oldest practiced discipline in human history. It is also one of the most under-examined; only in relatively recent times have we come to explore the ways products exist in the context they impact.

Designers often seek to control the experience users have with their product, aiming to polish each interaction and every detail, crafting it to give a positive—even emotional—experience to the individual. But we must be cautious of imbalance; a laser focus on the micro can draw attention and care away from the macro. Retaining a big-picture view of the product can provide meaning, not only for the user’s tasks, but for her as a person, and for her environment.

Dieter Rams’s ninth principle says that good design is environmentally friendly; it is sustainable. This is generally interpreted to mean the material resources and costs involved in production, but products also affect the immaterial: the social, economic, and cognitive world the user inhabits while considering and using the product.

At a high level, there is an easy way to think about this: your product and your users do not exist in a vacuum. Your algorithms are not fair or neutral. Your careful touch is not pristine.

Your life experiences instill certain values and biases into your way of thinking. These, in turn, color your design process and leave an imprint behind in the product. It’s essentially the DNA of your decisions, something embedded deeply in the fabric of your work, and visible only under extremely close inspection.

Unlike our DNA, we can consciously control the decisions that shape our products and strive to ensure they have a positive impact, even the myriad subtle and non-obvious ways we might not anticipate. Let’s learn to solve the problems we can’t yet see when designing our products.

Design for inclusion

When we set out to design a product, we generally have a target audience in mind. But there are distinctions between functional target audiences and holistic ones. To create products that embrace long-term positive impacts, we must embrace inclusive thinking as comprehensively as we can.

Conduct research into racial and gender politics to broaden your awareness of the social structures that impact your customers’ lives. These structures alter people’s priorities and affect their decision-making process, so design for as many social and societal considerations as possible. Sometimes people who fall outside the “target audience” are overlooked simply because their priorities for your product come in second place in their lives. Design your product to bridge such gaps, rather than ignoring them.

Listen to the voices of people expressing concern and learn to see the pain points they experience, even if they don’t articulate them as such. Step up to your responsibilities as a designer, curator, entrepreneur, or platform owner. You may not be an elected official, but when you offer products you still have responsibility over the roles they play in people’s lives and experiences—so govern accordingly.

Read studies that examine human psychology to understand how people’s biases may be exacerbated by your product. Learn about microaggressions so you can consciously design around them. Extrapolate how people with nefarious goals—from hackers to authoritarian governments—could exploit or abuse your features or the data you collect.

Work with data and let it inform you, but remember that data is suggestive, not authoritative; the data we gather is always a myopic subset of the entirety that exists but cannot possibly be measured. Enrich your process and viewpoint with information, but let your heart drive your design process.

These principles are more than “nice-to-haves”—they help you design with an ethical and moral code as inherent throughout the product as the design system used to build it.

Foster positivity and civility

When we use a product frequently, the DNA of its design process can leave a psychological imprint on us. Facebook knows it can affect people’s moods by putting more positive items in their feeds. When news broke that it did so, people were upset about this manipulation. In actuality, our lives are constantly being manipulated by algorithms anyway; we’re just not very conscious of it. Often, even the people who designed the algorithms aren’t conscious of the deeper manipulative impacts.

Features like upvotes and downvotes may seem like a balanced solution for people to express opinions, but the downvote’s only purpose is to feed and perpetuate negativity; it can be avoided or removed entirely without harmful consequences.

Don’t give angry people shortcuts to wield negative power; make them either articulate their anger or deal with it in more constructive ways. Social media platforms never benefit from angry, biased groups suppressing messages (often positive and constructive) from people they despise. In those scenarios, everyone loses—so why design the option into your product?

Any feature that petty, time-rich people can abuse to game your product’s ranking or discovery algorithms is a feature that eventually serves up toxic behaviors (regardless of the person’s politics) and is best left out.

Also avoid features that simply waste time, because when people waste time they feel less happy than when they do something productive or constructive. And of course, don’t deliberately design time-wasters into your product and offer users a premium fee to avoid them; that’s just not civil.

To foster positive behavior and encourage civility, you can reward good behavior and hold bad behavior accountable. Holding bad behavior accountable is crucial to establishing a credible community or platform—but no rewards for good behavior risks creating a fear-driven atmosphere.

A great example of designing consciously like this is Nextdoor, a platform for local communities. Nextdoor made a purposeful effort to reduce racial profiling by users by redesigning a small part of their product. For example, when reporting “suspicious activity,” new follow-up questions like “What are they doing that’s suspicious?” are required fields, so that users can no longer simply accuse people of color of “being suspicious.” The resulting 75 percent reduction in racial profiling is great for obvious reasons, but it also has the effect that users are actively being trained to no longer associate the two as interchangeable.

Design to avoid vectors of abuse; strive to encourage positive interactions and, wherever possible, challenge and transform existing biases.

Boost confidence and courage

People likely use your product to accomplish something, whether it’s a leisure task or a professional one. A user who repeats certain tasks with your product is effectively practicing her interactions; find the opportunities therein to help her grow as a person, not just succeed as a worker.

For example, when my cofounder and I set out to create Presentate, our goal wasn’t merely to create a web-based version of Keynote or PowerPoint—we set out to help people lose their fear of public speaking, to prevent audiences from experiencing “Death by PowerPoint,” and to create the fastest, most effective presentation software and sharing platform available on any device.

Our business effort was cut short, but our product design goals were achieved even with our alpha software: our users—the presenters—felt more confident and relaxed, found it easier to focus their energies on their talks, and spent far less time creating the presentations (leaving more time to rehearse). Plus, their audiences didn’t suffer through the dreaded stack of bullet points and a monotonous presentation.

Instead of seeing our product as a combination of features and UI, we considered it a tool that could empower people far beyond the scope of their tasks. Your product can do the same if you think about how it could strengthen related skills (in our case, public speaking) the more someone “practices” by using it.

Think about features and insights that encourage people in positive ways; teach them knowledge you have that they might not, perhaps as imposingly as by embedding its principles as features themselves.

Your user is likely a busy person with a million things on her plate—and on her mind. She won’t sit down and think introspectively about how your product affects her life, but you as the designer or developer can and should do precisely that.

You can spend the extra time upfront thinking about how to inform or teach your users new insights or techniques that help build the confidence they are looking for. Empowerment isn’t just the facilitation of a new ability—it’s the emotional and mental strengthening of confidence in your customer when she meets a challenge and accomplishes something impressive.

Strengthen emotional fortitude

Emotional fortitude is the foundation that helps you to be courageous and honest, and to better withstand setbacks. A person who feels emotionally secure has an easier time finding the courage to admit failure or mistakes, which creates opportunities for them to learn and grow. Conversely, emotional fragility erodes a person’s confidence and obstructs personal growth.

People’s emotional states are influenced heavily by external factors. Our environment plays a role in shaping how we see the world, its opportunities, and its problems. But while there’s been extensive research into the role of legislation on our lives, there’s comparatively little research examining the role that products play in our environment. This is becoming pressing as software and technology communicate with us, to us, and about us as frequently as other people do; they now have as much of an effect on our lives as laws and regulations.

Behavioral science and nudge theory strongly suggest that behaviors can be positively influenced by conscious efforts. For instance, rather than mandating certain actions, you could encourage better decisions or actions by making them more prominent or appealing. This kind of influence can and often does extend beyond behaviors and into our states of mind.

To be clear, this is not a deterministic argument—technology and products don’t inherently make us sad or happy, confident or anxious. Rather, this is an argument that products have the potential to influence us in emotional ways, and that the greater a product’s user base and its daily use of the product, the more impactful its effects can be on how they see and experience the world.

The strongest case for this is made by a variety of studies that show that our current social media platforms make people less happy. But what if those platforms had the opposite effect, instead making people happier and more confident about their lives?

One way is to take a teaching approach with your users. When enforcing Terms of Service, for instance, just saying “your actions are unacceptable and violate our ToS” doesn’t explain what was not okay or why you don’t want that kind of behavior. It also doesn’t suggest which behaviors you are looking to see from users. The former approach causes people to feel emotionally insecure, so focus on the latter—on positive kinds of interactions you wish to foster on your platform. They can be actual conversations, or simply part of your marketing and messaging.

Products can also affect our psychological and emotional well-being through the types of behaviors they facilitate and foster. For example, features that can be exploited by petty individuals may result in a great amount of petty behavior on your platform or within your community; we know this behavior creates emotional fragility, not fortitude. On the other hand, features that surprise and delight users (a tenet of great emotional design) can have a fortifying effect on a person’s emotional state.

When designing Presentate, our goal wasn’t “to make slideware”; our goal was to make presenters more confident in their presentation and have greater confidence as speakers. Our means of achieving that goal was to design a slideware product that would accomplish both.

Another fine example is Tesla, a company that makes electric vehicles and associated technology. As its CEO and founder Elon Musk repeats at many of their product announcements, Tesla’s goal—its mission—is to transform us into a renewable-energy human society. In setting its goal accordingly (and explicitly!), Tesla operates on the premise that it needs to do more than simply make a product; it needs to change people’s views and how they feel about their existing products. At the Solar Roof announcement, Musk reiterated that “the key is to make it desirable,” to make something people want regardless of its role in the energy revolution. Similarly, Tesla’s Model S car outperforms many a muscle car in drag races, legitimizing the electric vehicle as a high-performance option for speed enthusiasts. This approach helps to change people’s wider perceptions, extending beyond the products themselves.

When we set our goals not just to create great products, but products that help transform how we think, we can tackle underlying biases and prejudices that people may have but would be happy to be eased out of. We strengthen their confidence and character, and address problems that go well beyond the scope of any one product. And while none of us are solely responsible for fixing major problems in society, each of us, when designing a product, has an opportunity to make it part of the solution.

Or as Nextdoor CEO Nirav Tolia said, when asked about why they changed their design:

We don’t think Nextdoor can stamp out racism, but we feel a moral and business obligation to be part of the solution.

Recreate social mores

There is no digital duality, no “real world” separated from our environment online. Generally, every avatar you talk with on a screen has one or more real people behind it—people with real feelings you can hurt as easily online as you could to their face. You just don’t see it, which shows that we do miss out on a number of social cues when interacting on screen: things like tone, sarcasm, playfulness, hurt feelings—or disapproving frowns from our peers.

A street harasser exploits the lack of a social circle that pressures them to behave decently. Oftentimes this is out of ignorance, not malice, including when the harasser is in the company of others who often are equally unaware that such behavior is unwelcome and uncivil. Many, of course, are in denial and shout catcalls at women despite knowing better—and wouldn’t dare catcall a woman in front of their mothers, for example.

In the digital environment, those external social pressures to behave are often lost, so unless they come to you from the strength you have within, it’s all too easy to slip into behavior you wouldn’t engage in while speaking with someone face to face. Let’s be honest: we’ve all said things to people online at some point or another that we would be ashamed to repeat in person.

From a product perspective, that means we have to rely on mechanisms that either invoke those social mores to encourage civil and fruitful interactions, or outright enforce them. We have to design a simulated social circle of peer pressuring friends into the products we make. Nextdoor did it with form fields that asked follow-up questions. What can your product do?

See the best in people (but be realistic)

People prefer being good and happy over being mean-spirited or awful. You can design your products to encourage the best sides of people, to let them shine in their brilliance, to help them learn and grow while doing their work. But don’t mistake seeing the best in people as a reason not to anticipate harmful behaviors or exploitation of your features.

As product designers we deliberately craft solutions to envisioned problems. We should practice expanding our view to encompass and understand more people and the problems they are experiencing. We should strive to make our work a part of the solution, in ways that scale up to millions of users without harmful side effects.

You’ve read this far. That means you’re eager and ready to think bigger, more holistically, and more empathetically about the work that you do. Armed with these principles, you’re ready to take your product design to the next level.

We can’t wait to see what you’ll create!



This week's sponsor: WEBEDITION

WEBEDITION, the best way to craft and deliver issues of your own online magazine. Start now and build an issue for free.



The Imbalance of Culture Fit

When I started Bearded back in 2008, I’d never run a business before. This lack of experience meant I didn’t know how to do many of the things I’d ultimately have to do as a business owner. One of the things I didn’t know how to do yet? Hiring.

When it came time to start hiring employees, I thought a lot about what the company needed to advance, what skills it was lacking. I asked friends for advice, and introductions to people they knew and trusted who fit the bill. And I asked myself what felt like a natural question: would I want to hang out with this person all day? Because clearly, I would have to.

The trouble with this question is that I like hanging out with people I can talk to easily. One way to make that happen is to hang out with people who know and like the same books, music, movies, and things that I do; people with similar life experiences. It may not surprise you to learn that people who have experienced and enjoy all the same things I do tend to look a whole lot like me.

The dreaded culture fit

This, my friends, is the sneaky, unintentional danger of “culture fit.” And the only way out I’ve found is to recognize it for what it is–an unhelpful bias–and to consciously correct for it.

Besides being discriminatory by unfairly overvaluing people like yourself, hiring for culture fit has at least one other major detriment: it limits perspective.

At Bearded, our main focus is problem solving. Whether those are user experience problems, project management problems, user interface problems, or development problems–that’s what we do every day.

I’ve found that we arrive at better solutions faster when we collaborate during problem solving. Having two or more people hashing out an issue, suggesting new approaches, spotting flaws in each other’s ideas, or catching things another person missed–this is the heart of good collaboration. And it’s not just about having more than one person, it’s about having different perspectives.

Perspective as a skill

A simple shortcut to finding two people who look at the world differently is to find two people with varied life experience–different genders, races, religions, sexual orientations, economic backgrounds, or abilities… these factors all affect how we see and experience the world. This means that different perspectives–different cultures–are an asset. Varied perspective can be viewed, then, as a skill. It’s something you can consciously hire for, in addition to more traditional skills and experience. Having diverse teams better reflects our humanity, and it helps us do better work.

This isn’t just my experience, either.

According to research conducted by Sheen S. Levine and David Stark, groups that included diverse company produced answers to analytical questions that were 58 percent more accurate.

When surrounded by people “like ourselves,” we are easily influenced, more likely to fall for wrong ideas. Diversity prompts better, critical thinking. It contributes to error detection. It keeps us from drifting toward miscalculation.

Smarter groups and better problem-solving sounds good to me. And so does increased innovation. In her article for Scientific American, Katherine W. Phillips draws on decades of research to arrive at some exciting conclusions.

Diversity enhances creativity. It encourages the search for novel information and perspectives, leading to better decision making and problem solving. Diversity can improve the bottom line of companies and lead to unfettered discoveries and breakthrough innovations. Even simply being exposed to diversity can change the way you think.

Phillips isn’t alone in linking diversity to profit. A Morgan Stanley analysis released in May 2016 showed that gender-diverse companies delivered slightly better returns with lower volatility than their more homogenous peers.

Seems like we’d be crazy not to be thinking about building more diverse teams, doesn’t it?

People make the culture

I recently spoke at Web Directions 2016 in Sydney, and was lucky enough to listen to a talk on gender in the tech industry by Aubrey Blanche from Atlassian. Aubrey made a point of how Atlassian has shifted its perspective from finding people who fit their culture, to having a culture defined by its people.

When hiring, this means tossing out the whole “do I want to hang out with them?” question. Instead, I’ve tried to replace that with more specific, more culture-agnostic questions:

  • Are they kind and empathetic?
  • Do they care about their work?
  • Do they have good communication skills?
  • Do they have good self-management skills?

If the answer to each of these questions is yes, then it’s very likely I will want to hang out with them all day, regardless of which movies they like.

As Aubrey points out, we can then focus on values, and leave culture alone. Our values might be that we treat each other well, that we do great work that we care about, and that we are largely independent but communicate well when it’s time to collaborate. Then we can also include this new question:

  • Do they bring a valuable new perspective?

Hiring based on these values will naturally build a culture that is more comfortable with diversity, because the benefits of diversity become more clear in our daily experiences.

Encouragement and change

Now you don’t need me to tell you no one’s perfect. But when it comes to emotional, high-stakes topics like this, you can see people getting caught in the crosshairs of reproach–and that’s scary to watch. Sometimes it can feel as if we’re all one questionable tweet or ill-considered joke away from public humiliation.

That in mind, let me tell you about a time when I was an idiot.

For context, you should know that I’m a white, heterosexual, cisgender male who grew up in a stable, upper-middle-class environment, and now runs his own business. I pretty much tick all the privilege checkboxes.

Last year at a design conference, I was chatting with industry friends. At some point I brought up a meme that I thought was funny, until one of my friends pointed out that it was sexist. And he was right.

Oh crap, I thought: I’m that guy at the conference, I’m a terrible person. Luckily my friend went easy on me. He understood how I missed the underlying sexist assumptions of the joke, and was happy to bring that to my attention without extending the accusation of sexism to me, personally. He effectively reassured me that I could do something bad, while still being a good person. He gave me the option to admit bad behavior and correct it, without hating myself in the process.

And this, I think, may be the key for people in my very privileged position to change. When problems like this come up, when we make missteps and unveil our biases and ignorance, it’s an opportunity for change. But the opportunity is often much more delicate than any of us would like. Successfully navigating a situation like that requires sensitivity and control from both sides.

For the transgressor, being called out on an issue can feel like being attacked, like an indictment. For those of us who aren’t used to being made uncomfortable, that can be shocking. It can be something we might want to quickly deny, to reject that discomfort. But not all discomfort is, in the end, a bad thing. To give others’ feelings and concerns merit–to validate their different perspective–may require us to sit with our own hurt pride or injured self-image for a bit. Something that may help us through these difficult feelings is to remember that there is a big difference between behaviors and identity. Bad behavior is not immutable. Quite the opposite, bad behavior is often a first step toward good behavior, if we can withstand the discomfort of acknowledging it, and muster the strength to change.

It’s tough getting called out for bad behavior, but things aren’t exactly simple on the other side of the confrontation, either. When we’re offended by someone’s ill-considered words or actions, it can cut to the quick. We might feel required to respond with the full force of our anger or outrage. After all, why should we be expected to police our own tone, when we’re responding to words that weren’t prepared with our feelings in mind? It can be hard, but employing our empathy, our compassion—along with our critique—can be the best way to affect the positive change we want to see.

Right now, you’re doing your best. But we can all do better. Recognizing that we’re doing some bad things doesn’t make us bad people. You have the courage to see what you’ve been doing wrong (unintentionally, I know) and fix that. You can admit to having unfair privileges in the world, without it being your fault for having ended up that way. The world is terribly, horribly unfair. It may very well get worse. But when we have sway, even over a tiny part of it, we have to do our best to balance those scales, and make things a little better. I can do more, and so can you. So let’s see if we can’t get to an even better place in 2017, together.

Acknowledgements

Many thanks to Aubrey Blanche and Annette Priest for their thoughtful consideration and feedback on this article. My infinite gratitude goes out, as always, to my editor Rose Weisburd, who helped me find my way even more than usual this time around.



Learning from Lego: A Step Forward in Modular Web Design

With hundreds of frameworks and UI kits, we are now assembling all kinds of content blocks to make web pages. However, such modularity and versatility hasn’t been achieved on the web element level yet. Learning from Lego, we can push modular web design one step forward.

Rethinking the status quo

Modular atomic design has been around for a while. Conceptually, we all love it—web components should be versatile and reusable. We should be able to place them like bricks, interlocking them however we want without worrying about changing any code.

So far, we have been doing it on the content block level—every block occupies a full row, has a consistent width, and is self-contained. We are now able to assemble different blocks to make web pages without having to consider the styles and elements within each block. That’s a great step forward. And it has led to an explosion of frameworks and UI kits, making web page design more modular and also more accessible to the masses.

Achieving similar modularity on the web element level is not as easy. Pattern Lab says we should be able to put UI patterns inside each other like Russian nesting dolls. But thinking about Russian nesting dolls, every layer has its own thickness—the equivalent of padding and margin in web design. When a three-layer doll is put next to a seven-layer doll, the spacing in between is uneven. While it’s not an issue in particular with dolls, on web pages, that could lead to either uneven white space or multilevel CSS overrides.

I’ve been using Bootstrap and Foundation for years, and that’s exactly what would happen when I’d try to write complex layouts within those frameworks—rows nested in columns nested in rows, small elements in larger ones, all with paddings and margins of their own like Russian dolls. Then I would account for the nesting issues, take out the excessive padding on first- and last-child, calculate, override, add comments here and there.

It was not the prettiest thing I could do to my stylesheets, but it was still tolerable. Then I joined Graphiq, a knowledge company delivering data visualizations across more than 700 different topics. Here, content editors are allowed to put in any data they want, in any format they want, to create the best experience possible for their readers. Such flexibility makes sense for the small startup and we have a drag and drop interface to help organize everything from a single data point to infographics and charts, to columns, blocks, and cards. Content editors can also add logic to the layout of the page. Two similar bar charts right next to each other could end up being in quite different HTML structures. As you can imagine, this level of versatility oftentimes results in a styling hell for the designers and developers. Though a very promising solution—CSS Grid Layout—is on the horizon, it hasn’t made its way to Chrome yet. And it might take years for us to fully adapt to a new display attribute. That led me to thinking if we can change the Russian doll mentality, we can take one step further toward modular design with the tools available.

Learning from Lego

To find a better metaphor, I went back to Lego—the epitome of modular atomic design. Turns out we don’t ever need to worry about padding and margin when we “nest” a small Lego structure in a large Lego structure, and then in an even larger Lego structure. In fact, there is no such concept as “nesting” in Lego. All the elements appear to live on the same level, not in multiple layers.

But what does that mean for web design? We have to nest web elements for the semantic structure and for easy selecting. I’m not saying that we should change our HTML structures, but in our stylesheet, we could put spacing only on the lowest-level web elements (or “atoms” to quote atomic design terms) and not the many layers in between.

Take a look at the top of any individual Lego brick. If you see the space around the outside of the pegs as the padding of a web element, and everything inside the padding as the content, you will find that all Lego bricks have a consistent padding surrounding the content, which is exactly half of the gap between elements.

Lego bricks seen from the top, with the pegs representing box content and the padding highlighted to show its consistent width no matter the number of pegs on a brick
No matter how many pegs a brick has, the padding around them is the same as on every other Lego.

And when Lego bricks are placed together, all the elements will have the same gutter in between.

A rectangle of Lego bricks seen from the top, edges touching, each with a thin line between the pegs and the padding
The padding extends from the outer edge of the pegs of one brick to the outer edge of the pegs of the neighboring brick.

No other padding or margin needed; the gaps are naturally formed. All the elements—no matter how deeply they are nested—appear to be on the same level and need no CSS override or adjustment, not even the first- and last-child reset.

Putting it in code, we can make a class that adds the half-gutter spacing, and apply it to all the lowest-level web elements on the page. Then we can remove all the spacing on structural divs like .row and .col.

$gutter: 20px;
.element {
	 padding: $gutter / 2;
}

One tiny tweak to be mindful of is that when the padding is only on .element, the padding between the outermost elements and the parent div would only be half the gutter.

White rectangle representing the complete assembly of bricks in the previous figure with gray rectangles representing the area taken up by pegs, showing that the padding creates full-size gutters between peg areas but only half-size gutter around the periphery.
The periphery is only half the gutter, for now.

We need to add the same padding to the outermost container as well.

Peg areas shown as gray rectangles within a white rectangle representing the complete assembly, edges between bricks shown as black lines, and an extra pink line around the outermost edge showing added padding.
The outermost container with a half gutter added all around.
$gutter: 20px;
.container,
.element {
	padding: $gutter / 2;
}

And that will result in this:

White rectangle with gray rectangles and consistent padding between and around them.
With the added outermost padding, all the padding looks the same.

Think about how many layers of overrides we would need to create this layout with the current rows and columns mentality. The best we can do is probably something like this:

Diagram representing the previous Lego brick rectangle arrangement in rows and columns.
The same layout via rows and columns.

And in code:

See the Pen Complex layout the old way by Samantha Zhang (@moyicat) on CodePen.

With the Lego mentality, the spacing and the code can be much simpler, as shown in the two examples below:

Example with div:

See the Pen Complex layout with div by Samantha Zhang (@moyicat) on CodePen.

Example with Flexbox:

See the Pen Complex layout with flexbox by Samantha Zhang (@moyicat) on CodePen.

More flexible than Lego

Lego is a true one-size-fits-all solution. With Lego, we don’t get to tweak the padding of the bricks according to our projects, and we can’t have different horizontal and vertical padding. Web design offers us much more variation in this area.

Instead of just setting one value as the gutter, we can set four different variables and get more flexible layout this way:

$padding-x: 10px;
$padding-y: 20px;
$padding-outer-x: 40px;
$padding-outer-y: 30px;

.container {
  padding: $padding-outer-y $padding-outer-x;
}
.element {
  padding: ($padding-y / 2) ($padding-x / 2);
}

The result looks like this:

The same arrangement of rectangles representing bricks, but with different values for the x and y padding.
Unlike with physical Lego pieces, we can set different values for the padding.

It’s still modular, but also has varying spaces to create a more dynamic style.

With responsive design, we could also want different spacing for different media queries. We can take our approach one step further and write our logic into a Sass mixin (alternatively you can do it with LESS, too):

@mixin layout ($var) {

  $padding-x: map-get($var, padding-x);
  $padding-y: map-get($var, padding-y);
  $padding-outer-x: map-get($var, padding-outer-x);
  $padding-outer-y: map-get($var, padding-outer-y);

  .container {
    padding: $padding-outer-y $padding-outer-x;
  }
  .element {
    padding: ($padding-y / 2) ($padding-x / 2);
  }
}

Using this mixin, we can plug in different spacing maps to generate CSS rules for different media queries:

// Spacing variables
$spacing: (
  padding-x: 10px,
  padding-y: 20px,
  padding-outer-x: 40px,
  padding-outer-y: 30px
);
$spacing-tablet: (
  padding-x: 5px,
  padding-y: 10px,
  padding-outer-x: 20px,
  padding-outer-y: 15px
);


// Generate default CSS rules
@include layout($spacing);


// Generate CSS rules for tablet view
@media (max-width: 768px) { 
  @include layout($spacing-tablet);
}

And as easy as that, all our elements will now have different spacing in desktop and tablet view.

Live example:

See the Pen Complex layout with mixin and varying gutter by Samantha Zhang (@moyicat) on CodePen.

Discussion

After using this method for almost a year, I’ve encountered a few common questions and edge cases that I’d like to address as well.

Background and borders

When adding backgrounds and borders to the web elements, don’t apply it to the .element div. The background will cover both the content and padding areas of the element, so it will visually break the grid like this:

Gray rectangles with white padding, with one of the rectangles and its padding replaced by a picture.
A background applied to .element breaks the grid.

Instead, apply the background to a child div within the .element div:

<div class="element">
  <div style="background-image:url();"></div>
</div>
Gray rectangles with white padding, with one of the rectangles replaced by a picture.
A child div contains the image so it doesn’t break the grid.

I used this structure in all my examples above.

Similarly, the border goes around the padding in the box model, so we should also apply the border of the element to a child div to maintain the correct spacing.

White rectangle with blue borders around content areas.
As with a background, apply a border to a child div.

Full row elements

Another common issue occurs because we occasionally want full row elements, conceptually like this:

A gray horizontal rectangle with the words Title Here atop a white rectangle holding smaller gray rectangles.
Sometimes we want to break the grid with full row elements.

To style full row elements following the .container and .element structure, we need to make use of negative margin:

.element-full-row {
  margin: 0 (-$padding-outer-x);
  padding: ($padding-y / 2) ($padding-x / 2 + $padding-outer-x);
}

Notice that we need to add back the $padding-outer-x to the padding, so that the content in .element-full-row and the content in .element align.

A gray horizontal rectangle with the words Title Here atop a white rectangle holding smaller gray rectangles and a dashed line to show how the words align on the left with the left-most of the small rectangles.
The content in .element-full-row and the content in .element align.

The code above handles the horizontal spacing, and the same logic can be applied to take over vertical spacing as well (as shown in the example above–the header element takes over the top padding). We can also add a negative margin very easily in our stylesheets.

.element-full-row:first-child {
  margin: (-$padding-outer-y) (-$padding-outer-x) 0;
  padding: ($padding-y / 2 + $padding-outer-y) ($padding-x / 2 + $padding-outer-x) ($padding-y / 2);
}

It can be applied as a standalone rule or be included in the Sass or LESS mixin, then you will never have to worry about them again.

Nesting

The full freedom in nesting is the strong suit of this Lego CSS method. However, there is one kind of nesting we can’t do–we can’t ever nest an .element within an .element. That will create double padding and the whole point of this method would be lost. That’s why we should only apply the .element class to the lowest level web elements (or “atoms” to quote atomic design terms) like a button, input box, text box, image, etc.

Take this very generic comment box as an example.

Generic comment box with title, text area, helper text, and button.

Instead of treating it as one “element,” we need to treat it as a pre-defined group of elements (title, textarea, button, and helper text):

<div class="comment">
  <h3 class="comment-title element">Add a new comment</h3>
  <textarea class="element"></textarea>
  <div class="clearfix">
     <div class="float-left">
       <div class="element">
         <button class="btn-post">Post comment</button>
       </div>
     </div>
     <div class="float-right">
       <div class="helper-text element">
         <i class="icon-question"></i>
           Some HTML is OK.
       </div>
     </div>
   </div>
</div>

Then, we can treat .comment as one reusable component–or in the atomic design context, a “molecule”–that will play well with other reusable components written in the same manner, and can be grouped into higher level HTML structures. And no matter how you organize them, the spacing among them will always be correct.

Varying heights and layouts

In the bulk of this article, we’ve been using the same fitted row example. This may lead some to think that this method only works for elements with defined height and width.

It’s more versatile than that. No matter how elements change in height and width, lazy load, or float around, the Lego-like padding will ensure the same consistent gap between elements.

Pinterest flow layout of 5 columns.
I made a quick Pinterest flow layout to demonstrate how this mentality works with fluid and changing elements.

See the Pen Pinterest Flow by Samantha Zhang (@moyicat) on CodePen.

Maintenance

Some of you might also be worrying about the maintenance cost. Admittedly, it takes time to learn this new method. But once you start to adopt this mentality and write CSS this way, the maintenance becomes extremely simple.

Especially with the layout mixin, all the spacing rules are centralized and controlled by a few groups of variables. A single change in the variables would be carried out to all the elements on the web page automatically.

In comparison, we might have to change padding and margin in 20 different places with the old method, and then we have to test to make sure everything still works. It would be a much more hectic process.

Grid layout

And finally, there is the Grid layout, which supports very complicated layouts and nests much more gracefully than block. You might be thinking this is quite a lot of hard work for a problem that is actually going away.

While many of the issues we talked about in this article might go away with Grid, it might take Grid years to get browser support. And then, it might take a long time for the community to get familiar with the new method and develop best practices and frameworks around it. Like Flex–it’s already supported by most browsers, but it’s far from widely adopted.

And after all, it could take a typical web user a long time to understand Grid and how that works. Similarly, it would require quite a lot of development for us to translate user layout input into good CSS Grid code. The old by-column and by-row method is way easier to understand, and when nesting is not an issue, it could stand as a good solution for websites that allow user configuration.

Conclusion

We started to implement this method at Graphiq in the beginning of 2016. Almost a year in, we love it and believe this is how we should write web layouts in the future. As we refactor each page, we’re deleting hundreds of lines of old CSS code and making the stylesheets way more logical and much easier to read. We also got far fewer layout and spacing bugs compared to all our refactors in the past. Now, no matter how our content editors decide to nest their data points, we’ve got very little to worry about.

From what we’ve seen, this is a real game changer in how we think about and code our layouts. When web components are modular like Lego bricks down to the elements level, they become more versatile and easier to maintain. We believe it’s the next step to take in modular web design. Try it for yourself and it might change the way you write your web pages.



Demystifying Public Speaking

A note from the editors: We’re pleased to share an excerpt from Chapter 1 of Lara Hogan's new book, Demystifying Public Speaking, available now from A Book Apart.

Before you near the stage, before you write the talk, before you even pick a topic, take time to get comfortable with the idea of giving a talk.

You’re reading this because something about public speaking makes your palms sweat. You aren’t alone; when I created an anonymous survey and asked, “What’s your biggest fear about public speaking?” I received over 300 replies. Though the fears all revolved around being vulnerable in front of a large group of people, I was surprised how widely the responses ranged.

See for yourself—I’ve grouped a handful of replies to illustrate the spectrum of fears.

People are worried about their voices:

  • “The sound or pitch of my own voice.”
  • “Voice cracking up—I forget to breathe from the diaphragm and come across sounding nervous and uninformed.”
  • “Forgetting or skipping over what I want to say, heart racing (and getting out of breath quicker), getting tongue-tied.”

People are worried about their bodies:

  • “Being judged for being fat, not on my presentation content.”
  • “In middle school I got something in my eye during a class presentation, and my eyes would not stop watering. I’m terrified it will happen again.”
  • “Needing to pee during the speech!”
  • “Falling on stage.”
  • “People judging my appearance, whether I’m dressed appropriately.”

People are worried about technical or wardrobe malfunctions:

  • “Problems connecting laptop to projector.”
  • “Making stupid coding mistakes during live coding.”
  • “Open pants zipper (because it’s happened).”

People are worried about being wrong and being challenged:

  • “Elegantly explaining something that is actually wrong.”
  • “Showing that I’m ignorant about something I thought I was knowledgeable about.”
  • “Getting a question I can’t even begin to answer.”
  • “Being wrong and being called out on stage during Q&A.”
  • “Getting heckled.”
  • “Vocal skeptics or doubters.”

People are worried about their performance:

  • “Not being impressive enough.”
  • “That everything I say becomes so messy anyone can refute it.”
  • “Since I’m not a native English speaker, my biggest fear is not making any sense when speaking.”
  • “That no one learns anything, and the audience is starkly aware of it.”
  • “Being exposed for the fraud I have always felt like.”

Phew. Given the potential for these moments of total—human—disaster, why should we even bother embarking on this journey toward the stage?

To start, public speaking (or put another way, broadcasting your abilities and knowledge) has definite career benefits. You grow your network by meeting attendees and other speakers, and you gain documented leadership experience in your subject area. People looking to hire, collaborate with, or fund someone with your topic expertise will be able to find you, see proof of your work, and have a sense of the new perspective you’ll bring to future projects.

Those professional benefits are huge—but in my experience, the personal benefits are even more substantial. Giving a talk grows so many skill sets: crafting a succinct way to share information, reading an audience, and eloquently handling an adrenaline-heavy moment. You’ll prove something to yourself by overcoming a major fear, and you should take pride in knowing you taught a large group of people something new that will hopefully make their work or lives easier. Public speaking experience boosts a lot of knock-on benefits too, like a stronger visa application or more confidence in your everyday spotlight moments, like a standup meeting, code review, design critique, or other project presentations.

No matter the impetus, trying your hand at public speaking is a brave act. While it’s a different challenge for everyone, we do have a few tools to help tackle our fears.

Flip that fear around

First, give yourself permission to be anxious. Even renowned speaker and industry veteran Eric Meyer still gets nervous giving talks, as detailed in his article “The Stages of Fear”:

A hundred public talks or more, and it’s still not easy. I’m not sure it ever will be easy. I’m not sure it ever should be easy. […] Every speaker I know feels pretty much exactly the same. We don’t all get the same nervous tics, but we all get nervous. We struggle with our fears and doubts. We all feel like we have no idea what we’re doing.

Being nervous is totally normal. Consider what you’re juggling: sharing information, entertaining the audience, and guessing (or worrying over) how you’re being perceived. Keep in mind, though, being nervous is not a sign you’ll do poorly. Public speaking isn’t an everyday context, and you may still get butterflies even as you gain experience and improve your speaking game.

But if you can’t coolly eliminate all your fears and nerves like some stoic robot, what can you do? One tactic is to try reframing your anxiety in a positive or motivating way, as designer Lea Alcantara suggests:

Instead of worrying, flip your perception of nerves as an indication you care as opposed to dread of failure. There is no shame in caring deeply about a subject and what people think about your talk.

Caring feels a lot more approachable than dreading failure, and it gives you a way through: use your body’s natural reaction to stress to improve your talk. Invest that energy into more research of your topic, more practice, and more feedback-gathering—all acts within your control. Let your nerves become part of the process—or try accepting that—and just maybe, in time, they’ll feel more useful than disastrous.

What makes you tick?

To flip your fears into motivations, let’s dip into what makes you tick. Understanding who you are will help you determine where to invest that extra energy as you make your way toward the stage. Once you begin to name what scares you, what comforts you, and what drives you, you’ll be able to home in on which talk format, topic, venue type, and preparation style will calm those fears and build your excitement.

To get you started, think through these:

  • What makes you most excited when you think about public speaking? What do you want to get out of it?
  • What makes you most nervous when you think about public speaking?
  • What scenarios do you want to avoid?
  • What size audience do you think you might be most comfortable speaking to? Why?
  • Whose feedback matters most to you on your talk or presentation style?
  • What would you want people to take away from your talk?
  • What do you want to happen for you or your career after your talk? (Examples: someone offers you your dream project, someone you admire asks for your advice, people shower you with praise, you get right back to work, etc.)

That’s a lot of introspection, but it’s worth it. As we move through this book, we’ll go through the varied paths and aspects of public speaking, and your answers will guide you to the right fit for you. For instance, if you’re afraid of seeing a sea of strange faces before you, maybe a smaller meetup is the best venue to get in some practice. If you’re afraid of saying something patently false onstage, then pick a topic like a case study from your work that you know inside and out, and practice your Q&A session with friends who can help you fact-check your content. Or, if you’re excited to teach people skills they can immediately put into practice, opt for a workshop format and give hands-on help to folks. Whatever your goals and style, you can find a speaking opportunity that resonates with you.

Move beyond the “rules”

You’ve heard the adages: don’t say “um,” don’t say “uh.” Excise “like” with extreme prejudice. Don’t use bullets on your slides. Never, ever read from your notes. Some folks have an archetype of what a great speaker sounds like, or an audience size that feels real, or this idea you need to give a deeply technical or novel talk for it to count.

But you know what? If I can say one thing in this book about giving talks, it’s do what works for you. Truly.

Of course, it’s hard to move past the impulse to embrace rules—it’s reassuring to think we have a straightforward map to success. We try to mimic speakers who capture our attention or those whom our peers praise. We hold up examples of “ideal” presentation styles, and we instruct new speakers to follow suit. We see a lot of the same people, and we can’t help but absorb a lot of the same opinions on what a good speaker looks like or sounds like.

Just because we’ve built a system, it doesn’t mean it’s right. What we need to see represented onstage is a spectrum of speakers with different insights and ways to teach us about them. Your voice is valuable, and your own. If you choose to share it, we will all certainly be the better for it.

Public speaking is a journey that, like any other, involves practice and time to make you feel comfortable and successful. Take heart from Tiffani Jones Brown:

The worst case scenario is your talk flops—in which case you’ll be stronger for it. The likelier scenario is you’ll give a couple decent talks, followed by better ones, followed by even better ones, until you give one that really makes a difference.

I don’t want to set out any rules in this book—forget them. What I do hope is to help you forge your own path, so you make your way to that talk that makes a difference. Let’s get started.

Want to read more?

This excerpt from Demystifying Public Speaking will help you get started. Order the full copy today, as well as other excellent titles from A Book Apart.

Demystifying Public Speaking by Lara Hogan

 



This week's sponsor: ZARGET

ZARGET: Analytics Tool for designers. Capture exactly how users experience your website. Settle design debates with data.



Managing Ego

A note from the editors: This is Part 2 of the series entitled, “Defeating Workplace Drama with Emotional Intelligence”.

We’re in an industry where we regularly hear that our ideas are bad. We can get yelled at for overlooking something, even if we didn’t know about it, and we frequently encounter threats to our ego that can turn any one of us into an anxious and irrational coworker.

Minimizing our exposure to ego-damaging situations can be valuable in preventing anxiety, but that’s sometimes beyond our control. Unfortunately, when threats can’t be controlled, confidence is the next thing to take a hit. Professional and personal self-worth may seem vulnerable, but they can also be reinforced and strengthened far in advance.

Client drama, ground zero

I shrunk in my chair as a client technical contact listed off everything he hated about the site I had just built. The list was not short, nor was it constructive. When it came time for him to make his recommendations, I went on the offensive and launched into my own opinions on how terrible and impossible his ideas were. By the end of the phone call, everyone was on edge and I was left with one desperate question: What just happened?

I found out the next day that the website I built was originally supposed to be an internal initiative, handled by the technical contact who had berated me. In short, his ego was bruised—and by the end of the phone call, my ego was bruised too. This brought out the worst in each of us. The result was a phone call full of drama that shall live on in infamy.

There were a few things wrong with that conversation. First, the technical contact clearly felt threatened by my website. But my history with this guy showed me that he felt threatened by most ideas we brought to him, so we also had to give some thought to where to draw the line with validating him on this. We should have employed a long-term strategy for strengthening that relationship by validating him at other times. Lastly, there are things I could have done to guard myself against irrationality and drama when that conversation turned south.

In short, everything went wrong in this scenario. That’s bad for me, but good for you, because it means we can learn a lot from looking at it. Let’s dig in.

Validating self esteem to prevent anxiety

Everyone responds to external feedback and affirmation—some more than others. So how do we tailor our feedback to avoid causing undue anxiety?

When you notice someone suddenly get worked up about something, go over what just happened. You probably introduced a threat. Did you propose a new idea? Did you point out a flaw in their idea? (Ideas are tied very closely to self esteem.) What was the idea? You’ve just pinpointed where their self esteem comes from.

Just like web professionals usually draw self esteem from the things that got them the job in the first place, marketing and account people do the same thing. Marketing people may prize their own creative ideas in a campaign, or their analytical skills when critiquing a campaign; account people often value their communication skills and ability to read people. When these skills are called into question, it produces anxiety, which can quickly lead to drama.

Think about that marketing person who can’t accept any creative idea as-is—who feels the need to make revisions to any idea that comes in. Creativity is the source of this person’s self esteem, so pushing back on those ideas without first validating them will introduce threat and result in anxiety.

What about that developer who won’t accept other people’s suggestions, and shoots down others’ ideas as impossible or too impractical? Problem solving and technical know-how are the sources of this person’s self esteem, and self esteem must be boosted by validating those strengths to get anywhere in a discussion of the merits of said ideas.

Ok, great, so we know where their self esteem is coming from. How do we validate these traits to prevent drama?

Consider the conversation I had with the client’s technical contact. When the technical contact began listing everything he hated about my site, I should have noticed that his own ideas were invalidated by the proposal of my ideas, which were being presented in the site I designed and built.

Rather than immediately protest (producing more threat), I should have asked questions related to his expertise with the client brand and business goals. I could have asked for help and affirmed his problem-solving ability (boosting self esteem and lowering threat) before re-asserting my own ideas. Had I taken this approach, there’s a good chance I could have learned something about the client in addition to calming down their technical contact.

Simply acknowledging others’ ideas and the thought that went into them can go a long way in validating sources of self esteem and quelling anxiety in the workplace.

When validation is not enough

There are times when there is such an emotional deficit created by a blow to the ego (possibly to an already-low self esteem) that no amount of validation will fix it. Dealing with a vulnerable or shattered self esteem can be difficult, and fixing it can be impossible. In those cases, no level of threat is tolerable and no level of self esteem boosting is sufficient.

Going back to my conversation with the client technical contact, what if he remained unsatisfied until he had the project back on his plate? Obviously, this is not a solution that’s good for either the agency, who needs the work, or the client, who determined that the agency was a better fit than their internal team.

In these situations, preventing or calming anxiety may be impossible because the problem is likely much bigger than the conversation at hand. It’s hard to apply a short-term solution to a long-term problem. In those cases, there are two things to do: minimize damage, and employ a long-term strategy to strengthen the relationship.

Minimizing damage means avoiding triggers and being as understanding as you can to the other person’s plight without sacrificing the project. If the other party feels that their ideas are being invalidated, it’s a sign that they feel that others aren’t taking their contributions seriously. (It may or may not be true in reality, but that’s how they feel.) That’s a pretty rough place to be no matter who you are. In that case, treat their contributions respectfully and be understanding when they get defensive about them.

Employing a my-way-or-the-highway authoritarian approach is the opposite of what we’re going for. This approach increases threat and can lead to a lot of ugly politics, with people going behind your back to gain support for their cause because they feel that any ideas brought to you are being invalidated. There are some situations where this is the only way forward, but those situations are few and far between—as well as rough and aggravating. Only go this route if you’ve exhausted all other options.

Read on for a long-term strategy to strengthen the relationship.

Using self esteem to build long-term relationships

As web professionals, we’re in the idea business—but so are the marketing people we often deal with. Those marketing folks will probably react poorly when their self esteem is threatened by conflicting and challenging ideas; but they usually react well when treated with deference and asked to explain their ideas and contribute their strengths. While this can be done on a case-by-case basis to prevent anxiety, it can also be done proactively to build better relationships with clients, coworkers, and others.

Once you’ve identified the source of a person’s self esteem, start deferring to them on that subject. Treat them as an expert on that subject. (In many cases, they probably are an expert on that subject.) Be open to their ideas and suggestions, and willing to integrate them into your own.

This process can take time, depending on the emotional deficit they begin with and your flexibility in welcoming their ideas. But over time, the beneficiary of your emotional toil will begin to see you as an ally and partner. This is a very good spot to be in.

They keyword here is intentionality. This process cannot happen on a happy accident—it takes work with planning and strategy. Obviously, the mental energy required for this means you won’t be able to do it for everyone you work with. Give some thought to which of your working relationships have the most strategic importance and which could most benefit from additional trust and respect. Chances are a few will pop out at you.

Being intentional about boosting the self esteem of your coworkers and clients not only makes them easier to work with, but creates relational equity that can be cashed in at a later time for deference, respect, and allegiance. Remember, the less you challenge things in a relationship, the more the other person will listen when you do. Though it takes time, it will make your job way easier in the long run.

Guarding yourself against anxiety

I wish I could say I didn’t personally need the advice in this section—but I do. There are times when we all do. Let’s be honest: we’ve all been that angry client technical contact at some point, and it certainly doesn’t help our careers. The two things we apply to others can also be applied to ourselves to prevent anxiety: we can reduce threat, and we can boost self esteem.

At first glance, it may seem impossible to reduce threat coming from others. We can’t just ask everyone to be nicer to our egos. But some perspective can go a long way in reducing perceived threat.

In the example above, I reacted poorly because the client’s technical contact got mad at me on the phone. He challenged all of my ideas and was doing all he could to dismiss them entirely. What I didn’t realize until much later was that he wasn’t mad at me, or my ideas—he was mad at an unstated problem. Maybe he had been burned by another agency’s incompetent development team in the past. Maybe he had major concerns that weren’t being heeded by his company’s marketing team. Ultimately, I don’t know what the problem was, but I realize now that he probably would have been mad no matter what or who we put in front of him.

What I find is that angry people aren’t always mad at me—many times, they’re mad at the problem. They’re challenging my ideas not because they doubt them, but because they want to make sure that they’re the best solution to the problem. When viewed this way, it’s a lot easier to avoid being defensive, because it’s not me versus you—it’s me and you versus the problem. It’s not easy to counteract that fight-or-flight response that gets triggered when people start challenging your ideas, but forcing yourself to do so usually goes a long way in helping to solve the problem without escalating into drama.

Having a healthy view of yourself and your capabilities can also guard against anxiety. It’s very important to have a self-image independent of anything else going on around you. There’s one big difference between healthy self esteem and unhealthy pride: social comparison. Healthy self esteem is knowing that you’re good at something and being content with that; unhealthy pride is knowing that you’re better than someone else.

Being better than someone else is actually a rather tenuous place to be. Comparing yourself to a moving target—which may be moving past you—usually results in you trying to hammer the target down into a place where you can move past it, either by putting the other person down or filling yourself with false confidence in your own ability. This is never a good thing.

If a discussion on how to solve a problem devolves into a binary battle of opinions with a winner and a loser, there are no winners because the original problem becomes the loser. It doesn’t matter if you beat the other guy if the solution suffers for it. Instead of seeking to be a winner, you should seek to be a problem-solver. In the web industry, ideas don’t mean anything unless they solve real-world problems. It is always worth giving up some or even all of your idea if it means improving the solution.

Recognizing the roots of anxiety

Workplace drama and the anxiety beneath its surface, far from being unpredictable and random occurrences, are often the result of deeply held fears and insecurities. Avoiding an unmitigated drama disaster means dealing with underlying issues like self esteem. It can be difficult to navigate these waters, and even more so to turn the tides and produce happier relationships—but the benefits far outweigh the costs.



Accessibility Whack-A-Mole

I don’t believe in perfection. Perfection is the opiate of the design community.

Designers sometimes like to say that design is about problem-solving. But defining design as problem-solving is of course itself problematic, which is perhaps nowhere more evident than in the realm of accessibility. After all, problems don’t come in neat black-and-white boxes—they’re inextricably tangled up with other problems and needs. That’s what makes design so fascinating: experimentation, compromise, and the thrill of chasing an elusive sweet spot.

Having said that, deep down I’m a closet idealist. I want everything to work well for everyone, and that’s what drives my obsession with accessibility.

Whose accessibility, though?

Accessibility doesn’t just involve improving access for people with visual, auditory, physical, speech, cognitive, language, learning, and neurological difficulties—it impacts us all. Remember that in addition to those permanently affected, many more people experience temporary difficulties because of injury or environmental effects. Accessibility isn’t a niche issue; it’s an everyone issue.

There are lots of helpful accessibility guidelines in Web Content Accessibility Guidelines (WCAG) 2.0, but although the W3C is working to better meet the complex needs of neurodiverse users, there are no easy solutions. How do we deal with accessibility needs for which there are no definitive answers? And what if a fix for one group of people breaks things for another group?

That’s a big question, and it’s close to my heart. I’m dyslexic, and one of the recommendations for reducing visual stress that I’ve found tremendously helpful is low contrast between text and background color. This, though, often means failing to meet accessibility requirements for people who are visually impaired. Once you start really looking, you notice accessibility conflicts large and small cropping up everywhere. Consider:

  • Designing for one-handed mobile use raises problems because right-handedness is the default—but 10 percent of the population is left handed.
  • Giving users a magnified detailed view on hover can create a mobile hover trap that obscures other content.
  • Links must use something other than color to denote their “linkyness.” Underlines are used most often and are easily understood, but they can interfere with descenders and make it harder for people to recognize word shapes.

You might assume that people experiencing temporary or long-term impairment would avail themselves of the same browser accessibility features—but you’d be wrong. Users with minor or infrequent difficulties may not have even discovered those workarounds.

With every change we make, we need to continually check that it doesn’t impair someone else’s experience. To drive this point home, let me tell you a story about fonts.

A new font for a new brand

At Wellcome, we were simultaneously developing a new brand and redesigning our website. The new brand needed to reflect the amazing stuff we do at Wellcome, a large charitable organization that supports scientists and researchers. We wanted to paint a picture of an energetic organization that seeks new talent and represents broad contemporary research. And, of course, we had to do all of this without compromising accessibility. How could we best approach a rebrand through the lens of inclusivity?

To that end, we decided to make our design process as transparent as possible. Design is not a dark art; it’s a series of decisions. Sharing early and often brings the benefit of feedback and allows us to see work from different perspectives. It also offers the opportunity to document and communicate design decisions.

When we started showing people the new website, some of them had very specific feedback about the typeface we had chosen. That’s when we learned that our new headline font, Progress Two, might be less than ideal for readers with dyslexia. My heart sank. As a fellow dyslexic, I felt like I was letting my side down.

My entire career had been geared toward fostering accessibility, legibility, and readability. I’d been working on the site redevelopment for over a year. With clarity and simplicity as our guiding principles, we were binning jargon, tiny unreadable text, and decorative molecules.

And now this. Were we really going to choose a typeface that undid all of our hard work and made it difficult for some people to read? After a brief panic, I got down to some research.

So what makes type legible?

The short answer is: there is no right answer. A baffling and often contradictory range of research papers exists, as do, I discovered, companies trying to sell “reasonably priced” (read: extortionate) solutions that don’t necessarily solve anything.

Thomas Bohm offers a helpful overview of characters that are easily misrecognized, and the British Dyslexia Association (BDA) has published a list of guidelines for dyslexia-friendly type. The BDA guidelines on letterforms pretty much ruled out all of the fonts on our short list. Even popular faces like Arial and Helvetica fail to tick all the boxes on the BDA list, although familiar sans serifs do tend to test well, according to some studies (PDF).

And it’s not just dyslexia that is sensitive to typography; we recently had a usability testing participant who explained that some people on the autism spectrum struggle with certain fonts, too. And therein lies the problem: there’s a great deal of diversity within neurodiversity. What works for me doesn’t work for everyone with dyslexia; not everyone on the autism spectrum gives a flip about fonts, but some really do.

At first my research discouraged and overwhelmed me. The nice thing about guidelines, though, is that they give you a place to start.

Progress

Some people find fonts specifically designed for dyslexia helpful, but there is no one-size-fits-all solution. Personally, I find a font like Open Dyslexic tricky to read; since our goal was to be as inclusive as possible, we ultimately decided that Open Dyslexic wasn’t the right choice for Wellcome. The most practical (and universal) approach would be to build a standards-compliant site that would allow users to override styles with their own preferred fonts and/or colors. And indeed, users should always be able to override styles. But although customization is great if you know what works for you, in my experience (as someone who was diagnosed with dyslexia quite late), I didn’t always know why something was hard, let alone what might help. I wanted to see if there was more we could do for our users.

Mariane Dear, our senior graphic designer, was already negotiating with the type designer (Gareth Hague of Alias) about modifying some aspects of Progress Two. What if we could incorporate some of the BDA’s recommendations? What if we could create something that felt unique and memorable, but was also more dyslexia friendly? That would be cool. So that’s what we set out to do.

Welcome, Wellcome Bold

When I first saw Progress Two, I wasn’t particularly keen on it—but I had to admit it met the confident, energetic aspirations of our rebranding project. And even though I didn’t initially love it, I think our new customized version, Wellcome Bold, has “grown up” without losing its unique personality. I’ve come to love what it has evolved into.

We used the BDA’s checklist as a starting point to analyze and address the legibility of the letterforms and how they might be improved.

Illusion number 1


If uppercase I, lowercase l, and numeral 1 look too similar, some readers might get confused. We found that the capital I and lowercase l of Progress Two weren’t distinct enough, so Hague added a little hook to the bottom of the l.

Illustration showing examples of capital ‘I’, lowercase ‘l’, and numeral ‘1’
Capital I, lowercase l, and numeral 1 show how Progress Two metamorphosed into Wellcome Bold. (All glyph illustrations by Eleanor Ratliff.)

Modern modem

In some typefaces, particularly if not set well, r and n can run together to appear to form an mmodern may be read as modem, for example. Breaking the flow between the two shapes differentiates them better.

Illustration showing how lowercase ‘r’ and ‘n’ were modified to prevent the two glyphs from running together when set next to each other
From Progress Two to Wellcome Bold: lowercase r and n were tweaked to prevent the two glyphs from running together when set next to each other.

Openings

Counters are the openings in the middle of letterforms. Generally speaking, the bigger the counters, the more distinct the letters.

Illustration showing counters in ‘b’, ‘a’, ‘e’, ‘o’, and ‘q’ in Wellcome Bold
Highlighted counters in Wellcome Bold’s lowercase b, a, e, o, and q.

Mirroring

Because some people with dyslexia perceive letters as flipped or mirrored, the BDA recommends that b and d, and p and q, be easily distinguishable.

Illustration showing how lowercase ‘d’ and ‘b’ were modified to make them more easily distinguishable in Wellcome Bold
Lowercase d and b were modified to make them more easily distinguishable in Wellcome Bold.

Word shapes

Most readers don’t read letter by letter, but by organizing letterforms into familiar word shapes. We modified Progress Two not just to make things easier for readers who are dyslexic; we did it as part of a wider inclusive design process. We wanted to make accessibility a central part of our design principles so that we could create an easier experience for everyone.

Test, test, and test again

In the course of our usability testing, we had the good fortune to be able to work with participants with accessibility needs in each round, including individuals with dyslexia, those on the autism spectrum, and users of screen readers.

Once we started introducing changes, we were anxious to make sure we were heading in the right direction. Nancy Willacy, our lead user experience practitioner, suggested that a good way to uncover any urgent issues would be to ask a large number of respondents to participate in a survey. The media team helped us out by tweeting our survey to a number of charities focused on dyslexia, dyspraxia, autism, and ADHD, and the charities were kind enough to retweet us to their followers.

Although we realize that our test was of the quick-and-dirty variety, we got no feedback indicating any critical issues, which reassured us that we were probably on the right track. Respondents to the survey had a slight preference for the adjusted version of Progress Two over Helvetica (we chose a familiar sans serif as a baseline); the unadjusted version came in last.

Anyone can do it

Even if you don’t have a friendly type designer you can collaborate with to tailor your chosen fonts, you can still do a lot to be typographically accessible.

Type

When selecting a typeface, look for letterforms that are clear and distinct.

  • Look closely and critically. Keeping the checklists we’ve mentioned in mind, watch for details that could potentially trip readers up, like shapes that aren’t well differentiated enough or counters that are too closed.
  • To serif or not to serif? Some research has shown that sans serifs are easier to read on screen, since, especially at lower resolutions, serifs can get muddy, make shapes less distinct, or even disappear altogether. If your existing brand includes a typeface with fine serifs or ornamental details, use it sparingly and make sure you test it with a range of users and devices.
  • Use bold for emphasis. Some research has shown that italics and all-caps text reduce reading speed. Try using bold for emphasis instead.
  • Underline with care. Underlines are great for links, but a standard text-decoration underline obscures descenders. In the future, the text-decoration-skip property may be able to help with that; in the meantime, consider alternatives to the default.

Space

Think carefully about spaces between, around, and within letterforms and clusters of words.

Words

The words you use are just as important as what you do with them.

  • Keep it short. Avoid long sentences. Keep headings clear and concise.
  • Avoid jargon. Write for your audience and cut the jargon unless it’s absolutely necessary. Acronyms and academic terms that might be appropriate for a team of specialists would be totally out of place in a more general article, for example.

So everything’s fixed, right?

Nope.

There is no perfect typeface. Although we worked hard to improve the experience of the Wellcome site, some people will still struggle with our customized headline font, and with the Helvetica, Arial, sans-serif font stack we’re using for body text. However hard we try, some people may need to override defaults and choose the fonts and colors that work best for them. We can respect that by building sites that allow modification without breaking.

Pragmatic perfection

The trouble with expecting perfection in one go is that it can be tempting to take the safe route, to go with the tried and tested. But giving ourselves room to test and refine also gives us the freedom to take risks and try original approaches.

Putting ourselves out there can feel uncomfortable, but Wellcome wants to fund researchers that have the big ideas and the chutzpah to take big risks. So shouldn’t those of us building the site be willing to do the same? Yes, maybe we’ll make mistakes, but we’ll learn from them. If we had chosen a safe typeface for our headline font, we wouldn’t be having these conversations; we wouldn’t have done the research that led us to make changes; we wouldn’t discover new issues that failed to come up in any of our research.

The process sparked much debate at Wellcome, which opened doors to some intriguing opportunities. In the future, I won’t be so reticent about daring to try new things.

Additional resources



This week's sponsor: ENVATO ELEMENTS

ENVATO ELEMENTS, the only subscription made with designers in mind. 9000+ quality fonts, graphics, templates and more. Get started today.



This week's sponsor: O’REILLY DESIGN CONFERENCE

O’REILLY DESIGN CONFERENCE - get the skills and insights you need to design the products of the future. Save 20% with code ALIST





 
 
 
 
 

Affiliates

i digitalemotion Photoshop Tutorials
Tutorial Man Wallpaper Stock  More

Resources