Оценка на читателите: / 9
Слаба статияОтлична статия 

Новини от света на уеб дизайна и СЕО

Представям Ви синдикирани новини от няколко от водещите сайтове в областта на уеб дизайна и СЕО - оптимизирането за търсачки.

A List Apart: The Full Feed
Articles for people who make web sites.
  • Discovery on a Budget: Part II

    Welcome to the second installment of the “Discovery on a Budget” series, in which we explore how to conduct effective discovery research when there is no existing data to comb through, no stakeholders to interview, and no slush fund to draw upon. In part 1 of this series, we discussed how it is helpful to articulate what you know (and what you assume) in the form of a problem hypothesis. We also covered strategies for conducting one of the most affordable and effective research methods: user interviews. In part 2 we will discuss when it’s beneficial to introduce a second, competing problem hypothesis to test against the first. We will also discuss the benefits of launching a “fake-door” and how to conduct an A/B test when you have little to no traffic.

    A quick recap

    In part 1 I conducted the first round of discovery research for my budget-conscious (and fictitious!) startup, Candor Network. The original goal for Candor Network was to provide a non-addictive social media platform that users would pay for directly. I articulated that goal in the form of a problem hypothesis:

    Because their business model relies on advertising, social media tools like Facebook are deliberately designed to “hook” users and make them addicted to the service. Users are unhappy with this and would rather have a healthier relationship with social media tools. They would be willing to pay for a social media service that was designed with mental health in mind.

    Also in part 1, I took extra care to document the assumptions that went into creating this hypothesis. They were:

    • Users feel that social media sites like Facebook are addictive.
    • Users don’t like to be addicted to social media.
    • Users would be willing to pay for a non-addictive Facebook replacement.

    For the first round of research, I chose to conduct user interviews because it is a research method that is adaptable, effective, and—above all—affordable. I recruited participants from Facebook, taking care to document the bias of using a convenience sampling method. I carefully crafted my interview protocol, and used a number of strategies to keep my participants talking. Now it is time to review the data and analyze the results.

    Analyze the data

    When we conduct discovery research, we look for data that can help us either affirm or reject the assumptions we made in our problem hypothesis. Regardless of what research method you choose, it’s critical that you set aside the time to objectively review and analyze the results.

    In practice, analyzing interview data involves creating transcriptions of the interviews and then reading them many, many times. Each time you read through the transcripts, you highlight and label sentences or sections that seem relevant or important to your research question. You can use products like NVivo, HyperRESEARCH, or any other qualitative analysis tool to help facilitate this process. Or, if you are on a pretty strict budget, you can simply use Google Sheets to keep track of relevant sections in one column and labels in another.

    Screenshot of a spreadsheet with quotes about Facebook usage
    Screenshot of my interview analysis in Google Sheets

    For my project, I specifically looked for data that would show whether my participants felt Facebook was addicting and whether that was a bad thing, and if they’d be willing to pay for an alternative. Here’s how that analysis played out:

    Assumption 1: Users feel that social media sites like Facebook are addictive

    Facebook has a weird, hypnotizing effect on my brain. I keep scrolling and scrolling and then I like wake up and think, ‘where have I been? why am I spending my time on this?’
    interview participant

    Overwhelmingly, my data affirms this assumption. All of my participants (eleven out of eleven) mentioned Facebook being addictive in some way.

    Assumption 2: Users don’t like to be addicted to social media

    I know a lot of people who spend a lot of time on Facebook, but I think I manage it pretty well.
    interview participant

    This assumption turned out to be a little more tricky to affirm or reject. While all of my participants described Facebook as addictive, many of them (eight out of eleven) expressed that “it wasn’t so bad” or that they felt like they were less addicted than the average Facebook user.

    Assumption 3: Users would be willing to pay for a non-addictive Facebook replacement

    No, I wouldn’t pay for that. I mean, why would I pay for something I don’t think I should use so much anyway?
    interview participant

    Unfortunately for my project, I can’t readily affirm this assumption. Four participants told me they would flat-out never pay for a social media service, four participants said they would be interested in trying a paid-for “non-addictive Facebook,” and three participants said they would only try it if it became really popular and everyone else was using it.

    One unexpected result: “It’s super creepy”

    I don’t like that they are really targeting me with those ads. It’s super creepy.
    interview participant

    In reviewing the interview transcripts, I came across one unexpected theme. More than 80% of the interviewees (nine out of eleven) said they found Facebook “creepy” because of the targeted advertising and the collection of personal data. Also, most of those participants (seven out of nine) went on to say that they would pay for a “non-creepy Facebook.” This is particularly remarkable because I never asked the participants how they felt about targeted advertising or the use of personal data. It always came up in the conversation organically.

    Whenever we start a new project, our initial ideas revolve around our own personal experiences and discomforts. I started Candor Network because I personally feel that social media is designed to be addicting, and that this is a major flaw with many of the most popular services. However, while I can affirm my first assumption, I had unclear results on the second and have to consider rejecting the third. Also, I encountered a new user experience that I previously didn’t think of or account for: that the way social media tools collect and use personal data for advertising can be disconcerting and “creepy.” As is so often the case, the data analysis showed that there are a variety of other experiences, expectations, and needs that must be accounted for if the project is to be successful.

    Refining the hypothesis

    Graphic showing a process with Create Hypothesis, leading to Test, leading to Analyze, leading back to Create Hypothesis
    Discovery research cycle: Create Hypothesis, Test, Analyze, and repeat

    Each time we go through the discovery research process, we start with a hypothesis, test it by gathering data, analyze the data, and arrive at a new understanding of the problem. In theory, it may be possible to take one trip through the cycle and either completely affirm or completely reject our hypothesis and assumptions. However, like with Candor Network, it is more often the case that we get a mixture of results: some assumptions can be affirmed while others are rejected, and some completely new insights come to light.

    One option is to continue working with a single hypothesis, and simply refine it to account for the results of each round of research. This is especially helpful when the research mostly affirms your assumptions, but there is additional context and nuance you need to account for. However, if you find that your research results are pulling you in a new direction entirely, it can be useful to create a second, competing hypothesis.

    In my example, the interview research brought to light a new concern about social media I previously hadn’t considered: the “creepy” collection of personal data. I am left wondering, Would potential customers be more attracted to the idea of a social media platform built to prevent addiction, or one built for data privacy? To answer this question, I articulated a new, competing hypothesis:

    Because their business model relies on advertising, social media tools like Facebook are designed to gather lots of behavior data. They then utilize this behavior data to create super-targeted ads. Users are unhappy with this, and would rather use a social media tool that does not rely on the commodification of their data to make money. They would be willing to pay for a social media service that did not track their use and behavior.

    I now have two hypotheses to test against one another: one focused on social media addiction, the other focused on behavior tracking and data collection.

    At this point, it would be perfectly acceptable to conduct another round of interviews. We would need to change our interview protocol and find more participants, but it would still be an effective (and cheap) method to use. However, for this article I wanted to introduce a new method for you to consider, and to illustrate that a technique like A/B testing is not just for the “big guys” on the web. So I chose to conduct an A/B test utilizing two “fake-doors.”

    A low-cost comparative test: fake-door A/B testing

    A “fake-door” test is simply a marketing page, ad, button, or other asset that promotes a product that has yet to be made. Fake-door testing (or “ghetto testing”) is Zynga’s go-to method for testing ideas. They create a five-word summary of any new game they are considering, make a few ads, and put it up on various high-trafficked websites. Data is then collected to track how often users click on each of the fake-door “probes,” and only those games that attract a certain number of “conversions” on the fake-door are built.

    One of the many benefits of conducting a fake-door test is that it allows you to measure interest in a product before you begin to develop it. This makes it a great method for low-budget projects, because it can help you decide whether a project is worth investing in before you spend anything.

    However, for my project, I wasn’t just interested in measuring potential customer interest in a single product idea. I wanted to continue evaluating my original hypothesis on non-addictive social media as well as start investigating the second hypothesis on a social media platform that doesn’t record behavior data. Specifically, I wanted to see which theoretical social media platform is more attractive. So I created two fake-door landing pages—one for each hypothesis—and used Google Optimize to conduct an A/B test.

    Two screenshots of a Candor Network landing page with different copy
    Versions A (right) and B (left) of the Candor Network landing page

    Version A of the Candor Network landing page advertises the product I originally envisioned and described in my first problem hypothesis. It advertises a social network “built with mental health in mind.” Version B reflects the second problem hypothesis and my interview participants’ concerns around the “creepy” commodification of user data. It advertises a social network that “doesn’t track, use, solicit, or sell your data.” In all other respects, the landing pages are identical, and both will receive 50% of the traffic.

    Running an A/B test with little to no site traffic

    One of the major caveats when running an A/B test is that you need to have a certain number of people participate to achieve any kind of statistically significant result. This wouldn’t be a problem if we worked at a large company with an existing customer base, as it would be relatively straightforward to find ways to direct some of the existing traffic to the test. If you’re working on a new or low-trafficked site, however, conducting an A/B test can be tricky. Here are a few strategies I recommend:

    Figuring out how much traffic you need to achieve statistical significance in a quantitative study is an inexact science. If we were conducting a high-stakes experiment at a more established business, we would conduct multiple rounds of pre-tests to calculate the effect size of the experiment. Then we would use a calculation like Cohen’s d to estimate the number of people we need to participate in the actual test. This approach is rigorous and helps avoid sample pollution or sampling bias, but it requires a lot of resources upfront (like time, money, and lots of potential participants) that we may not have access to.

    In general, however, you can use this rule of thumb: the bigger the difference between the variations, the fewer participants you need to see a significant result. In other words, if your A and B are very different from each other, you will need fewer participants.

    Tip 2: Run the test for a longer amount of time

    When I worked at Weather Underground, we would always start an A/B test on a Sunday and end it a full week later on the following Sunday. That way we could be sure we captured both weekday and weekend users. Because Weather Underground is a high-trafficked site, this always resulted in having more than enough participants to see a statistically significant result.

    If you’re working on a new or low-trafficked site, however, you’ll need to run your test for longer than a week to achieve the number of test participants required. I recommend budgeting enough time so that your study can run a full six weeks. Six weeks will provide enough time to not only capture results from all your usual website traffic, but also any newcomers you can recruit through other means.

    Tip 3: Beg and borrow traffic from someone else

    I’ve got a pretty low number of followers on social media, so if I tweet or post about Candor Network, only a few people will see it. However, I know a few people and organizations that have a huge number of followers. For example, @alistapart has roughly 148k followers on Twitter, and A List Apart’s publisher, Jeffrey Zeldman (@zeldman), has 358k followers. I have asked them both to share the link for Candor Network with their followers.

    A screenshot of a Tweet from Jeffrey Zeldman promoting Meg's experiment
    A helpful tweet from @zeldman

    Of course, this method of advertising doesn’t cost any money, but it does cost social capital. I’m sure A List Apart and Mr. Zeldman wouldn’t appreciate it if I asked them to tweet things on my behalf on a regular basis. I recommend you use this method sparingly.

    Tip 4: Beware! There is always a risk of no results.

    Before you create an A/B test for your new product idea, there is one major risk you need to assess: there is a chance that your experiment won’t produce any statistically significant results at all. Even if you use all of the tips I’ve outlined above and manage to get a large number of participants in your test, there is a chance that you won’t be able to “declare a winner.” This isn’t just a risk for companies that have low traffic, it is an inherent risk when running any kind of quantitative study. Sometimes there simply isn’t a clear effect on participant behavior.

    Tune in next time for the last installment

    In the third and final installment of the “Discovery on a Budget” series, I’ll describe how I designed the incredibly short survey on the Candor Network landing page and discuss the results of my fake-door A/B test. I will also make another revision to my problem hypothesis and will discuss how to know when you’re ready to leave the discovery process (at least for now) and embark on the next phase of design: ideating over possible solutions.

  • My Accessibility Journey: What I’ve Learned So Far

    Last year I gave a talk about CSS and accessibility at the stahlstadt.js meetup in Linz, Austria. Afterward, an attendee asked why I was interested in accessibility: Did I or someone in my life have a disability?

    I’m used to answering this question—to which the answer is no—because I get it all the time. A lot of people seem to assume that a personal connection is the only reason someone would care about accessibility.

    This is a problem. For the web to be truly accessible, everyone who makes websites needs to care about accessibility. We tend to use our own abilities as a baseline when we’re designing and building websites. Instead, we need to keep in mind our diverse users and their diverse abilities to make sure we’re creating inclusive products that aren’t just designed for a specific range of people.

    Another reason we all should think about accessibility is that it makes us better at our jobs. In 2016 I took part in 10k Apart, a competition held by Microsoft and An Event Apart. The objective was to build a compelling web experience that worked without JavaScript and could be delivered in 10 kB. On top of that, the site had to be accessible. At the time, I knew about some accessibility basics like using semantic HTML, providing descriptions for images, and hiding content visually. But there was still a lot to learn.

    As I dug deeper, I realized that there was far more to accessibility than I had ever imagined, and that making accessible sites basically means doing a great job as a developer (or as a designer, project manager, or writer).

    Accessibility is exciting

    Web accessibility is not about a certain technology. It’s not about writing the most sophisticated code or finding the most clever solution to a problem; it’s about users and whether they’re able to use our products.

    The focus on users is the main reason why I’m specializing in accessibility rather than solely in animation, performance, JavaScript frameworks, or WebVR. Focusing on users means I have to keep up with pretty much every web discipline, because users will load a page, deal with markup in some way, use a design, read text, control a JavaScript component, see animation, walk through a process, and navigate. What all those things have in common is that they’re performed by someone in front of a device. What makes them exciting is that we don’t know which device it will be, or which operating system or browser. We also don’t know how our app or site will be used, who will use it, how fast their internet connection will be, or how powerful their device will be.

    Making accessible sites forces you to engage with all of these variables—and pushes you, in the process, to do a great job as a developer. For me, making accessible sites means making fast, resilient sites with great UX that are fun and easy to use even in conditions that aren’t ideal.

    I know, that sounds daunting. The good news, though, is that I’ve spent the last year focusing on some of those things, and I’ve learned several important lessons that I’m happy to share.

    1. Accessibility is a broad concept

    Many people, like me pre-2016, think making your site accessible is synonymous with making it accessible to people who use screen readers. That’s certainly hugely important, but it’s only one part of the puzzle. Accessibility means access for everyone:

    • If your site takes ten seconds to load on a mobile connection, it’s not accessible.
    • If your site is only optimized for one browser, it’s not accessible.
    • If the content on your site is difficult to understand, your site isn’t accessible.

    It doesn’t matter who’s using your website or when, where, and how they’re doing it. What matters is that they’re able to do it.

    The belief that you have to learn new software or maybe even hardware to get started with accessibility is a barrier for many developers. At some point you will have to learn how to use a screen reader if you really want to get everything right, but there’s a lot more to do before that. We can make a lot of improvements that help everyone, including people with visual impairments, by simply following best practices.

    2. There are permanent, temporary, and situational impairments

    Who benefits from a keyboard-accessible site? Only a small percentage of users, some might argue. Aaron Gustafson pointed me to the Microsoft design toolkit, which helped me broaden my perspective. People with permanent impairments are not the only ones who benefit from accessibility. There are also people with temporary and situational impairments who’d be happy to have an alternative way of navigating. For example, someone with a broken arm, someone who recently got their forearm tattooed, or a parent who’s holding their kid in one arm while having to check something online. When you watch a developer operate their editor, it sometimes feels like they don’t even know they have a mouse. Why not give users the opportunity to use your website in a similar way?

    As you think about the range of people who could benefit from accessibility improvements, the group of beneficiaries tends to grow much bigger. As Derek Featherstone has said, “When something works for everyone, it works better for everyone.

    3. The first step is to make accessibility a requirement

    I’ve been asked many times whether it’s worth the effort to fix accessibility, how much it costs, and how to convince bosses and colleagues. My answer to those questions is that you can improve things significantly without even having to use new tools, spend extra money, or ask anyone’s permission.

    The first step is to make accessibility a requirement—if not on paper, then at least in your head. For example, if you’re looking for a slider component, pick one that’s accessible. If you’re working on a design, make sure color contrasts are high enough. If you’re writing copy, use language that is easy to understand.

    We ask ourselves many questions when we make design and development decisions: Is the code clean? Does the site look nice? Is the UX great? Is it fast enough? Is it well-documented?

    As a first step, add one more question to your list: Is it accessible?

    4. Making accessible sites is a team sport

    Another reason why making websites accessible sounds scary to some developers is that there is a belief that we’re the only ones responsible for getting it right.

    In fact, as Dennis Lembree reminds us, “Nearly everyone in the organization is responsible for accessibility at some level.

    It’s a developer’s job to create an accessible site from a coding perspective, but there are many things that have to be taken care of both before and after that. Designs must be intuitive, interactions clear and helpful, copy understandable and readable. Relevant personas and use cases have to be defined, and tests must be carried out accordingly. Most importantly, leadership and teams have to see accessibility as a core principle and requirement, which brings me to the next point: communication.

    5. Communication is key

    After talking to a variety of people at meetups and conferences, I think one of the reasons accessibility often doesn’t get the place it deserves is that not everyone knows what it means. Many times you don’t even have to convince your team, but rather just explain what accessibility is. If you want to get people on board, it matters how you approach them.

    The first step here is to listen. Talk to your colleagues and ask why they make certain design, development, or management decisions. Try to find out if they don’t approach things in an accessible way because they don’t want to, they’re not allowed to, or they just never thought of it. You’ll have better results if they don’t feel bad, so don’t try to guilt anyone into anything. Just listen. As soon as you know why they do things the way they do, you’ll know how to address your concerns.

    Highlight the benefits beyond accessibility

    You can talk about accessibility without mentioning it. For example, talk about typography and ideal character counts per line and how beautiful text is with the perfect combination of font size and line height. Demonstrate how better performance impacts conversion rates and how focusing on accessibility can promote out-of-the-box thinking that improves usability in general.

    Challenge your colleagues

    Some people like challenges. At a meetup, a designer who specializes in accessibility once said that one of the main reasons she loves designing with constraints in mind is that it demands a lot more of her than going the easy way. Ask your colleagues, Can we hit a speed index below 1000? Do you think you can design that component in such a way that it’s keyboard-accessible? My Nokia 3310 has a browser—wouldn’t it be cool if we could make our next website work on that thing as well?

    Help people empathize

    In his talk “Every Day Website Accessibility,” Scott O’Hara points out that it can be hard for someone to empathize if they are unaware of what they should be empathizing with. Sometimes people just don’t know that certain implementations might be problematic for others. You can help them by explaining how people who are blind or who can’t use a mouse, use the web. Even better, show videos of how people navigate the web without a mouse. Empathy prompts are also a great of way of illustrating different circumstances under which people are surfing the web.

    6. Talk about accessibility before a projects kicks off

    It’s of course a good thing if you’re fixing accessibility issues on a site that’s already in production, but that has its limitations. At some point, changes may be so complicated and costly that someone will argue that it’s not worth the effort. If your whole team cares about accessibility from the very beginning, before a box is drawn or a line of code is written, it’s much easier, effective, and cost-efficient to make an accessible product.

    7. A solid knowledge of HTML solves a lot of problems

    It’s impressive to see how JavaScript and the way we use it has changed in recent years. It has become incredibly powerful and more important than ever for web development. At the same time, it seems HTML has become less important. There is an ongoing discussion about CSS in JavaScript and whether it’s more efficient and cleaner than normal CSS from a development perspective. What we should talk about instead is the excessive use of <div> and <span> elements at the expense of other elements. It makes a huge difference whether we use a link or a <div> with an onclick handler. There’s also a difference between links and buttons when it comes to accessibility. Form items need <label> elements, and a sound document outline is essential. Those are just a few examples of absolute basics that some of us forgot or never learned. Semantic HTML is one of the cornerstones of accessible web development. Even if we write everything in JavaScript, HTML is what is finally rendered in the user’s browser.

    (Re)learning HTML and using it consciously prevents and fixes many accessibility issues.

    8. JavaScript is not the enemy, and sometimes JavaScript even improves accessibility

    I’m one of those people who believes that most websites should be accessible even when JavaScript fails to execute. That doesn’t mean that I hate JavaScript; of course not—it pays part of my rent. JavaScript is not the enemy, but it’s important that we use it carefully because it’s very easy to change the user experience for the worse otherwise.

    Not that long ago, I didn’t know that JavaScript could improve accessibility. We can leverage its power to make our websites more accessible for keyboard users. We can do things like trapping focus in a modal window, adding key controls to custom components, or showing and hiding content in an accessible manner.

    There are many impressive and creative CSS-only implementations of common widgets, but they’re often less accessible and provide worse UX than their JavaScript equivalents. In a post about building a fully accessible help tooltip, Sara Soueidan explains why JavaScript is important for accessibility. “Every single no-JS solution came with a very bad downside that negatively affected the user experience,” she writes.

    9. It’s a good time to know vanilla CSS and JavaScript

    For a long time, we’ve been reliant on libraries, frameworks, grid systems, and polyfills because we demanded more of browsers than they were able to give us. Naturally, we got used to many of those tools, but from time to time we should take a step back and question if we really still need them. There were many problems that Bootstrap and jQuery solved for us, but do those problems still exist, or is it just easier for us to write $() instead of document.querySelector()?

    jQuery is still relevant, but browser inconsistencies aren’t as bad as they used to be. CSS Grid Layout is supported in all major desktop browsers, and thanks to progressive enhancement we can still provide experiences for legacy browsers. We can do feature detection natively with feature queries, testing has gotten much easier, and caniuse and MDN help us understand what browsers are capable of. Many people use frameworks and libraries without knowing what problems those tools are solving. To decide whether it makes sense to add the extra weight to your site, you need a solid understanding of HTML, CSS, and JavaScript. Instead of increasing the page weight for older browsers, it’s often better to progressively enhance an experience. Progressively enhancing our websites—and reducing the number of requests, kilobytes, and dependencies—makes them faster and more robust, and thus more accessible.

    10. Keep learning about accessibility and share your knowledge

    I’m really thankful that I’ve learned all this in the past few months. Previously, I was a very passive part of the web community for a very long time. Ever since I started to participate online, attend and organize events, and write about web-related topics, especially accessibility, things have changed significantly for me and I’ve grown both personally and professionally.

    Understanding the importance of access and inclusion, viewing things from different perspectives, and challenging my decisions has helped me become a better developer.

    Knowing how things should be done is great, but it’s just the first step. Truly caring, implementing, and most importantly sharing your knowledge is what makes an impact.

    Share your knowledge

    Don’t be afraid to share what you’ve learned. Write articles, talk at meetups, and give in-house workshops. The distinct culture of sharing knowledge is one of the most important and beautiful things about our industry.

    Go to conferences and meetups

    Attending conferences and meetups is very valuable because you get to meet many different people from whom you can learn. There are several dedicated accessibility events and many conferences that feature at least one accessibility talk.

    Organize meetups

    Dennis Deacon describes his decision to start and run an accessibility meetup as a life-changing experience. Meetups are very important and valuable for the community, but organizing a meetup doesn’t just bring value to attendees and speakers. As an organizer, you get to meet all these people and learn from them. By listening and by understanding how they see and approach things, and what’s important to them, you are able to broaden your horizons. You grow as a person, but you also get to meet other professionals, agencies, and companies from which you may also benefit professionally.

    Invite experts to your meetup or conference

    If you’re a meetup or conference organizer, you can have a massive impact on the role accessibility plays in our community. Invite accessibility experts to your event and give the topic a forum for discussion.

    Follow accessibility experts on Twitter

    Follow experts on Twitter to learn what they’re working on, what bothers them, and what they think about recent developments in inclusive web development and design in general. I’ve learned a lot from the following people: Aaron Gustafson, Adrian Roselli, Carie Fisher, Deborah Edwards-Onoro, Heydon Pickering, Hugo Giraudel, Jo Spelbrink, Karl Groves, Léonie Watson, Marco Zehe, Marcy Sutton, Rob Dodson, Scott O’Hara, Scott Vinkle, and Steve Faulkner.

    11. Simply get started

    You don’t have to go all-in from the very beginning. If you improve just one thing, you’re already doing a great job in bringing us closer to a better web. Just get started and keep working.

    There are a lot of resources out there, and trying to find out how and where to start can get quite overwhelming. I’ve gathered a few sites and books that helped me; hopefully they will help you as well. The following lists are by no means exhaustive.

    Video series

    • This free Udacity course is a great way to get started.
    • Rob Dodson covers many different accessibility topics in his video series A11ycasts (a11y is short for accessibility—the number eleven stands for the number of letters omitted).

    Books

    Blogs

    Newsletters

    Accessible JavaScript components

    Resources and further reading

  • Design Like a Teacher

    In 2014, the clinic where I served as head of communications and digital strategy switched to a new online patient portal, a change that was mandated by the electronic health record (EHR) system we used. The company that provides the EHR system held several meetings for the COO and me to learn the new tool and provided materials to give to patients to help them register for and use the new portal.

    As the sole person at my clinic working on any aspect of user experience, I knew the importance of knowing the audience when implementing an initiative like the patient portal. So I was skeptical of the materials provided to the patients, which assumed a lot of knowledge on their part and focused on the cool features of the portal rather than on why patients would actually want to use it.

    By the time the phone rang for the fifth time on the first day of the transition, I knew my suspicion that the patient portal had gone wrong in the user experience stage was warranted. Patients were getting stuck during every phase of the process—from wondering why they should use the portal to registering for and using it. My response was to ask patients what they had tried so far and where they were getting stuck. Then I would try to explain why they might want to use the portal.

    Sometimes I lost patients completely; they just refused to sign up. They had a bad user experience trying to understand how a portal fit into their mental model of receiving healthcare, and I had a terrible user experience trying to learn what I needed to do to guide patients through the migration. To borrow a phrase from Dave Platt, the lead instructor of the UX Engineering course I currently help teach, the “hassle budget” was extremely high.

    I realized three important things in leading this migration:

    • When people get stuck, their frustration prevents them from providing information up front. They start off with “I’m stuck” and don’t offer additional feedback until you pull it out of them. (If you felt a tremor just then, that was every IT support desk employee in the universe nodding emphatically.)
    • In trying to get them unstuck, I had to employ skills that drew on my work outside of UX. There was no choice; I had a mandate to reach an adoption rate of at least 60%.
    • The overarching goal was really to help these patients learn to do something different than what they were used to, whether that was deal with a new interface or deal with an interface for the first time at all.

    Considering these three realizations led me to a single, urgent conclusion that has transformed my UX practice: user experience is really a way of defining and planning what we want a user to learn, so we also need to think about our own work as how to teach.

    It follows, then, that user experience toolkits need to include developing a teaching mindset. But what does that mean? And what’s the benefit? Let’s use this patient portal story and the three realizations above as a framework for considering this.

    Helping users get unstuck

    Research on teaching and learning has produced two concepts that can help explain why people struggle to get unstuck and what to do about it: 1) cognitive load and 2) the zone of proximal development.

    Much like you work your muscles through weight resistance to develop physical strength, you work your brain through cognitive load to develop mental strength—to learn. There are three kinds of cognitive load: intrinsic, germane, and extraneous.

     

    This type of cognitive load ... is responsible for ...
    Intrinsic Actual learning of the material
    Germane Building that new information into a more permanent memory store
    Extraneous Everything else about the experience of encountering the material (e.g., who’s teaching it, how they teach, your comfort level with the material, what the room is like, the temperature, the season, your physical health, energy levels, and so on)

    In the case of the patient portal, intrinsic cognitive load was responsible for a user actually signing up for the portal and using it for the first time. Germane cognitive load was devoted to a user making sense of this experience and storing it so that it can be repeated in the future with increasing fluency. My job in salvaging the user experience was to figure out what was extraneous in the process of using the portal so that I could help users focus on what they needed to know to use it effectively.

    Additionally, we all have a threshold for comfortably exploring and figuring something out with minimal guidance. This threshold moves around depending on the task and is called your zone of proximal development. It lays between the spaces where you can easily do a task on your own and where you cannot do a task at all without help. Effective learning happens in this zone by offering the right support, at the right time, in the right amount.

    When you’re confronted with an extremely frustrated person because of a user experience you have helped create (or ideally, before that scenario happens), ask yourself a couple questions:

    • Did I put too much burden on their learning experience at the expense of the material?
    • Did I do my best to support their movement from something completely familiar to something new and/or unknown?

    Think about your creation in terms of the immediate task and everything else. Consider (or reconsider) all the feelings, thoughts, contexts, and everything else that could make up the space around that task. What proportion of effort goes to the task versus to everything in the space around it? After that, think about how easy or difficult it is to achieve that task. Are you offering the right support, at the right time, in the right amount? What new questions might you need to ask to figure that out?

    Making use of “unrelated” skill sets

    When you were hired, you responded to a job description that included specific bullet points detailing the skills you should have and duties you would be responsible for fulfilling. You highlighted everything about your work that showed you fit that description. You prepared your portfolio, and demonstrated awareness of the recent writings from UX professionals in the field to show you can hold a conversation about how to “do” this work. You looked incredibly knowledgeable.

    In research on teaching and learning, we also explore the idea of how we know in addition to what we know. Some people believe that knowledge is universally true and is out there to be uncovered and explored. Others believe that knowledge is subjective because it is uncovered and explored through the filter of the individual’s experiences, reflections, and general perception of reality. This is called constructivism. If we accept constructivism, it means that we open ourselves to learning from each other in how we conceptualize and practice UX based on what else we know besides what job descriptions ask. How do we methodically figure out the what else? By asking better questions.

    Part of teaching and learning in a constructivist framework is understanding that the name of the game is facilitation, not lecturing (you might have heard the cute phrase, “Guide on the side, not sage on the stage”). Sharing knowledge is actually about asking questions to evoke reflection and then conversation to connect the dots. Making time to do this can help you recall and highlight the “unrelated” skills that you may have buried that would actually serve you well in your UX work. For example:

    • That was an incredibly difficult stakeholder meeting. What feels like the most surprising thing about how it turned out?
    • It seemed like we got nothing done in that wireframing session. Everyone wanted to see their own stuff included instead of keeping their eye on who we’re solving for. What is another time in my life when I had this kind of situation? How did it turn out?

    All of this is in service to helping ourselves unlock more productive communication with our clients. In the patient portal case, I relied very heavily on my master’s degree in international relations, which taught me about how to ask questions to methodically untangle a problem into more manageable chunks, and listen for what a speaker is really saying between the lines. When you don’t speak the same language, your emotional intelligence and empathy begin to heighten as you try to relate on a broader human level. This helped me manage patient expectations to navigate them to the outcome I needed, even though this degree was meant to prepare me to be a diplomat.

    As you consider how you’re feeling in your current role, preparing for a performance review, or plotting your next step, think about your whole body of experience. What are the themes in your work that you can recall dealing with in other parts of your life (at any point)? What skills are you relying on that, until you’ve now observed them, you didn’t think very much about but that have a heavy influence on your style of practice or that help make you effective when you work with your intended audiences?

    Unlearn first, then learn

    When Apple wanted to win over consumers in their bid to make computers a household item, they had to help them embrace what a machine with a screen and some keys could accomplish. In other words, to convince consumers it was worth it to learn how to use a computer, they first had to help consumers unlearn their reliance on a desk, paper, file folders, and pencils.

    Apple integrated this unlearning and learning into one seamless experience by creating a graphical user interface that used digital representations of objects people were already familiar with—desks, paper, file folders, and pencils. But the solution may not always be that literal. There are two concepts that can help you support your intended audiences as they transition from one system or experience to another.

    The first concept, called a growth mindset, relates to the belief that people are capable of constructing and developing intelligence in any given area, as opposed to a fixed mindset, which holds that each of us is born with a finite capacity for some level of skill. It’s easy to tell if someone has a fixed mindset if they say things like, “I’m too old to understand new technology,” or “This is too complicated. I’ll never get it.”

    The second is self-determination theory, which divides motivation into two types: intrinsic and extrinsic. Self-determination theory states that in learning, your desire to persevere is not just about having motivation at all, but about what kind of motivation you have. Intrinsic motivation comes from within yourself; extrinsic comes from the world around you. Thanks to this research and subsequent studies, we know that intrinsic motivation is vital to meaningful learning and skill development (think about the last time you did an HR training and liked it).

    This appears in our professional practice as the ever-favored endeavor to generate “buy-in.” What we’re really saying is, “How do I get someone to feel motivated on their own to be part of this or do this thing, instead of me having to reward them or somehow provide an incentive?” Many resources on getting buy-in are about the end goal of getting someone to do what you want. While this is important, conducting this as a teaching process allows you to step back and make space for the other person’s active contribution to a dialogue where you also learn something, even if you don’t end up getting buy-in:

    • “I’m curious about your feeling that this is complicated. Walk me through what you’ve done so far and tell me more about that feeling.”
    • “What’s the most important part of this for you? What excites you or resonates with you?”

    For the majority of patients I worked with, transitioning to a new portal was almost fully an extrinsically motivated endeavor—if they didn’t switch, they didn’t get to access their health information, such as lab results, which is vital for people with chronic diseases. They did it because they had to. And many patients ran into a fixed-mindset wall as they confronted bad design: “I can’t understand this. I’m not very good at the computer. I don’t understand technology. Why do I have to get my information this way?” I especially spent a lot of time on exploring why some users felt the portal was complicated (i.e., the first bullet point above), because not only did I want them to switch to it, but I wanted them to switch and then keep using the portal with increasing fluency. First I had to help them unlearn some beliefs about their capabilities and what it means to access information online, and then I could help them successfully set up and use this tool.

    While you’re researching the experience you’re going to create around a product, service, or program, ask questions not just about the thing itself but about the circumstances or context. What are the habits or actions someone might need to stop doing, or unlearn, before they adopt what you’re creating? What are the possible motivators in learning to do the something different? Among those, what is the ratio of extrinsic to intrinsic? Do you inadvertently cause an inflammation of fixed mindset? How do you instead encourage a growth mindset?

    Where we go from here

    Ultimately, I hit the target: about 70% of patients who had been using the old portal migrated to the new tool. It took some time for me to realize I needed to create a process rather than react to individual situations, but gradually things started to smooth out as I knew what bumps in the road to expect. I also walked back even further and adjusted our communications and website content to speak to the fears and concerns I now knew patients experienced. Eventually, we finished migrating existing patients, and the majority of patients signing onto this portal for the first time were new to the clinic overall (so they would not have used the previous portal). To my knowledge the interface design never improved in any profound way, but we certainly lodged a lot of technical tickets to contribute to a push for feature changes and improvements.

    Although this piece contains a lot of information, it essentially boils down to asking questions as you always do, but from a different angle to uncover more blind spots. The benefit is a more thorough understanding of who you intend to serve and a more empathetic process for acquiring that understanding. Each section is specifically written to give you a direct idea of a question or prompt you can use the next time you have an opportunity in your own work. I would love to hear how deepening your practice in this way works for you—please comment or feel free to find me on Twitter!

  • CSS: The Definitive Guide, 4th Edition

    A note from the editors: We’re pleased to share an excerpt from Chapter 19 (“Filters, Blending, Clipping, and Masking”) of CSS: The Definitive Guide, 4th Edition by Eric Meyer and Estelle Weyl, available now from O’Reilly.

    In addition to filtering, CSS offers the ability to determine how elements are composited together. Take, for example, two elements that partially overlap due to positioning. We’re used to the one in front obscuring the one behind. This is sometimes called simple alpha compositing, in that you can see whatever is behind the element as long as some (or all) of it has alpha channel values less than 1. Think of, for example, how you can see the background through an element with opacity: 0.5, or in the areas of a PNG or GIF87a that are set to be transparent.

    But if you’re familiar with image-editing programs like Photoshop or GIMP, you know that image layers which overlap can be blended together in a variety of ways. CSS has gained the same ability. There are two blending strategies in CSS (at least as of late 2017): blending entire elements with whatever is behind them, and blending together the background layers of a single element.

    Blending Elements

    In situations where elements overlap, it’s possible to change how they blend together with the property mix-blend-mode.

    mix-blend-mode

    Values: normal | multiply | screen | overlay | darken | lighten | colordodge | color-burn | hard-light | soft-light | difference | exclusion | hue | saturation | color | luminosity
    Initial value: normal
    Applies to: All elements
    Computed value: As declared
    Inherited: No
    Animatable: No

    The way the CSS specification puts this is: “defines the formula that must be used to mix the colors with the backdrop.” That is to say, the element is blended with whatever is behind it (the “backdrop”), whether that’s pieces of another element, or just the background of its parent element.

    The default, normal, means that the element’s pixels are shown as is, without any mixing with the backdrop, except where the alpha channel is less than 1. This is the “simple alpha compositing” mentioned previously. It’s what we’re all used to, which is why it’s the default value. A few examples are shown in Figure 19-6.

    Graphic showing three different alpha compositing blending modes in CSS
    Figure 19-6. Simple alpha channel blending

    For the rest of the mix-blend-mode keywords, I’ve grouped them into a few categories. Let’s also nail down a few definitions:

    • The foreground is the element that has mix-blend-mode applied to it.
    • The backdrop is whatever is behind that element. This can be other elements, the background of the parent element, and so on.
    • A pixel component is the color component of a given pixel: R, G, and B

    If it helps, think of the foreground and backdrop as images that are layered atop one another in an image-editing program. With mix-blend-mode, you can change the blend mode applied to the top image (the foreground).

    Darken, Lighten, Difference, and Exclusion

    These blend modes might be called simple-math modes—they achieve their effect by directly comparing values in some way, or using simple addition and subtraction to modify pixels:

    darken: Each pixel in the foreground is compared with the corresponding pixel in the backdrop, and for each of the R, G, and B values (the pixel components), the smaller of the two is kept. Thus, if the foreground pixel has a value corresponding to rgb(91,164,22) and the backdrop pixel is rgb(102,104,255), the resulting pixel will be rgb(91,104,22).

    lighten: This blend is the inverse of darken: when comparing the R, G, and B components of a foreground pixel and its corresponding backdrop pixel, the larger of the two values is kept. Thus, if the foreground pixel has a value corresponding to rgb(91,164,22) and the backdrop pixel is rgb(102,104,255), the resulting pixel will be rgb(102,164,255).

    difference: The R, G, and B components of each pixel in the foreground are compared to the corresponding pixel in the backdrop, and the absolute value of subtracting one from the other is the final result. Thus, if the foreground pixel has a value corresponding to rgb(91,164,22) and the backdrop pixel is rgb(102,104,255), the resulting pixel will be rgb(11,60,233). If one of the pixels is white, the resulting pixel will be the inverse of the non-white pixel. If one of the pixels is black, the result will be exactly the same as the non-black pixel.

    exclusion: This blend is a milder version of difference. Rather than being | back - fore |, the formula is back + fore - (2 × back × fore), where back and fore are values in the range from 0-1. For example, an exclusion calculation of an orange (rgb(100%,50%,0%)) and medium gray (rgb(50%,50%,50%)) will yield rgb(50%,50%,50%). For the red component, the math is 1 + 0.5 - (2 × 1 × 0.5), which reduces to 0.5, corresponding to 50%. For the blue and green components, the math is 0 + 0.5 - (2 × 0 × 0.5), which again reduces to 0.5. Compare this to difference, where the result would be rgb(50%,0%,50%), since each component is the absolute value of subtracting one from the other.

    This last definition highlights the fact that for all blend modes, the actual values being operated on are in the range 0-1. The previous examples showing values like rgb(11,60,233) are normalized from the 0-1 range. In other words, given the example of applying the difference blend mode to rgb(91,164,22) and rgb(102,104,255), the actual operation is as follows:

    • rgb(91,164,22) is R = 91 ÷ 255 = 0.357; G = 164 ÷ 255 = 0.643; B = 22 ÷ 255 = 0.086. Similarly, rgb(102,104,255) corresponds to R = 0.4; G = 0.408; B = 1.
    • Each component is subtracted from the corresponding component, and the absolute value taken. Thus, R = | 0.357 - 0.4 | = 0.043; G = | 0.643 - 0.408 | = 0.235; B = | 1 - 0.086 | = 0.914. This could be expressed as rgba(4.3%,23.5%,91.4%), or (by multiplying each component by 255) as rgb(11,60,233).

    From all this, you can perhaps understand why the full formulas are not written out for every blend mode we cover. If you’re interested in the fine details, each blend mode’s formula is provided in the “Compositing and Blending Level 1” specification.

    Examples of the blend modes in this section are depicted in Figure 19-7.

    Graphic showing various blend modes in CSS
    Figure 19-7. Darken, lighten, difference, and exclusion blending

    Multiply, Screen, and Overlay

    These blend modes might be called the multiplication modes—they achieve their effect by multiplying values together:

    multiply: Each pixel component in the foreground is multiplied by the corresponding pixel component in the backdrop. This yields a darker version of the foreground, modified by what is underneath. This blend mode is symmetric, in that the result will be exactly the same even if you were to swap the foreground with the back‐drop.

    screen: Each pixel component in the foreground is inverted (see invert in the earlier section “Color Filtering” on page 948), multiplied by the inverse of the corresponding pixel component in the backdrop, and the result inverted again. This yields a lighter version of the foreground, modified by what is underneath. Like multiply, screen is symmetric.

    overlay: This blend is a combination of multiply and screen. For foreground pixel components darker than 0.5 (50%), the multiply operation is carried out; for foreground pixel components whose values are above 0.5, screen is used. This makes the dark areas darker, and the light areas lighter. This blend mode is not symmetric, because swapping the foreground for the backdrop would mean a different pattern of light and dark, and thus a different pattern of multiplying versus screening.

    Examples of these blend modes are depicted in Figure 19-8.

    Graphic showing various blend modes in CSS
    Figure 19-8. Multiply, screen, and overlay blending

    Hard and Soft Light

    There blend modes are covered here because the first is closely related to a previous blend mode, and the other is just a muted version of the first:

    hard-light: This blend is the inverse of overlay blending. Like overlay, it’s a combination of multiply and screen, but the determining layer is the backdrop. Thus, for back‐drop pixel components darker than 0.5 (50%), the multiply operation is carried out; for backdrop pixel components lighter than 0.5, screen is used. This makes it appear somewhat as if the foreground is being projected onto the backdrop with a projector that employs a harsh light.

    soft-light: This blend is a softer version of hard-light. That is to say, it uses the same operation, but is muted in its effects. The intended appearance is as if the foreground is being projected onto the backdrop with a projector that employs a diffuse light.

    Examples of these blend modes are depicted in Figure 19-9.

    Graphic showing various blend modes in CSS
    Figure 19-9. Hard- and soft-light blending

    Color Dodge and Burn

    Color dodging and burning are interesting modes, in that they’re meant to lighten or darken a picture with a minimum of change to the colors themselves. The terms come from old darkroom techniques performed on chemical film stock:

    color-dodge: Each pixel component in the foreground is inverted, and the component of the corresponding backdrop pixel component is divided by the inverted foreground value. This yields a brightened backdrop unless the foreground value is 0, in which case the backdrop value is unchanged.

    color-burn: This blend is a reverse of color-dodge: each pixel component in the backdrop is inverted, the inverted backdrop value is divided by the unchanged value of the corresponding foreground pixel component, and the result is then inverted. This yields a result where the darker the backdrop pixel, the more its color will burn through the foreground pixel.

    Examples of these blend modes are depicted in Figure 19-10.

    Graphic showing various blend modes in CSS
    Figure 19-10. Color dodge and burn blending

    Hue, Saturation, Luminosity, and Color

    The final four blend modes are different than those we’ve seen before, because they do not perform operations on the R/G/B pixel components. Instead, they perform operations to combine the hue, saturation, luminosity, and color of the foreground and backdrop in different ways:

    hue: For each pixel, combines the luminosity and saturation levels of the backdrop with the hue angle of the foreground.

    saturation: For each pixel, combines the hue angle and luminosity level of the backdrop with the saturation level of the foreground.

    color: For each pixel, combines the luminosity level of the backdrop with the hue angle and saturation level of the foreground.

    luminosity: For each pixel, combines the hue angle and saturation level of the backdrop with the luminosity level of the foreground.

    Examples of these blend modes are depicted in Figure 19-11.

    Graphic showing various blend modes in CSS
    Figure 19-11. Hue, saturation, luminosity, and color blending

    These blend modes can be a lot harder to grasp without busting out raw formulas, and even those can be confusing if you aren’t familiar with how things like saturation and luminosity levels are determined. If you don’t feel like you quite have a handle on how they work, the best thing is to practice with a bunch of different images and simple color patterns.

    Two things to note:

    • Remember that an element always blends with its backdrop. If there are other elements behind it, it will blend with them; if there’s a patterned background on the parent element, the blending will be done against that pattern.
    • Changing the opacity of a blended element will change the outcome, though not always in the way you might expect. For example, if an element with mix-blend-mode: difference is also given opacity: 0.8, then the difference calculations will be scaled by 80%. More precisely, a scaling factor of 0.8 will be applied to the color-value calculations. This can cause some operations to trend toward flat middle gray, and others to shift the color changes.
  • The King vs. Pawn Game of UI Design

    If you want to improve your UI design skills, have you tried looking at chess? I know it sounds contrived, but hear me out. I’m going to take a concept from chess and use it to build a toolkit of UI design strategies. By the end, we’ll have covered color, typography, lighting and shadows, and more.

    But it all starts with rooks and pawns.

    I want you to think back to the first time you ever played chess (if you’ve never played chess, humor me for a second—and no biggie; you will still understand this article). If your experience was anything like mine, your friend set up the board like this:

    Standard chessboard in starting configuration

    And you got your explanation of all the pieces. This one’s a pawn and it moves like this, and this one is a rook and it moves like this, but the knight goes like this or this—still with me?—and the bishop moves diagonally, and the king can only do this, but the queen is your best piece, like a combo of the rook and the bishop. OK, want to play?

    This is probably the most common way of explaining chess, and it’s enough to make me hate board games forever. I don’t want to sit through an arbitrary lecture. I want to play.

    One particular chess player happens to agree with me. His name is Josh Waitzkin, and he’s actually pretty good. Not only at chess (where he’s a grandmaster), but also at Tai Chi Push Hands (he’s a world champion) and Brazilian Jiu Jitsu (he’s the first black belt under 5x world champion Marcelo Garcia). Now he trains financiers to go from the top 1% to the top .01% in their profession.

    Point is: this dude knows a lot about getting good at stuff.

    Now here’s the crazy part. When Josh teaches you chess, the board looks like this:

    Chessboard showing only three pieces
    King vs. King and Pawn

    Whoa.

    Compared to what we saw above, this is stupidly simple.

    And, if you know how to play chess, it’s even more mind-blowing that someone would start teaching with this board. In the actual game of chess, you never see a board like this. Someone would have won long ago. This is the chess equivalent of a street fight where both guys break every bone in their body, dislocate both their arms, can hardly see out of their swollen eyes, yet continue to fight for another half-hour.

    What gives?

    Here’s Josh’s thinking: when you strip the game down to its core, everything you learn is a universal principle.

    That sounds pretty lofty, but I think it makes sense when you consider it. There are lots of things to distract a beginning chess player by a fully-loaded board, but everything you start learning in a king-pawn situation is fundamentally important to chess:

    • using two pieces to apply pressure together;
    • which spaces are “hot”;
    • and the difference between driving for a checkmate and a draw.

    Are you wondering if I’m ever going to start talking about design? Glad you asked.

    The simplest possible scenario

    What if, instead of trying to design an entire page with dozens of elements (nav, text, input controls, a logo, etc.), we consciously started by designing the simplest thing possible? We deliberately limit the playing field to one, tiny thing and see what we learn? Let’s try.

    What is the simplest possible element? I vote that it’s a button.

    Basic blue button that says, 'Learn More'

    This is the most basic, default button I could muster. It’s Helvetica (default font) with a 16px font size (pretty default) on a plain, Sketch-default-blue rectangle. It’s 40px tall (nice, round number) and has 20px of horizontal padding on each side.

    So yeah, I’ve already made a bunch of design decisions, but can we agree I basically just used default values instead of making decisions for principled, design-related reasons?

    Now let’s start playing with this button. What properties are modifiable here?

    • the font (and text styling)
    • the color
    • the border radius
    • the border
    • the shadows

    These are just the first things that come to my mind. There are even more, of course.

    Typography

    Playing with the font is a pretty easy place to start.

    Button with a rounder font
    Blown up to show font detail.

    Now I’ve changed the font to Moon (available for free on Behance for personal use). It’s rounded and soft, unlike Helvetica, which felt a little more squared-off—or at least not as overtly friendly.

    The funny thing is: do you see how the perfectly square edges now look a tad awkward with the rounded font?

    Let’s round the corners a bit.

    Button with round font and rounded corner

    Bam. Nice. That’s a 3px border radius.

    But that’s kind of weird, isn’t it? We adjusted the border radius of a button because of the shape of the letterforms in our font. I wouldn’t want you thinking fonts are just loosey-goosey works of art that only work when you say the right incantations.

    No, fonts are shapes. Shapes have connotations. It’s not rocket science.

    Here’s another popular font, DIN.

    Examples of the Din font
    With its squared edges, DIN is a clean and solid workhorse font.

    Specifically, this is a version called DIN 2014 (available for cheap on Typekit). It’s the epitome of a squared-off-but-still-readable font. A bit harsh and no-nonsense, but in a bureaucratic way.

    It’s the official font of the German government, and it looks the part.

    So let’s test our working hypothesis with DIN.

    Button with sharp font and rounded corner

    How does DIN look with those rounded corners?

    Well, we need to compare it to square corners now, don’t we?

    Button with sharp font and sharp corners

    Ahhh, the squared-off corners are better here. It’s a much more consistent feel.

    Now look at our two buttons with their separate fonts. Which is more readable? I think Moon has a slight advantage here. DIN’s letters just look too cramped by comparison. Let’s add a bit of letter-spacing.

    Button with sharp font and letter spacing, with sharp corners

    When we add some letter-spacing, it’s far more relaxed.

    This is a key law of typography: always letter-space your uppercase text. Why? Because unless a font doesn’t have lowercase characters, it was designed for sentence-case reading, and characters in uppercase words will ALWAYS appear too cramped. (Moon is the special exception here—it only has uppercase characters, and notice how the letter-spacing is built into the font.)

    We’ll review later, but so far we’ve noticed two things that apply not just to buttons, but to all elements:

    • Rounded fonts go better with rounded shapes; squared-off fonts with squared-off shapes.
    • Fonts designed for sentence case should be letter-spaced when used in words that are all uppercase.

    Let’s keep moving for now.

    Color

    Seeing the plain default Sketch blue is annoying me. It’s begging to be changed into something that matches the typefaces we’re using.

    How can a color match a font? Well, I’ll hand it to you. This one is a bit more loosey-goosey.

    For our Moon button, we want something a bit more friendly. To me, a staid blue says default, unstyled, trustworthy, takes-no-risks, design-by-committee. How do you inject some fun into it?

    Well, like all problems of modifying color, it helps to think in the HSB color system (hue, saturation, and brightness). When we boil color down to three intuitive numbers, we give ourselves levers to pull.

    For instance, let’s look at hue. We have two directions we can push hue: down to aqua or up to indigo. Which sounds more in line with Moon? To me, aqua does. A bit less staid, a bit more Caribbean sea. Let’s try it. We’ll move the hue to 180° or so.

    Same button with a lighter blue background

    Ah, Moon Button, now you’ve got a beach vibe going on. You’re a vibrant sea foam!

    This is a critical lesson about color. “Blue” is not a monolith; it’s a starting point. I’ve taught hundreds of students UI design, and this comes up again and again: just because blue was one color in kindergarten doesn’t mean that we can’t find interesting variations around it as designers.

    Chart showing various shades of blue with names and temperature
    “Blue” is not a monolith. Variations are listed in HSB, with CSS color names given below each swatch.

    Aqua is a great variation with a much cooler feel, but it’s also much harder to read that white text. So now we have another problem to fix.

    “Hard to read” is actually a numerically-specific property. The World Wide Web Consortium has published guidelines for contrast between text and background, and if we use a tool to test those, we find we’re lacking in a couple departments.

    Chart showing a failure for AA and AAA WCAG compliance
    White text on an aqua button doesn’t provide enough contrast, failing to pass either AA or AAA WCAG recommendations.

    According to Stark (which is my preferred Sketch plugin for checking contrast—check out Lea Verou’s Contrast Ratio for a similar web-based tool), we’ve failed our contrast guidelines across the board!

    How do you make the white text more legible against the aqua button? Let’s think of our HSB properties again.

    • Brightness. Let’s decrease it. That much should be obvious.
    • Saturation. We’re going to increase it. Why? Because we’re contrasting with white text, and white has a saturation of zero. So a higher saturation will naturally stand out more.
    • Hue. We’ll leave this alone since we like its vibe. But if the contrast continued to be too low, you could lower the aqua’s luminosity by shifting its hue up toward blue.

    So now, we’ve got a teal button:

    Same button with a darker teal

    Much better?

    Chart showing a passing score for AA WCAG compliance

    Much better.

    For what it’s worth, I’m not particularly concerned about missing the AAA standard here. WCAG developed the levels as relative descriptors of how much contrast there is, not as an absolute benchmark of, say, some particular percentage of people to being able to read the text. The gold standard is—as always—to test with real people. AAA is best to hit, but at times, AA may be as good as you’re going to get with the colors you have to work with.

    Some of the ideas we’ve used to make a button’s blue a bit more fun and legible against white are actually deeper lessons about color that apply to almost everything else you design:

    • Think in HSB, as it gives you intuitive levers to pull when modifying color.
    • If you like the general feel of a color, shifting the hue in either direction can be a baseline for getting interesting variations on it (e.g., we wanted to spice up the default blue, but not by, say, changing it to red).
    • Modify saturation and brightness at the same time (but always in opposite directions) to increase or decrease contrast.

    OK, now let’s switch over to our DIN button. What color goes with its harsh edges and squared-off feel?

    The first thing that comes to mind is black.

    Black button with sharp font and sharp corners

    But let’s keep brainstorming. Maybe a stark red would also work.

    Deep red button with sharp font and sharp corners

    Or even a construction-grade orange.

    Deep orange button with sharp font and sharp corners

    (But not the red and orange together. Yikes! In general, two adjacent hues with high saturations will not look great next to each other.)

    Now, ignoring that the text of this is “Learn More” and a button like this probably doesn’t need to be blaze orange, I want you to pay attention to the colors I’m picking. We’re trying to maintain consistency with the official-y, squared-off DIN. So the colors we go to naturally have some of the same connotations: engineered, decisive, no funny business.

    Sure, this match-a-color-and-a-font business is more subjective, but there’s something solid to it: note that the words I used to describe the colors (“stark” and “construction-grade”) apply equally well to DIN—a fact I am only noticing now, not something done intentionally.

    Want to match a color with a font? This is another lesson applicable to all of branding. It’s best to start with adjectives/emotions, then match everything to those. Practically by accident, we’ve uncovered something fundamental in the branding design process.

    Shadows

    Let’s shift gears to work with shadows for a bit.

    There are a couple directions we could go with shadows, but the two main categories are (for lack of better terms):

    • realistic shadows;
    • and cartoon-y shadows.

    Here’s an example of each:

    Graphic showing a teal button with a realistic drop shadow and another button with a border-like shadow along the bottom

    The top button’s shadow is more photorealistic. It behaves like a shadow in the real world.

    The bottom button’s shadow is a bit lower-fidelity. It shows that the button is raised up, but it’s a cartoon version, with a slightly unrealistic, idealized bottom edge—and without a normal shadow, which would be present in the real world.

    The bottom works better for the button we’re crafting. The smoothness, the friendliness, the cartoon fidelity—it all goes together.

    As for our DIN button?

    Graphic showing a black button with a realistic drop shadow and another button with an indistinguishable bottom shadow

    I’m more ambivalent here. Maybe the shadow is for a hover state, à la Material Design?

    In any case, with a black background, a darkened bottom edge is impossible—you can’t get any darker than black.

    By the way, you may not have noticed it above, but the black button has a much stronger shadow. Compare:

    Graphic showing the soft shadow on the teal button and the harder shadow on the black button

    The teal button’s shadow is 30%-opacity black, shifted 1 pixel down on the y-axis, with a 2-pixel blur (0 1px 2px). The black button’s is 50%-opacity black, shifted 2 pixels down on the y-axis, with a 4-pixel blur (0 2px 4px). What’s more, the stronger shadow looks awful on the teal button.

    A dark shadow underneath a softer teal button

    Why is that? The answer, like so many questions that involve color, is in luminosity. When we put the button’s background in luminosity blend mode, converting it to a gray of equal natural lightness, we see something interesting.

    A grayscale version of our teal button with a shadow

    The shadow, at its darkest, is basically as dark as the button itself. Or, at least, the rate of change of luminosity is steady between each row of pixels.

    Extreme closeup of the gradient resulting in the drop shadow

    The top row is the button itself, not shadow.

    Shadows that are too close to the luminosity of their element’s backgrounds will appear too strong. And while this may sound like an overly specific lesson, it’s actually broadly applicable across elements. You know where else you see it?

    Borders

    Let’s put a border on our teal button.

    Our teal button with a subtle border

    Now the way I’ve added this border is something that a bunch of people have thought of: make the border translucent black so that it works on any background color. In this case, I’ve used a single-pixel-wide border of 20%-opacity black.

    However, if I switch the background color to a more standard blue, which is naturally a lot less luminous, that border all but disappears.

    A bright blue button with a nearly invisible border

    In fact, to see it on blue just as much as you can see it on teal, you’ve got to crank up black’s opacity to something like 50%.

    A bright blue button with a more noticeable border

    This is a generalizable rule: when you want to layer black on another color, it needs to be a more opaque black to show up the same amount on less luminous background colors. Where else would you apply this idea?

    Buttons with varying degrees of shadows on a light background and a dark background

    Spoiler alert: shadows!

    Each of these buttons has the same shadow (0 2px 3px) except for different opacities. The top two buttons’ shadows have opacity 20%, and the bottom two have opacity 40%. Note how what’s fine on a white background (top left) is hardly noticeable on a dark background (top right). And what’s too dark on a white background (lower left) works fine on a dark background (lower right).

    Icons

    I want to change gears one more time and talk about icons.

    Button with sharp font and a download icon from FontAwesome

    Here’s the download icon from Font Awesome, my least favorite icon set of all time.

    Close-up of the download icon from the previous button

    I dislike it, not only because it’s completely overused, but also because the icons are really bubbly and soft. Yet most of the time, they’re used in clean, crisp websites. They just don’t fit.

    You can see it works better with a soft, rounded font. I’m less opposed to this sort of thing.

    Softer teal button with the download icon from FontAwesome

    But there’s still a problem: the icon has these insanely small details! The dots are never going to show up at size, and even the space between the arrow and the disk is a fraction of a pixel in practice. Compared to the letterforms, it doesn’t look like quite the same style.

    But what good is my complaining if I don’t offer a solution?

    Let’s create a new take on the “download” icon, but with some different guiding principles:

    • We’ll use a stroke weight that’s equivalent (or basically equivalent) to the text weight.
    • We’ll use corner radii that are similar to the corner radii of our font: squared off for DIN, rounded for Moon.
    • We’ll use a simpler icon shape so the differences are easy to see.

    Let’s see how it looks:

    Black button with sharp font and a download icon with sharp corners, and a softer teal button with a round font and a download icon with softer corners

    I call this “drawing with the same pen.” Each of these icons looks like it could basically be a character in the font used in the button. And that’s the point here. I’m not saying all icons will appear this way, but for an icon that appears inline with text like this, it’s a fantastic rule of thumb.

    Wrapping it up

    Now this is just the beginning. Buttons can take all kinds of styles.

    Various button styles

    But we’ve got a good start here considering we designed just two buttons. In doing so, we covered a bunch of the things that are focal points of my day-to-day work as a UI designer:

    • lighting and shadows;
    • color;
    • typography;
    • consistency;
    • and brand.

    And the lessons we’ve learned in those areas are fundamental to the entirety of UI design, not just one element. Recall:

    • Letterforms are shapes. You can analyze fonts as sets of shapes, not simply as works of art.
    • You should letter-space uppercase text, since most fonts were designed for sentence case.
    • Think in HSB to modify colors.
    • You can find more interesting variations on a “basic” color (like a CSS default shade of blue or red) by tweaking the hue in either direction.
    • Saturation and brightness are levers that you can move in opposite directions to control luminosity.
    • Find colors that match the same descriptors that you would give your typeface and your overall brand.
    • Use darker shadows or black borders on darker backgrounds—and vice versa.
    • For inline icons, choose or design them to appear as though they were drawn with the same pen as the font you’re using.

    You can thank Josh Waitzkin for making me a pedant. I know, you just read an entire essay on buttons. But next time you’re struggling with a redesign or even something you’re designing from scratch, try stripping out all the elements that you think you should be including already, and just mess around with the simplest players on the board. Get a feel for the fundamentals, and go from there.

    Weird? Sure. But if it’s good enough for a grandmaster, I’ll take it.

Search Engine Watch
Keep updated with major stories about search engine marketing and search engines as published by Search Engine Watch.
Search Engine Watch
ClickZ News
Breaking news, information, and analysis.
PCWorld
CNN.com - RSS Channel - App Tech Section
CNN.com delivers up-to-the-minute news and information on the latest top stories, weather, entertainment, politics and more.
CNN.com - RSS Channel - App Tech Section
 

Ако решите, че "как се прави сайт" ръководството може да бъде полезно и за други хора, моля гласувайте за сайта:

+добави в любими.ком Елате в .: BGtop.net :. Топ класацията на българските сайтове и гласувайте за този сайт!!!

Ако желаете да оставите коментар към статията, трябва да се регистрирате.