{"rowid": 1, "title": "Why Bother with Accessibility?", "contents": "Web accessibility (known in other fields as inclusive design or universal design) is the degree to which a website is available to as many people as possible. Accessibility is most often used to describe how people with disabilities can access the web.\n\nHow we approach accessibility\n\nIn the web community, there\u2019s a surprisingly inconsistent approach to accessibility. There are some who are endlessly dedicated to accessible web design, and there are some who believe it so intrinsic to the web that it shouldn\u2019t be considered a separate topic. Still, of those who are familiar with accessibility, there\u2019s an overwhelming number of designers, developers, clients and bosses who just aren\u2019t that bothered.\n\nOver the last few months I\u2019ve spoken to a lot of people about accessibility, and I\u2019ve heard the same reasons to ignore it over and over again. Let\u2019s take a look at the most common excuses.\n\nExcuse 1: \u201cPeople with disabilities don\u2019t really use the web\u201d\n\nAccessibility will make your site available to more people \u2014 the inclusion case\n\nIn the same way that the accessibility of a building isn\u2019t just about access for wheelchair users, web accessibility isn\u2019t just about blind users and screen readers. We can affect positively the lives of many people by making their access to the web easier.\n\nThere are four main types of disability that affect use of the web:\n\n\n\tVisual\n\tBlindness, low vision and colour-blindness\n\tAuditory\n\tProfoundly deaf and hard of hearing\n\tMotor\n\tThe inability to use a mouse, slow response time, limited fine motor control\n\tCognitive\n\tLearning difficulties, distractibility, the inability to focus on large amounts of information\n\n\nNone of these disabilities are completely black and white\n\nExamining deafness, it\u2019s clear from the medical scale that there are many grey areas between full hearing and total deafness:\n\n\n\tmild\n\tmoderate\n\tmoderately severe\n\tsevere\n\tprofound\n\ttotally deaf\n\n\nFor eyesight, and brain conditions that affect what users see, there is a huge range of conditions and challenges:\n\n\n\tastigmatism\n\tcolour blindness\n\takinetopsia (motion blindness)\n\tscotopic visual sensitivity (visual stress related to light)\n\tvisual agnosia (impaired recognition or identification of objects)\n\n\nWhile we might have medical and government-recognised definitions that tell us what makes a disability, day-to-day life is not so straightforward. People experience varying degrees of different conditions, and often one or more conditions at a time, creating a false divide when you view disability in terms of us and them.\n\nImpairments aren\u2019t always permanent\n\nAs we age, we\u2019re more likely to experience different levels of visual, auditory, motor and cognitive impairments. We might have an accident or illness that affects us temporarily. We might struggle more earlier or later in the day. There are so many little physiological factors that affect the way people interact with the web that we can\u2019t afford to make any assumptions based on our own limited experiences.\n\nImpairments might be somewhere between the user and the website\n\nThere are also impairments that aren\u2019t directly related to the user. Environmental factors have a huge effect on the way people interact with the web. These could be:\n\n\n\tLow bandwidth, or intermittent internet connection\n\tBright light, rain, or other weather-based conditions\n\tNoisy environments, or a location where the user doesn\u2019t want to disturb their neighbours with sound\n\tBrowsing with mobile devices, games consoles and other non-desktop devices\n\tBrowsing with legacy browsers or operating systems\n\n\nSuch environmental factors show that it\u2019s not just those with physical impairments who benefit from more accessible websites. We started designing responsive websites so we could be more future-friendly, and with a shared goal of better optimised experiences, accessibility should be at the core of responsive web design.\n\nExcuse 2: \u201cWe don\u2019t want to affect the experience for the majority of our users\u201d\n\nAccessibility will improve your site for all your users \u2014 the usability case\n\nOn a basic level, the different disability groups, as shown in the inclusion case, equate to simple usability goals:\n\n\n\tVisual \u2013 make it easy to read\n\tAuditory \u2013 make it easy to hear\n\tMotor \u2013 make it easy to interact\n\tCognitive \u2013 make it easy to understand and focus\n\n\nTaking care to ensure good usability in these areas will also have an impact on accessibility. Unless your site is catering specifically to a particular disability, where extreme optimisation is most beneficial, taking care to design with accessibility in mind will rarely negatively affect the experience of your wider audience.\n\nExcuse 3: \u201cWe don\u2019t have the budget for accessibility\u201d\n\nAccessibility will make you money \u2014 the business case\n\nBy reducing your audience through ignoring accessibility, you\u2019re potentially excluding the income from those users. Designing with accessibility in mind from the beginning of a project makes it easier to make small inexpensive optimisations as part of the design and development process, rather than bolting on costly updates to increase your potential audience later on.\n\nThe following are excerpts from a white paper about companies that increased the accessibility of their websites to comply with government regulation.\n\n\n\tImprovements in accessibility doubled Legal and General\u2019s life insurance sales online.\n\n\n\n\tImprovements in accessibility increased Tesco\u2019s grocery home delivery sales by \u00a313 million in 2005\u2026 To their surprise they found that many normal visitors preferred the ease of navigation and improved simplicity of the [parallel] accessible site and switched to use it. Tesco have replaced their \u2018normal\u2019 site with their accessible version and expect a further increase in revenues.\n\n\n\n\tImprovements in accessibility increased Virgin.net sales by 68%.\n\n\nStatistics all from WSI white paper: Improve your website\u2019s usability and accessibility to increase sales (PDF).\n\nExcuse 4: \u201cAccessible websites are ugly\u201d\n\nAccessibility won\u2019t stop your site from being beautiful \u2014 the beauty case\n\nMany people use ugly accessible websites as proof that all accessible websites are ugly. This just isn\u2019t the case. I\u2019ve compiled some examples of beautiful and accessible websites with screenshots of how they look through the Color Oracle simulator and how they perform when run through Webaim\u2019s Wave accessibility checker tool.\n\nWhile automated tools are no substitute for real users, they can help you learn more about good practices, and give you guidance on where your site needs improvements to make it more accessible.\n\nAmazon.co.uk\n\nIt may not be a decorated beauty, but Amazon is often first in functional design. It\u2019s a huge website with a lot of interactive content, but it generates just five errors on the Wave test, and is easy to read under a Color Oracle filter.\n\n Screenshot of Amazon website\n Screenshot of Amazon\u2019s Wave results \u2013 five errors\n Screenshot of Amazon through a Color Oracle filter\n\n24 ways\n\nWhen Tim Van Damme redesigned 24 ways back in 2007, it was a striking and unusual design that showed what could be achieved with CSS and some imagination. Despite the complexity of the design, it gets an outstanding zero errors on the Wave test, and is still readable under a Color Oracle filter.\n\n Screenshot of pre-2013 24 ways website design\n Screenshot of 24 ways Wave results \u2013 zero errors\n Screenshot of 24ways through a Color Oracle filter\n\nOpera\u2019s Shiny Demos\n\nDemos and prototypes are notorious for ignoring accessibility, but Opera\u2019s Shiny Demos site shows how exploring new technologies doesn\u2019t have to exclude anyone. It only gets one error on the Wave test, and looks fine under a Color Oracle filter.\n\n Screenshot of Opera\u2019s Shiny Demos website\n Screenshot of Opera\u2019s Shiny Demos Wave results \u2013 1 error\n Screenshot of Opera\u2019s Shiny Demos through a Color Oracle filter\n\nSoundCloud\n\nWhen a site is more app-like, relying on more interaction from the user, accessibility can be more challenging. However, SoundCloud only gets one error on the Wave test, and the colour contrast holds up well under a Color Oracle filter.\n\n Screenshot of SoundCloud website\n Screenshot of SoundCloud\u2019s Wave results \u2013 one error\n Screenshot of SoundCloud through a Color Oracle filter\n\nEducation and balance\n\nAs with most web design, doing accessibility well is about combining your knowledge of accessibility with your project\u2019s context to create a balance that serves your users\u2019 needs. Your types of content and interactions will dictate one set of constraints. Your users\u2019 needs and goals will dictate another. In broad terms, web design as a practice is finding the equilibrium between these constraints.\n\nAnd then there\u2019s just caring. The web as a platform is open, affordable and available to many. Accessibility is our way to ensure that nobody gets shut out.", "year": "2013", "author": "Laura Kalbag", "author_slug": "laurakalbag", "published": "2013-12-10T00:00:00+00:00", "url": "https://24ways.org/2013/why-bother-with-accessibility/", "topic": "design"}
{"rowid": 6, "title": "Run Ragged", "contents": "You care about typography, right? Do you care about words and how they look, read, and are understood? If you pick up a book or magazine, you notice the moment something is out of place: an orphan, rivers within paragraphs of justified prose, or caps masquerading as small caps. So why, I ask you, is your stance any different on the web?\n\nWe\u2019re told time and time again that as a person who makes websites we have to get comfortable with our lack of control. On the web, this is a feature, not a bug. But that doesn\u2019t mean we have to lower our standards, or not strive for the same amount of typographic craft of our print-based cousins. We shouldn\u2019t leave good typesetting at the door because we can\u2019t control the line length.\n\nWhen I typeset books, I\u2019d spend hours manipulating the text to create a pleasurable flow from line to line. A key aspect of this is manicuring the right rag \u2014 the vertical line of words on ranged-left text. Maximising the space available, but ensuring there are no line breaks or orphaned words that disrupt the flow of reading. Setting a right rag relies on a bunch of guidelines \u2014 or as I was first taught to call them, violations! \n\nViolation 1. Never break a line immediately following a preposition\n\nPrepositions are important, frequently used words in English. They link nouns, pronouns and other words together in a sentence. And links should not be broken if you can help it. Ending a line on a preposition breaks the join from one word to another and forces the reader to work harder joining two words over two lines.\n\nFor example: \n\n\n\tThe container is for the butter\n\n\nThe preposition here is for and shows the relationship between the butter and the container. If this were typeset on a line and the line break was after the word for, then the reader would have to carry that through to the next line. The sentence would not flow.\n\nThere are lots of prepositions in English \u2013 about 150 \u2013 but only 70 or so in use.\n\nViolation 2. Never break a line immediately following a dash\n\nA dash \u2014 either an em-dash or en-dash \u2014 can be used as a pause in the reading, or as used here, a point at which you introduce something that is not within the flow of the sentence. Like an aside. Ending with a pause on the end of the line would have the same effect as ending on a preposition. It disrupts the flow of reading.\n\nViolation 3. No small words at the end of a line\n\nDon\u2019t end a line with small words. Most of these will actually be covered by violation \u21161. But there will be exceptions. My general rule of thumb here is not to leave words of two or three letters at the end of a line.\n\nViolation 4. Hyphenation\n\nIn print, hyphens are used at the end of lines to join words broken over a line break. Mostly, this is used in justified body text, and no doubt you will be used to seeing it in newspapers or novels. A good rule of thumb is to not allow more than two consecutive lines to end with a hyphen.\n\nOn the web, of course, we can use the CSS hyphens property. It\u2019s reasonably supported with the exception of Chrome. Of course, it works best when combined with justified text to retain the neat right margin.\n\nViolation 5. Don\u2019t break emphasised phrases of three or fewer words\n\nIf you have a few words emphasised, for example:\n\n\n\tHe calls this problem definition escalation\n\n\n\u2026then try not to break the line among them. It\u2019s important the reader reads through all the words as a group.\n\nHow do we do all of that on the web?\n\nAll of those guidelines are relatively easy to implement in print. But what about the web? Where content is poured into a template from a CMS? Well, there are things we can do. Meet your new friend, the non-breaking space, or as you may know them: \u00a0.\n\nThe guidelines above are all based on one decision for the typesetter: when should the line break? \n\nWe can simply run through a body of text and add the \u00a0 based on these sets of questions:\n\n\n\tAre there any prepositions in the text? If so, add a \u00a0 after them.\n\tAre there any dashes? If so, add a \u00a0 after them.\n\tAre there any words of fewer than three characters that you haven\u2019t already added spaces to? If so, add a \u00a0 after them.\n\tAre there any emphasised groups of words either two or three words long? If so, add a \u00a0 in between them.\n\n\nFor a short piece of text, this isn\u2019t a big problem. But for longer bodies of text, this is a bit arduous. Also, as I said, lots of websites use a CMS and just dump the text into a template. What then? We can\u2019t expect our content creators to manually manicure a right rag based on these guidelines. In this instance, we really need things to be automatic.\n\nThere isn\u2019t any reason why we can\u2019t just pass the question of when to break the line straight to the browser by way of a script which compares the text against a set of rules. In plain English, this script could be to scan the text for:\n\n\n\tPrepositions. If found, add \u00a0 after them.\n\tDashes. If found, add \u00a0 after them.\n\tWords fewer than three characters long that aren\u2019t prepositions. If found, add \u00a0 after them.\n\tEmphasised phrases of up to three words in length. If found, add \u00a0 between all of the words.\n\n\nAnd there we have it.\n\nA note on fluidity\n\nAn important consideration of this script is that it doesn\u2019t scan the text to see what is at the end of a line. It just looks for prepositions, dashes, words fewer than three characters long, and emphasised words within paragraphs and applies the \u00a0 accordingly regardless of where the thing lives. This is because in a fluid layout a word might appear in the beginning, middle or the end of a line depending on the width of the browser. And we want it to behave in the right way when it does find itself at the end.\n\nSee it in action!\n\nMy friend and colleague, Nathan Ford, has written a small JavaScript called Ragadjust that does all of this automatically. The script loops through a webpage, compares the text against the conditions, and then inserts \u00a0 in the places that violate the conditions above.\n\nYou can get the script from GitHub and see it in action on my own website.\n\nSome caveats\n\nAs my friend Jon Tan says, \u201cThere are no rules in typography, just good or bad decisions\u201d, and typesetting the right rag is no different. \n\n\n\tThe guidelines for the violations above are useful for justified text, too. But we need to be careful here. Too stringent adherence to these violations could lead to ugly gaps in our words \u2014 called rivers \u2014 as the browser forces justification.\n\tThe violation regarding short words at the end of sentences is useful for longer line lengths, or measures, of text. When the measure gets shorter, maybe five or six words, then we need to be more forgiving as to what wraps to the next line and what doesn\u2019t. In fact, you can see this happening on my site where I\u2019ve not included a check on the size of the browser window (purposefully, for this demo, of course. Ahem).\n\tThis article is about applying these guidelines to English. Some of them will, no doubt, cross over to other languages quite well. But for those languages, like German for instance, where longer words tend to be in more frequent use, then some of the rules may result in a poor right rag.\n\n\nMarginal gains\n\nIn 2007, I spoke with Richard Rutter at SXSW on web typography. In that talk, Richard and I made a point that good typographic design \u2014 on the web, in print; anywhere, in fact \u2014 relies on small, measurable improvements across an entire body of work. From heading hierarchy to your grid system, every little bit helps. In and of themselves, these little things don\u2019t really mean that much. You may well have read this article, shrugged your shoulders and thought, \u201cHuh. So what?\u201d But these little things, when added up, make a difference. A difference between good typographic design and great typographic design.\n\n \n\nAppendix\n\nPreposition whitelist\n\naboard\nabout\nabove\nacross\nafter\nagainst\nalong\namid\namong\nanti\naround\nas\nat\nbefore\nbehind\nbelow\nbeneath\nbeside\nbesides\nbetween\nbeyond\nbut\nby\nconcerning\nconsidering\ndespite\ndown\nduring\nexcept\nexcepting\nexcluding\nfollowing\nfor\nfrom\nin\ninside\ninto\nlike\nminus\nnear\nof\noff\non\nonto\nopposite\noutside\nover\npast\nper\nplus\nregarding\nround\nsave\nsince\nthan\nthrough\nto\ntoward\ntowards\nunder\nunderneath\nunlike\nuntil\nup\nupon\nversus\nvia\nwith\nwithin\nwithout", "year": "2013", "author": "Mark Boulton", "author_slug": "markboulton", "published": "2013-12-24T00:00:00+00:00", "url": "https://24ways.org/2013/run-ragged/", "topic": "design"}
{"rowid": 12, "title": "Untangling Web Typography", "contents": "When I was a carpenter, I noticed how homeowners often had this deer-in-the-headlights look when the contractor I worked for would ask them to make tons of decisions, seemingly all at once.\n\nSquare or subway tile? Glass or ceramic? Traditional or modern trim details? Flat face or picture frame cabinets? Real wood or laminate flooring? Every day the decisions piled up and were usually made in the context of that room, or that part of that room. Rarely did the homeowner have the benefit of taking that particular decision in full view of the larger context of the project. And architectural plans? Sure, they lay out the broad strokes, but there is still so much to decide.\n\nTypography is similar. Designers try to make sites that are easy to use and understand visually. They labour over the details of line height, font size, line length, and font weights. They consider the relative merits of different typographical scales for applications versus content-driven sites. Frequently, designers consider all of this in the context of one page, feature, or view of an application. They are asked to make a million tiny decisions.\n\nSometimes designers just bump up the font size until it looks right.\n\nI don\u2019t see anything wrong with that. Instincts are important. Designing in context is easier. It\u2019s OK to leave the big picture until later. Design a bunch of things, and then look for the patterns. You can\u2019t always know everything up front. How does the current feature relate to all the other features on the site? For a large site, just like for a substantial remodel, the number of decisions you would need to internalize to make that knowable would be prohibitively large.\n\nWhen typography goes awry\n\nI should be honest. I know very little about typography. I struggle to understand vertical rhythm and the math in Tim Ahrens\u2019s talks about the interaction between type design and rendering technology kind of melted my brain. I have an unusual perspective because I\u2019m not the one making the design decisions, but I am the one implementing them and often cleaning up when a project goes off the rails.\n\nI\u2019ve seen projects with thousands of font-size declarations and headings. One project even had over ten thousand margin declarations. So while I appreciate creative exploration, I\u2019m also eager to establish patterns in typography and make sure we aren\u2019t choosing not to choose. Or, choosing all the things.\n\nAnalyzing a site\u2019s typography\n\nMost of my projects start out with an evaluation of the client\u2019s existing CSS. I look for duplication in the CSS by using Grep, though functionality is landing soon in CSS Lint to do the same thing automatically. The goal is to find the underlying missing abstractions that, once in place, would allow developers to create new functionality without needing to write additional CSS. In addition to that, my team and I would comb through each site (generally, around ten pages is enough to get the big picture), and take screenshots of each of the components we found.\n\nIn this way, we could look for subtle visual differences that were unlikely to add value to the user. By correcting these differences, we could help make the design more consistent, and at the same time the code leaner and more performant. Typography is much like a homeowner who chooses to incorporate too many disparate design elements, pairing a mid-century modern sofa with flowered country cottage curtains. Often the typography of a site ends up collecting an endless array of new typefaces as the site\u2019s overall styles evolve. Designers come and go on a project, and eventually no one can remember how the 16px Verdana got into the codebase.\n\nAutomation\n\nWe used to do this work by hand. It was incredibly tedious. We\u2019d go through the site, taking screenshots and meticulously documenting the style information we found. We didn\u2019t have to do that many times before it became incredibly clear that the task needed to be automated. So we built a little tool called the Type-o-matic that could do it for us.\n\nTo try it on your site:\n\n\n\tDownload and install the Firebug extension to Firefox\n\tDownload and install the Type-o-matic extension to Firebug (I know, I fully intend to port it to Chrome)\n\tNow, visit the site you\u2019d like to test\n\tRight click and choose Inspect element with Firebug\n\tNow click on the Typography tab\n\tClick Persist\n\tClick Generate Report\n\tChoose which pages to analyze (we\u2019ve found that ten is a good number to get the big picture, but you can analyze as many as you\u2019d like\u200a\u2014\u200ait will even work on just one page!)\n\tNow navigate to other pages, and on each subsequent page, click Generate Report\n\tThe table of results can be a bit difficult to interact with, so you can always click Copy to clipboard, and copy the results (JSON).\n\n\n \n \nA screenshot of Type-o-matic in action\n\n\nWhat does this data mean?\n\nWhen you\u2019ve analyzed as many pages or different views as you\u2019d like, you\u2019ll start to see some interesting patterns emerge in the data. In the right-hand column, you\u2019ll see examples of how each kind of typography we found has been used in a real context on your site. It is organized by color and then by size so you can easily see how you are using typography.\n\nThe next thing you\u2019ll want to take a look at is in the first column, called \u201cCount\u201d. We\u2019ve counted how many times you\u2019ve used each combination of typographical styles. This can be incredibly helpful when deciding which styles were intentional, versus one-off color pick errors or experiments that never got removed from the code base. If you\u2019ve used one color blue 1,400 times, and another just 23, it\u2019s pretty obvious which is more in line with broader site-wide styles.\n\nConsistency before perfection\n\nIt can be really tempting to try to make everything perfect\u200a\u2014\u200ato try to make every decision final. When you use the data you can collect from this tool, I\u2019d recommend trying to get to consistent before you try to make things perfect. Stop using fifteen different shades of blue type first, and then if you want to change to a new blue, go for it! You\u2019ll be able to make design changes much more easily once you\u2019ve reduced the total number of typographical styles you rely on.\n\nLower the importance of the decisions you are making. Our sites, like ourselves, are always a work in progress. Or, as a carpenter I used to work with said, \u201cYou\u2019re not building a fucking piano.\u201d We\u2019re not building houses. We can choose one typeface today and a different one tomorrow. It is OK to experiment. Be brave.", "year": "2013", "author": "Nicole Sullivan", "author_slug": "nicolesullivan", "published": "2013-12-20T00:00:00+00:00", "url": "https://24ways.org/2013/untangling-web-typography/", "topic": "design"}
{"rowid": 13, "title": "Data-driven Design with an Annual Survey", "contents": "Too often, we base designs on assumptions that don\u2019t match customer perspectives. Why? Because the data we need to make informed decisions isn\u2019t available.\n\nImagine starting off the year with a treasure trove of user data that can be filtered, sliced, and diced to inform new UI designs, help you discover where users struggle the most, and expose emerging trends in your customers\u2019 needs that could lead to new features. Why, that would be useful indeed. And it\u2019s easy to obtain by conducting an annual survey.\n\nAnnual surveys may seem as exciting as receiving socks and undies for Christmas, but they\u2019re the gift that keeps on giving all year long (just like fresh socks and undies). I\u2019m not ashamed to admit it: I love surveys! Each time my design research team runs a survey, we learn so much about customer motivations, interests, and behaviors. \n\nSurveys provide an aggregate snapshot of your users that can\u2019t easily be obtained by other research methods, and they can be conducted quickly too. You can build a survey in a few hours, run a pilot test in a day, and have real results streaming in the following day. Speed is essential if design research is going to keep pace with a busy product release schedule. \n\nSurveys are also an invaluable springboard for customer interviews, which provide deep perspectives on user behavior. If you play your cards right as you construct your survey, you can capture a user ID and an email address for each respondent, making it easy to get in touch with customers whose feedback is particularly intriguing. No more recruiting customers for your research via Twitter or through a recruiting company charging a small fortune. You can filter survey responses and isolate the exact customers to talk with in moments, not months.\n\nI love this connected process of sending targeted surveys, filtering the results, and then \u2014 with surgical precision \u2014 selecting just the right customers to interview. Not only is it fast and cheap, but it lets design researchers do quantitative and qualitative research in a coordinated way. Aggregate survey responses help you quantify the perspectives of different user segments, and interviews help you get into the heads of your customers.\n\nAn annual survey can give your team the data needed to make more informed designs in the new year. It all starts with a plan.\n\nPlanning your survey\n\nBefore you start jotting down questions to ask users, spend some time thinking about the work your team will be doing in the coming year. Are you planning new mobile apps or a responsive redesign? Then questions about devices used and behaviors around mobile devices might be in order. Rethinking your content strategy? Then you might want to ask a few questions about how your customers consume content.\n\nYou can\u2019t predict all of the projects you\u2019ll be working on in the coming year, but tuck a couple of sections in your survey about the projects you\u2019re certain about. This will give you the research you need to start new projects with solid foundational data.\n\nGoogle Drive is a great place to start collaboratively building survey questions with colleagues. Questions that seem crystal clear in your head get challenged, refined, or even expanded quickly when the entire team can chime in. \n\nAs you craft your survey, try to consider how you\u2019ll filter it once all of the data is compiled. Do you need to see responses by industry, by age of an account, by devices used, or by size of company? Adding the right filter questions can help you discover fascinating patterns in user segments. Filtering on responses to a few questions can surface insights like: customers in non-profit companies with more than 100 employees are 17% more likely to use an Android phone and are most attracted to features A, D, and F. A designer working on the landing page for a non-profit would love to have concrete information like this. Filter questions are key, so consider them carefully. But don\u2019t go overboard \u2014 too many of them and you\u2019ll start to hurt your survey response rate.\n\nMultiple choice questions are the heart of most surveys because respondents can complete them quickly, which increases response rate, and researchers can analyze them without a lot of manual categorization. Open text field questions are valuable too, but be careful not to add too many to your survey. You\u2019ll hate yourself after the survey\u2019s done and you have to sort through and tag thousands of open responses so patterns become visible. Oy vey!\n\nAn open-ended question works well towards the end of the survey. At this point respondents have a lot of topics swirling around in their head and tend to say weird things that will pique your interest. This is where you\u2019ll find the outliers who are using your product. They\u2019ll be fascinating to interview, and on occasion will help you see your work in a brand new way.\n\nConclude your survey with a question asking permission to get in touch for a followup interview so you don\u2019t pester people who want to be left alone. \n\nWith your questions nailed down, it\u2019s time to build out that survey and get it ready for sending!\n\nBuilding your survey\n\nThere are dozens of apps you could use to build your survey, but SurveyMonkey is the one that I prefer. It lets you pass in variables for each respondent such as user ID and email address. Metadata about respondents is essential if you\u2019re going to do any follow-up interviews with your customers in the coming year. SurveyMonkey also makes it easy to set up question logic, showing questions to customers only if they responded in a certain way to a prior question. This helps you avoid asking irrelevant questions to some respondents.\n\nDetermining survey recipients\n\nOnce you\u2019ve chosen a survey tool and entered all of your questions, you need to gather a list of recipients. Your first instinct will be to send it to everyone. You might say, \u201cI need maximum response and metric shit tons of data!\u201d But this is rarely the best approach \u2014 broad distribution almost always leads to lower response rates, increased noise, and decreased signal in your data. Are there subsets of customers you could send to, like only those who are active, those who are paying, or have been with you for a certain length of time? Talk to the keepers of your customer database and see how they can segment it so you can be certain you\u2019re talking to just the people who will have the most relevant responses for your needs. \n\nIf you want to get super nerdy when finding the right customer sample to survey, use a [sample size calculator]. Sampling is a deep subject best explored in other articles. \n\nCrafting your survey email\n\nAfter focusing your energies on writing and building your survey, the email asking your customers to respond seems almost trivial, but it will greatly influence your response rate. Take great care when writing your subject line and the body of the email. If you can pull it off, A/B testing subject lines can greatly improve the open rate of your email and click-through to your survey. My design research team has seen a ~10% increase in open and click rates when we A/B tested. We\u2019ve found that personalizing subject lines and greetings with the recipients name (ie. \u201cHey, Aarron. How can we make our app work better for you?\u201d) gave us the best response rates. Your mileage may vary.\n\nThe tone of your email is important \u2014 be friendly, honest, and to the point. Those that are passionate about your product will be happy to share their perspective. Writing a survey email that people will actually respond to ain\u2019t easy \u2014 in fact, they\u2019re almost always annoying. But Ben Chestnut found a non-annoying way to send a survey email and improve response rates.\n\nThe email sent for the 2013 MailChimp survey let customers know what we\u2019d been up to in the previous year, and invited feedback on what we should work on in the coming year.\n\nThe link to your survey should be a clear call to action. A big button with a label like \u201cAnswer a few questions\u201d generally does the trick. The URL linking to the survey will need to include some variables like user ID and email. It might look something like this if you\u2019re using SurveyMonkey:\n\nhttp://surveymonkey.com/s/somesurveyid/?uid=*|UID|*&email=*|email|*\n\nAs each email is sent, the proper data will be populated in the variables, passing it on to the survey app for inclusion in each response. This is the magic that will help you pinpoint customers to interview down the road, so take special care to test that all is working before sending to all recipients. How you construct the survey link will vary depending on what survey tool and email service provider you use, so don\u2019t take my example as gospel. You\u2019ll need to read the documentation for your survey and email apps to set things up properly.\n\nPilot before sending\n\nBy now, you\u2019ve whipped yourself into a fever pitch over your brilliant survey and the data you hope to collect. Your finger is on the send button, poised for action, but there\u2019s one very important thing to do before you send to the entire list of customers: send a pilot email. How do you know if your questions are clear, your form logic is sound, and you\u2019re passing variables from the email to the survey properly? You won\u2019t, unless you send to a small segment of your recipients first. \n\nThe data collected in your pilot will make plain where your survey needs refinement. This data won\u2019t be used in your final analysis, as you\u2019re probably going to make a few changes to your questions.\n\nSend the pilot survey to enough people that you can really stress test the clarity of the questions and data you\u2019re gathering, while considering how much data can you comfortably throw out. If you\u2019re sending your final survey to a few thousand people, you might find a couple of hundred recipients for your pilot will give you enough insight into what to improve while leaving the vast majority of the recipients for your final survey.\n\nAfter you\u2019ve sent your pilot, made your survey adjustments, and ensured the variables are being passed from your email into the survey app, you\u2019re ready to send to the remainder of your customers. This is your moment of glory!\n\nAnalyzing your results\n\nAfter a couple of weeks you can probably safely close the survey so no other responses come in as you transition from data gathering to data analysis. Any survey app worth its salt will chart responses to your multiple choice questions. Reviewing these charts is a great place to start your analysis. Is there anything particularly interesting that stands out? Jot down some of your observations. I like to print screenshots of the charts for each question, highlighting areas of interest. These prints become a particularly handy reference point for the next step in your analysis. \n\nPrinting results from a survey makes comparing different customers easy.\n\nViewing aggregate data about all responses is interesting, but the deltas between different types of customers are where the real revelations happen. Remember those filter questions you added to your survey? They\u2019re the tool that\u2019ll help you compare customer segments.\n\nMost survey apps will let you filter the data based on response to a question. If the one you\u2019re using doesn\u2019t, you can always export your data and create pivot tables in Excel. Try filtering your data based on one of your filter questions, such as industry, company size, or devices used. Now compare those printed screenshots of baseline responses to the filtered data. Chances are you\u2019ll see some significant differences in how each group responded to your questions, giving you clues about the variance in interests and motivations in customer segments and a leg up as you work on future design projects. \n\nOpen-ended responses are equally interesting, but much more time-consuming to analyze. Yes, you need to read through thousands of responses, some of which are constructive and some of which are not. Taking the time to tag each open response will help you see trends and filter out the responses that are unhelpful.\n\nUnlike questions with predefined answers, open-ended responses let users express unique ideas and use cases you may not be looking for. The tedium of reading thousands of response is always cut by eureka moments when users tell you something fascinating that changes your perspective on your app. These are the folks you want to pull out for follow-up interviews. Because you\u2019ve already captured their email addresses when you set up your survey and your email, getting in touch will be a piece of cake.\n\nFilter, compare, interview, and summarize; then share your findings with your colleagues. Reports are great for head honchos, but if you want to really inform and inspire, create a video, a poster series, or even a comic to communicate what you\u2019ve learned. Want to get really fancy? Store your survey results in a centrally accessible location so anyone in your company can research and discover the insights they need to make more informed designs. \n\nGood design researchers discover valuable insights. Great design researchers turn those insights into stories.\n\nConclusion\n\nAs we enter the new year, it\u2019s a great time to reflect on the work we\u2019ve done in the past and how we can do better in the future. Without a doubt, designers working with a foundation of insights about customers can make more effective UIs. But designers aren\u2019t the only ones who stand to gain from the data collected in an annual survey\u2014anyone who makes things for or communicates with customers will find themselves empowered to do better work when they know more about the people they serve. The data you collect with your survey is a fantastic holiday gift to your colleagues, one that they\u2019ll appreciate throughout the year.", "year": "2013", "author": "Aarron Walter", "author_slug": "aarronwalter", "published": "2013-12-13T00:00:00+00:00", "url": "https://24ways.org/2013/data-driven-design-with-an-annual-survey/", "topic": "design"}