Subscribe: A List Apart
http://alistapart.com/feed/rss.xml
Added By: Feedage Forager Feedage Grade A rated
Language: English
Tags:
accessibility  content  design  experience  idea  it’s  make  new  people  performance  site  time  user  users  web  work 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: A List Apart

A List Apart: The Full Feed



Articles for people who make web sites.



Published: 2016-02-11T15:00:00+00:00

 



This week's sponsor: Hotjar

2017-02-20T05:01:00+00:00

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

(image)



I Don’t Need Help

2017-02-07T16:00:00+00:00

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: [...]



This week's sponsor: Hired

2017-02-06T05:01:00+00:00

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

(image)



Considering How We Use HTTP/2

2017-02-02T15:00:00+00:00

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: 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. 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. 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). 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 i[...]



Using HTTP/2 Responsibly: Adapting for Users

2017-02-02T15:00:00+00:00

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 compi[...]



This week's sponsor: FullStory

2017-01-30T05:01:00+00:00

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

(image)



Gaming the System…and Winning

2017-01-24T15:00:00+00:00

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. Bartl[...]



This week's sponsor: GatherContent

2017-01-23T05:01:00+00:00

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

(image)



Guerrilla Innovation

2017-01-17T15:00:00+00:00

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 [...]



A Dao of Product Design

2017-01-12T15:00:00+00:00

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 [...]



This week's sponsor: WEBEDITION

2017-01-09T23:19:00+00:00

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

(image)



The Imbalance of Culture Fit

2017-01-03T15:00:00+00:00

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[...]



Learning from Lego: A Step Forward in Modular Web Design

2016-12-22T15:00:00+00:00

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[...]



Demystifying Public Speaking

2016-12-15T15:00:00+00:00

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 mee[...]



This week's sponsor: ZARGET

2016-12-14T17:36:00+00:00

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

(image)



Managing Ego

2016-12-13T15:00:00+00:00

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[...]



Accessibility Whack-A-Mole

2016-12-06T15:00:00+00:00

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.[...]



This week's sponsor: ENVATO ELEMENTS

2016-12-05T05:01:00+00:00

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

(image)



This week's sponsor: O’REILLY DESIGN CONFERENCE

2016-11-28T05:01:00+00:00

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

(image)



Insisting on Core Development Principles

2016-11-22T15:00:00+00:00

The web community talks a lot about best practices in design and development: methodologies that are key to reaching and retaining users, considerate design habits, and areas that we as a community should focus on. But let’s be honest—there are a lot of areas to focus on. We need to put users first, content first, and mobile first. We need to design for accessibility, performance, and empathy. We need to tune and test our work across many devices and browsers. Our content needs to grab user attention, speak inclusively, and employ appropriate keywords for SEO optimization. We should write semantic markup and comment our code for the developers who come after us. Along with the web landscape, the expectations for our work have matured significantly over the last couple of decades. It’s a lot to keep track of, whether you’ve been working on the web for 20 years or only 20 months. If those expectations feel daunting to those of us who live and breathe web development every day, imagine how foreign all of these concepts are for the clients who hire us to build a site or an app. They rely on us to be the experts who prioritize these best practices. But time and again, we fail our clients. I’ve been working closely with development vendor partners and other industry professionals for a number of years. As I speak with development shops and ask about their code standards, workflows, and methods for maintaining consistency and best practices across distributed development teams, I’m continually astonished to hear that often, most of the best practices I listed in the first paragraph are not part of any development project unless the client specifically asks for them. Think about that. Development shops are relying on the communications team at a finance agency to know that they should request their code be optimized for performance or accessibility. I’m going to go out on a limb here and say that shouldn’t be the client’s job. We’re the experts; we understand web strategy and best practices—and it’s time we act like it. It’s time for us to stop talking about each of these principles in a blue-sky way and start implementing them as our core practices. Every time. By default. Whether you work in an internal dev shop or for outside clients, you likely have clients whose focus is on achieving business goals. Clients come to you, the technical expert, to help them achieve their business goals in the best possible way. They may know a bit of web jargon that they can use to get the conversation started, but often they will focus on the superficial elements of the project. Just about every client will worry more about their hero images and color palette than about any other piece of their project. That’s not going to change. That’s okay. It’s okay because they are not the web experts. That’s not their job. That’s your job. If I want to build a house, I’m going to hire experts to design and build that house. I will have to rely on architects, builders, and contractors to know what material to use for the foundation, where to construct load-bearing walls, and where to put the plumbing and electricity. I don’t know the building codes and requirements to ensure that my house will withstand a storm. I don’t even know what questions I would need to ask to find out. I need to rely on experts to design and build a structure that won’t fall down—and then I’ll spend my time picking out paint colors and finding a rug to tie the room together. This analogy applies perfectly[...]