The first rule of content management systems is that you’re using the wrong one. Using Wordpress? You’re a fifth-grader running a coloring-contest blog. Drupal? You should be using WordPress. An enterprise solution? You’re an open-source Judas.
This is how it often feels, at least, if you hang around the rough parts of web-dev Twitter or loiter in blog comments. But the real first rule of content management systems is that it’s not so much which CMS you use as how you use it. A bottom-drawer content management system implemented with care will often be much more useful than a top-drawer system pulled straight out of the box and shoved onto your server.
As a guiding text for implementing content management systems, I’m going to ruin your day by presenting a quote from Fyodor Dostoyevsky’s The Brothers Karamozov:Man is tormented by no greater anxiety than to find someone quickly to whom he can hand over that great gift of freedom with which the ill-fated creature is born.
For our purposes, Dostoyevsky meant that the nicest thing you can tell your CMS users is that they don’t have the freedom to mess things up. When implementing a CMS, try to give your users exactly the level of freedom they need—but, when in doubt, err on the side of giving them slightly too much.
That’s the broad view of things, but it’s trickier once you get into the details—the fields and WYSIWYGs and permissions. What makes it even trickier is that, if you’re thinking about CMS implementation, you’re probably in one of two very different situations:
- You’re creating a new site and the world is your content-management-system-implementation oyster.
- You’re managing or refurbishing an existing site and the content management system setup brings you great sadness.
Although these situations each have their own individual troubles—which we’ll get to—they’re both governed not just by the first rule of CMSes but also by the second rule: no two CMS implementations should be exactly alike. Each site will have its own needs, and the CMS should be customized to match those needs.
With that in mind, instead of a set of prescriptions, I offer a handful of questions you might ask to limit your users’ freedom.Can this element have its own field?
With many content management systems—WordPress and Drupal spring to mind—content types come default with a big text field where anything can be entered. Anything you want! Consider limiting this freedom as much as possible by giving discrete elements discrete inputs.
Every element on your page that serves a purpose distinct from other elements should have its own input field. In a staff directory, a person’s job title and name ought to have separate input fields, even if they appear next to each other on the page. The photo should have a separate image-uploader field. The office hours in the sidebar should have their own field. The contact info beneath the office hours should be its own field as well. Remember: just because two items are near each other visually does not necessarily mean they’re related enough to share a field.
For those who think partitioning every element into its own field is excessive and unnecessary, remember that it gives you flexibility for the future. As Karen McGrane points out, breaking your content into chunks gives your content structure, and that structure gives you, the web developer, freedom. It gives you the freedom to make small design changes—like moving the contact info above the office hours—with just a quick bit of backend work. And it also gives you the freedom to make large changes to how that content is displayed, whether it’s on the site you’re working on, another iteration of that site, or a totally different product that taps into that site’s content. That’s the sort of freedom you want.Can this field be more restrictive?
It’s a good idea to use the most restrictive field you can for an element. If you’re going to use a big text field, ask yourself: could you make this plain text instead of anything-goes HTML? If it’s an image, consider using an image-uploader field rather than a general media field. If it’s a person’s first name, use a plain text field. If it’s a day of the week, make users select one of the seven days of the week. Don’t make them invent their own.
Restricting fields makes it easier for the people using the CMS to do their jobs correctly and quickly, and it can also help bring an editorial and visual consistency to the site. Having users select the day of the week from an array instead of typing it into a text field ensures that all days of the week will always be spelled correctly, and it keeps people from having to pause and remember whether the house style is to abbreviate days of the week or to spell them out. Also, if the house style changes, you can make a small tweak on the backend instead of changing the text in every day-of-the-week input across the site.
Restricting fields is also one of the most significant ways you can let CMS users know that they can’t mess things up. By using a restricted image field, you implicitly assure people that if they try to upload the wrong type of image file, the CMS will reject it. Likewise, using plain text instead of a WYSIWYG or rich text is a way of letting users know that they can copy text from wherever and paste it in without any problems, and that they don’t need to worry about styling the text.
However, there are a few areas where being restrictive will probably cause more harm than good. For example, it’s probably going to be more trouble than it’s worth to have a strict character limit on a text field. Even if it’s a field for, say, someone’s first name in a staff directory, you’re not going to cause much harm by having a character limit of 200 instead of 40. You also don’t stand to gain much by being too strict with so-called special characters. Allowing them might mean a slightly larger font file, but for most sites it’s not possible or advisable to avoid words with diacritics.Does the WYSIWYG need this button?
Out of the box, WYSIWYG editors sometimes come with a few dozen buttons. Some are classics like bold, italic, and strikethrough. Some are leftovers from word-processing days, like justify text and background color. Some are inscrutable: looking at the full set of buttons on CKEditor, I see a button that looks like a T walking a baby x on a leash, a globe, and three variations on a clipboard.
Most content management systems let you edit which buttons appear in the WYSIWYG. Do it! If the field is a text field that will need an occasional link, get rid of all the buttons except the link button. If a text area only needs basic text formatting, leave the buttons for bold and italic, and maybe ordered and unordered lists and links, if it’s possible they’ll be needed.
For general text fields—like product descriptions or event summaries—I like to keep those same few formatting options. I often omit the button for underlining—it’s best to restrict that style to links. I always include the link button because links make the web go ’round.
For longer texts like articles, I also include buttons for formatting block quotes, punctuation like em dashes (not everyone knows the keyboard shortcut), and maybe indent and outdent options if it’s possible that users will need to create lists within lists. I also usually create buttons that allow users to apply markup like headings, and I label them something like “Heading 2” rather than “h2,” since most CMS users will be more proficient in English than HTML. I generally avoid buttons that change font, size, and color or background color, which are best set through CSS to keep form and content distinct.
Those are just some starting points. Beyond that, know your editorial team. If writers like to sarcastically use strikethroughs, give them a button for it. Or if you only want editors to be able to sarcastically strike through things their writers write, only let users with editor permissions have a strikethrough button.
View-source buttons can be a difficult call. My general rule of thumb is that editor- or administrator-level users should have a view-source button if they know HTML. Funky things sometimes happen in WYSIWYGs—you’ll make something a heading and the whole paragraph will turn into a heading—and users who know HTML will find it easier to look at the source code and fix the markup.
You should use WYSIWYGs as basic formatting tools, not design tools. WYSIWYGs sometimes have a bad rep because users and clients want to treat them like word processors, a tool that gives people full (if clunky) control of how things look. They’re called What You See Is What You Get, after all. But if you restrict the WYSIWYG to its essential functions, you can assure users that what shows up on the website will look great every time, and they won’t have to worry about what they see or what they get.Does the user need this permission?
Restricting a user’s permissions is the easiest way to make sure they can’t accidentally destroy the site. Most content updaters or editors won’t need to mess around with permalinks, so don’t give them permission to do so. If a user is only editing existing content, you should avoid giving them permission to create or delete pages. And so on.
Here’s something you can do to figure out what permissions a user will actually need: when you create a new user, turn off all permissions. Log in as that user in one browser, and then log in as an admin in another. On the non-admin account, go about accomplishing all the tasks that user will need to do and, as you go along, add permissions from the admin account as needed.How can I hard-code accessibility into the site?
What’s accessibility doing in an article about implementing content management systems and 19th-century Russian novelists? Well: you can make your site’s code as accessible as possible, using the coolest ARIA roles and testing everything on an actual screen reader, but if your content updater creates grey text on a dark grey background or doesn’t care about alt text, your hard work goes to waste. You can’t prevent all of this, but you can at least make it slightly more difficult to mess up the site’s accessibility.
Even if you’re not ultimately the person uploading an image, for example, you can often still hard-code alt text right into the backend. If you’re designing a staff directory, for example, you can pull the alt text from other fields, like this:<img src="cool-guy-optimized.jpg" alt="<?php echo name_field; ?>, the <?php echo job_title_field; ?> of Cool Business Guys, LLC" / >
That way, alt text will always be there—and it’ll even be useful and accurate—and the content updater won’t have to worry about it.
Or: if you’ve given discrete elements discrete input fields, you can guarantee that everything has the proper, accessible structure. Most content management systems do this naturally for h1 headings—they wrap your page title in an h1 unless you code otherwise. You can extend this functionality to other items. Put that callout text in an aside. Put that time in a time.How effortless can I make image-uploading?
As a web developer, you’re likely up to date on all the latest image technology. You know when you should use img srcset (most of the time) and when you should use picture (only when you’re doing something art-direction-ish). You know the best image-optimizing plugin that’s only available from this one plugin site you found that one time. When someone asks you to Photoshop an SVG, you’ll tell them it’s not called Vectorshop, and you’ll laugh at your own joke and resolve to have outdoor time this weekend.
Your content updater probably does not know these things. Even if you yourself are the content updater, you do not want to have to remember this when you are just trying to upload a picture of your arugula. That’s why you should code all of this into your system. When possible, every image on your site should have its own image-uploader field, and you should be able to drop an image of any size into that uploader field and have it resized, optimized, and put into the appropriate responsive markup.
All of this content management system stuff takes some work—but you can do it. I believe in you. I saw how robust your arugula was.A few other questions you might find yourself asking I have an absolutely impossible CMS implementation problem. Any ideas?
Let me guess: you’re dealing with articles that have pictures and embedded Tweets and maybe even an interactive graph, and the person creating the article is going to need to reposition those elements for every article. That’s one of the trickiest and most common CMS issues. Let me point you to Jeff Eaton’s “The Battle for the Body Field” for some answers. That sort of problem is absolutely solvable with a CMS, and while my guidelines will send you in the right direction, Jeff outlines some ways you can approach that specific case.
If the problem you face is that you want your final CMS implementation to make all who use it proclaim its brilliance, check out Eileen Webb’s “Training the CMS.” Among other things, she has some awesome ideas for making the actual setup of your editorial pages helpful and easy to use.
Sometimes when you get into what seems like an intractable problem with a CMS, it’s because you’re thinking of how your content will appear on one particular page and not within your overall content/data structure. For that, check out Karen McGrane’s talk “Content in a Zombie Apocalypse.” She’ll help you rethink content modeling, and also kicks some dirt on WYSIWYGs, which is fun.Okay, great—but where do I start with all of this?
At the beginning, I mentioned that CMS implementations come in one of two types: with the first, you’re starting fresh, the world is your delicate cold little oyster, you’re not going to make the same mistakes this time; with the second, you’re refurbishing a CMS, things are broken, love isn’t real, God is dead, and so on. How you get started with asking these CMS questions depends on which situation you’re in.
If you’re in situation one, life is much easier in some ways. Keeping these questions in mind when you’re putting your design into CMS templates will make the field-related parts easier, and starting with reasonable WYSIWYG buttons, a functional image-uploading system, and built-in accessibility will give the site a solid base that you can tinker with later on.
The hard part is predicting exactly how the site will be used. It’s easy to think that you can replace the sidebar field with a location field and a contact information field, but what if someone wants to put a special message about holiday closures in the sidebar but they don’t have a place for it? If you’re redesigning a new site, I recommend using the gnarliest, most edge-case-y content on the current site for your sample content. That can often keep you from limiting things too much. If the site doesn’t have any content yet, that’s not really the best way to build a website, but if you live in the real world and have to do it anyway, you’ll likely have to err on the side of giving users too much freedom, and then restrict it later if you can.
If you’re in situation two, buck up. You don’t need to demolish your current site to implement all of this—you can slide into it gradually. Some parts are easier to do than others, and some of it’s more important. If you have a free afternoon, you can adjust all the user permissions appropriately and remove buttons from the WYSIWYG. You may even be able to adjust your image-uploading system without breaking images already on the site. But it’ll likely be more difficult to divide discrete elements into discrete fields or to restrict field types. Databases are sensitive like that. But the next time you create a new content type, you can make sure it has discrete fields and that they’re restricted appropriately. Even doing little bits and pieces of this can make your CMS more effective.But what about politics?
For both situations—really, for most web-development situations—the technical part will likely be easier than the political part. How do you sell the client or your boss on spending an extra week or so on making the CMS better? Did you pick a bad CMS or something?
In my experience, not only is it possible to get approval to spend time on this, but you can get outright gratitude. I recommend making a financial case: spending x number of hours on the CMS now will save five times as many hours later. The more specific, the more compelling. For example, if you estimate 16 hours of work to implement an image-uploading system that takes care of all the image sizes behind the scenes, you can then estimate how long it would take for the content editor to save three different image sizes and optimize and upload them every time an image needs to be changed.
If that doesn’t work, here are a few sound bites you can use:
- “This is a special, one-of-a-kind organization, so we need to spend a little more time making sure the CMS meets its unique needs.”
- “You have talented staff doing important work, and we don’t want them to have to spend their valuable time troubleshooting errors on the website.”
- “We want to make sure there’s no way you can do anything to mess up the site. That way you’ll never have to pay us again.”
- “See this page where someone uploaded a dog GIF and typed some flashing red text? I can prevent that from ever happening again.”
Just don’t quote Dostoyevsky and expect it to go over well.
Government snooping. Identity theft. Sale of personal data. Privacy is out there in a big way. But it’s not in here, meaning on most product development teams.
I’m a member of those teams, as an experience designer with a foot in strategy and user research. I’m also a longtime public radio reporter (tech was a big topic of mine), so curiosity is my strong suit. I noticed that, at the agencies and tech companies I’ve worked for, privacy never seemed to be discussed much. And, as reporters do, I wondered why.
Making the case for bringing privacy into the product development process isn’t easy, especially since finding examples of successful companies that value privacy isn’t easy. In fact, the opposite is true—the web is littered with products or design methods that tried to promote privacy and failed, or that gained only small, niche adoption (here, here, here, here, here, and here). Knock-on effects are that privacy sometimes sits on the back burner.
There are good reasons for this: so many factors are at play in developing web products, and privacy gives us just one more thing to think about. But designers and product owners can and should work privacy into the process, and I’ll explain some ways we can do that.The basics of privacy
Privacy is one thing, but security is another—and the latter is something that many companies do care about. If users’ information gets stolen, or governments snoop on it, that’s bad for trust and reputation and hence bad for business. When companies like Apple and Facebook call for security measures or legislation, or encrypt their data, it’s because they care about secure user data.
But, even companies that do encrypt (voluntarily—there are no laws around this right now) receive data in an unencrypted fashion, so there’s nothing to stop them from making the most of it for their own purposes, or selling that information to other companies (some secure, some not).
There are many flavors of online privacy violations. Last year’s Uber episode, in which the company singled out a journalist and tracked her movements without consent, was a violation of policies and may allow for legal recourse. (Other companies likely engage in these sorts of activities, but we rarely hear about it. Of course, the Facebooks and Googles of the world have access to all the messages their users write.)
Then there’s the murky area of things that aren’t technically illegal, but are questionable, like companies collecting information on behavior that users are not aware of. Cookies are one example of that. Of bigger concern is something like Target predicting a woman was pregnant before she knew it herself. And, finally, there’s the selling of that data—to advertisers, for example, or during an acquisition.
This data is typically made up of a combination of user-entered values and behavior tracked in the background (a.k.a. analytics): geographic location, clicks, time on a certain page, etc. Many companies claim they don’t care about individually identifying features, but instead, about user behavior or information in aggregate. However, anonymized or partially anonymized data can often be traced to individuals—take, for example, AOL’s search data leak of 2006. One user who had searched for information on murdering his wife was identified—but he turned out to be a TV writer who worked for a crime show.Making a case for privacy Community-building requires trust
If a business wants to build some sort of community or audience, it needs to establish trust. You can make the case that privacy will help, and include product requirements and user stories around privacy.Legislation will come
Following privacy legislation isn’t easy, but things are moving. American states pursue their own laws piecemeal, and federal legislation is outdated, though Congress talks about it more and more. Meanwhile, Europe is ahead of the rest of the world when it comes to online privacy laws. If your company has designs on going global, all users will likely be stored in the same online bucket—meaning European privacy protections will need to be extended to all of them. Wherever you do business, being proactive now will save headaches later.Bad press is painful
Uber could’ve avoided some pain—and legal hot water—if it had adhered to stated policies. When violations and sketchy behaviors are brought to light, users hear about it. Witness the intense reaction to Facebook’s “social experiment.” Or the response to Edward Snowden.It could become a selling point Alex Winter
The most common retort you hear when raising issues around privacy is “What are you so scared of?” During a 2014 talk at Carnegie Hall, Glenn Greenwald explained how he responds to this question: he proposes the asker write their email username and password on a piece of paper and give it to him. No one ever takes him up on it. People, he posits, simply want private spaces where they can do things away from others.
There are also very real things to be afraid of—things that we, as user experience designers who care about empathy, should also care deeply about. One example: Weight Watchers sharing personal information in user accounts (weight, health habits, and exercise patterns, for example) with advertisers, which 60 Minutes reported on. In the same report, an expert discussed the emergence of “digital redlining.” Historically, redlining is the practice of denying mortgages to applicants of color in predominantly white areas of town. Digital redlining is similar: you could be denied a mortgage if the socioeconomic status of your online social circle deems you undesirable—and Facebook just patented technology for that very thing. Warrantless snooping by the government can have serious consequences too, leading to unjust detention and arrest.
Down the road, it’ll really suck when health insurance companies start to get access to data from Fitbit to raise premiums (they’re already rewarding users who provide access to their data). And don’t forget about users in countries whose lives may be at risk when their data isn’t private. If we believe that treating users with respect and honesty is essential to a good experience, then we owe it to them to ponder these issues.
We also need to be aware of the processes we’re complicit in—as Mike Monteiro has said, designers have responsibility. Trading in user data is a big part of making a living online today. If you choose to participate, you should know that you’re part of further ossifying the web in this modus operandi. You may be okay with that, but know it.
So, to sum up: Arrests based on erroneous or overblown government intelligence. Insurance companies snooping around in messages and health records. Dissenters being punished by dictatorial regimes. The arrival of robot overlords in the form of targeted advertising. Lack of privacy creates real danger. But even if users don’t want Google cataloging and analyzing a lifetime of their search history just because—well, that’s valid, too. It’s Article 12 of the Universal Declaration of Human Rights.Adding privacy to your process
There’s no tried-and-true path to building privacy into your process, but there are ways to get started. Here are a few.Use a question protocol
If your site or app uses a form, or asks the user to enter any amount of data, Caroline Jarrett’s question protocol is an invaluable tool for digging deeper into what you’re doing and why. As she describes it:
A question protocol is a tool for finding out which form fields are required and lists:
- every question you ask
- who within your organization uses the answers to each question [or, if no one plans to use it now, who can you imagine using it down the line?]
- what they use them for
- whether an answer is required or optional
- if an answer is required, what happens if a user enters any old thing just to get through the form
The question protocol is different from the form itself, because it’s about how you use the answers.
Jarrett sees the protocol as bringing web development closer to the rigor of the scientific research process. “For example, during the census,” Jarrett explains, “they will be doing extensive research around what questions to ask, how that data will be used, and the delicate balance between the cost of collecting every piece of data and the benefits. Because collecting census data is incredibly expensive, but it’s very important.”
In the case of product development, every piece of data we collect through a form has a cost, too.User costs Business costs Attention What about your product might the user ignore if a form is onerous? Data storage Where will you keep all of this stuff? Time How much time does a user really have to contribute to your form fields? Data maintenance What is the cost of updating, modifying, and potentially disposing of data? Trust What happens if users don’t understand why certain data is required? Data quality What will it take to sift through made-up data to get to the real stuff? Physical cost What does it take from the user to fill out the form? Breach of user trust How would users react if data were misused or sold?
You could apply this method of deeper thinking to any piece of data you’re collecting on a site, not just what gets typed into a form. Say you want to collect GPS data on users: ask why it’s needed, where it’ll be stored, how it’ll be used, and tally up the costs around breach of trust if it comes to that.Write user stories around privacy
We spend a lot of time designing features—features that users experience. But things that happen in the background of an experience can still constitute bad UX.
One way to bring privacy into the conversation early on is to write user stories around a privacy epic. Here are some examples based on an online store:
- As an online shopper, I want to know why the store requires my phone number because I feel uncomfortable giving it out, and it seems irrelevant to making a purchase.
- As an online shopper, I want to have a choice over whether and how the store uses my search history so that I have control over my data.
- As an online shopper, I want to have the option for my purchase history to inform recommendations the store makes so that I can shop more efficiently.
- As an online shopper, I want to know how the store uses my data so that I can make an informed decision about whether I want to shop there.
- As an online shopper, I want my purchase history to remain under the purview of the relevant business so that I do not receive unsolicited marketing.
- As an online shopper, I want my purchase history to default to private until I tell the store they may use it.
Here’s another example:Privacy icons by Aza Raskin.
Former Mozilla designer Aza Raskin created a whole slew of privacy icons to instantly communicate to users how their data is used.
These examples are more about informing users than allowing them to take action. Much more could still be done to give control. But explaining—whether through approachable language, content organization, or design—is a great first step.Make privacy a core team skillset
Developers oftentimes don’t know optimal storage configurations to help protect users. (“Let’s anonymize the logs” is a typical, and unsatisfactory, solution.) Advocate hiring someone for this expertise, such as someone who went through a program specifically studying online privacy—like Carnegie Mellon’s IT master’s with a privacy engineering specialization. Or bring in a consultant to advise on a specific project, like the Privacy Guru. If you’re part of a bigger company, maybe it’s time to consider a chief privacy officer—Acxiom has one.Build privacy into your product’s DNA
You probably can’t compete on privacy alone, but combining usability with privacy—like Heartbeat does—can be an advantage. Or, build third-party products that encourage privacy, such as the rating system for apps (PDF) that would let consumers know how private and secure they are that a group of computer scientists proposed. I talked with Columbia professor Henning Schulzrinne, who recommended an Energy Star-like privacy rating system, and futurist Marcel Bullinga, who told me about an idea for a universal dashboard that would allow users to control their privacy across the internet. The Electronic Frontier Foundation’s Privacy Badger blocks advertisers and trackers that collect data, while Lightbeam, a browser add-on for Firefox, shows you who’s accessing data on every site you visit.Reconsider the ads you run
Take a course on data analytics. Hold a lunch-and-learn at your office about US privacy laws. Share the W3C’s guidelines on browser fingerprinting and privacy, the FTC’s guidelines for privacy and security for the internet of things and its older report on protecting consumer privacy (PDF), Microsoft’s adherence to the ISO’s guidelines, or the foundational principles of “Privacy by Design.”
It’s tough to keep up, but there are resources to help, like the Electronic Privacy Information Center and writers like David Meyer and Kashmir Hill. Write more articles like this one and come up with other ideas for “privacy by design.” Maybe you’ve built privacy into your process in a cool way. I know I’d love to hear about it.Be realistic about the hurdles
Bringing privacy into your process is still challenging. First off, usage patterns are one of the basic underpinnings of UX. The vast troves of online data being generated aren’t evil in themselves. On the contrary, they hold possibilities for wonderful insights and improvements to life. But there’s a fine line between that and invasive—possibly even abusive—behavior. (One pretty unambiguous example is Mattel’s Hello Barbie, which records children’s voices and transfers them to an online server to process and respond to them.)
Then, there are the users themselves, who seem to sort of care about privacy, but sort of don’t. A 2014 report from Pew found that while 80 percent of Americans are concerned about third parties accessing data about them on social networking sites, 55 percent “agree” or “strongly agree” with this statement: “I am willing to share some information about myself with companies in order to use online services for free.” Essentially, we’ve grown accustomed to the commerce of personal information online in exchange for free services. There’s the old saw, “If you’re not paying for the service, then you’re the product.” User data is quite the lucrative product, too. There’s arguably a disadvantage to throttling its flow. (See: Google’s market cap of $360 billion.) Many companies have never even considered that there may be alternatives to the current user-data-for-service model of so much of the internet.
Then there’s this notion of “Minimum Viable Product Disease,” where products are rushed out the door before privacy is taken into account. That’s no big surprise—adopting privacy as a foundational principle is time-consuming and expensive, as ad company 4info found.Try anyway
The fact that it’s hard doesn’t mean we’re off the hook. Just as we have a responsibility to design accessible products, even when it’d be easier not to, we have a responsibility to consider privacy. We all have a role in shaping the way products are delivered, ensuring they serve users’ interests in an era when the notion of private life has been thoroughly compromised. So let’s do it mindfully, not limiting our considerations to features that users see. Instead, let’s look underneath and above, reach further into the future, and think bigger about what user experience is.
Brainstorming is fun! In the early days of a new project, there are tons of ideas flying around, and those ideas spark discussions that spark more ideas. Maybe this new section of the site will have live-chat, and a video tour, and we’ll add voting to the comments!
It can be pretty hairy to narrow down the list of potential features. If the ideas were developed a while ago (which is usually the case in my projects—brainstorming tends to happen before outside consultants are hired), people are often very attached to an idea that they love and don’t want to give up.
I’ve found that what works best for me in these whittling sessions is to have a framework to fall back on. An established framework means that no one is trying to justify their idea to me; all ideas are evaluated in a relatively emotion-free setting so we can decide which solutions are the best ones to pursue.Image courtesy of Elise Weeks.
My framework initially started as a Venn diagram with two circles: “What the business needs” and “What the user wants to do.” Finding features and content that fit in the overlap is basis of the core model and many other great strategic approaches.
This is the level of evaluation that helps nix ideas like “photo gallery of the company golf tournament.” (Because, hint: no user has a task that is completed by seeing your team in dopey hats and spiky shoes.)Image courtesy of Elise Weeks.
I’ve started adding to my Venn diagram. The third circle holds “What is appropriate for the website,” which covers questions of brand intent, technology, and cost. A few years ago, we had a client who wanted to have live-chat crisis counseling on their site—they had trained counselors on staff, it fit perfectly with their mission, and it served the needs of their users. But (at the time) the technology just wasn’t ready: third-party solutions didn’t have the privacy and reporting capabilities they needed, and there wasn’t budget to build something from scratch.
Another client was talking about putting forums on their site, to mimic the engaging dinner table conversations people had at their monthly events. This circle helped us have a discussion about whether that was an appropriate use for the site—and since part of the emphasis of the events was being physically together, we decided that site forums didn’t align with that goal.Image courtesy of Elise Weeks.
My fourth circle is a love letter to all content strategists, and holds “What is sustainable for the organization.” A weekly podcast plan that only lasts a month, lovingly crafted team profiles for two of the 28 staff, a community calendar whose last event was held in 2013—we’ve all seen plans like this fall apart. This circle helps me push on questions of time and energy without sounding so, well, pushy.
This circle also provides opportunities to talk about ongoing needs like photography, in-house versus external development resources, and what happens when the person in charge of this complex taxonomy goes on maternity leave?
I’ve found that grouping feature discussions with these circles has helped me have much more productive conversations with my clients, and has given them a framework for continuing their evaluation discussions when I’m not in the room. I recognize, though, that these particular four labels are based on the type of work I do and the shape of my projects. Do developers, or project managers, or in-house strategists have a different set of evaluation needs? What are the labels in your circles?
You’ve likely heard about the arrest of 14-year-old Ahmed Mohamed for building a homemade clock. This shameful and reactionary response to Ahmed’s creativity has been met with a well-deserved outcry—and a wonderful show of support from the online maker community, which understands the importance of stoking curiosity in young people.
Many have asked how you can help. Until we've heard back from the Mohamed family, here's a form to show your support: http://t.co/ENpjid6boD— Anil Dash (@anildash) September 16, 2015
Visit Anil’s form to extend your support in any capacity. He’ll share the feedback with the Mohamed family to “connect Ahmed to any Maker event or hardware hacking community he wants to join.” —Lisa Maria Martin, issues editorYour weekend reading
- Last week, the Coral Project shared the Trello board where they’re tracking stakeholder needs for the news-commenting platform they’re developing in collaboration with Knight-Mozilla OpenNews, the New York Times, and the Washington Post. I’m a firm believer that comments can be community; it’s refreshing to see folks investing in making comments sections better, instead of just turning them off entirely. As a community nerd, I love that the Coral Project is making their process public and sharing their research findings with the rest of us—there’s a lot here for anyone looking to improve the way people interact on the web. —Marie Connelly, blog editor
- Many of us build sites and projects on top of Amazon’s platform, and they have over 50 great services to choose from—that is, if you can figure out what they are. Here’s a list of all of Amazon’s services, and what they should have been called, based on what they actually do. —Tim Murtaugh, technical director
- I was saddened this week to hear that Adrian Frutiger, the talented type designer who brought us so many classic typefaces, died this week at 87. His legacy will thankfully live on through the myriad contributions he made to the type and design communities. This excellent Dezeen piece on his life and contributions is worth a read. —Erin Lynch, production manager
- A while back, the indefatigable Chris Coyier put together the end-all, be-all inline SVG vs. @font-face icon grudgematch, weighing the two approaches in terms of workflow, aliasing, accessibility, browser support, and more. Every so often the “icon fonts vs. SVG” debate comes up on a project, and I just as often find myself reaching for the URL to this page. Not to take sides or anything, but I did bet my lunch money on seeing a lot of green in the SVG column the first time I clicked on through. —Mat Marquis, technical editor
- “I came into the discussion looking to prove something, not learn something.” Jason Fried of Basecamp looks back in embarrassment at his hotheaded youthful self, and shares a life lesson that changed him as a thinker and maker, in “Give it five minutes” on Medium. —Jeffrey Zeldman, founder and publisher
Big news from our sponsor MailChimp: new MailChimp Pro, with multivariate testing, comparative reports, and priority support.
You know those moments when you’re shown a new feature to build, a description that needs to be written, or a design that needs to be translated to code, and you just freeze? When you aren’t sure where to go or how to begin?
This happened to me recently; the designer I was working with wanted to include a small animation on the homepage. I’ve taken an animation workshop, and I’ve done very small things on sites before, but I’ve never done something quite like what he asked for. At first I thought it was completely unnecessary, why bother? But as I worked through it, Googling madly and using Mozilla Developer Network a lot, I learned. When I got it working, or at least got it started, it was fun to see.
We’ve all had those moments when we’ve been asked to do something in our work, and cringe. I get it, some days you just want to coast, use the knowledge you have, get the job done. But on those same days, you may be thrown a new idea or concept that you need to make happen. How we handle these moments, can make a difference in how our days go.
Lately, instead of cringing, I’m pausing to think of the task differently when something new is thrown my way. Instead of feeling like I can’t do it, or searching for an argument for why we shouldn’t do it, I’m trying to look at these moments as a possible way to learn.
I can be old fashioned at times; I like the code that I know works, and sometimes I’m slow to warm up to new things. But, I’ve found when I keep an open mind to the possibilities and try something out, I learn and sometimes I even have fun.
We have so many tools at our finger tips that can help us learn quickly, and I know when I learn something on the job, the new ideas stick with me longer. Truth be told, I’ve gotten fond of reading the drier specs and documentation—it’s a way I’ve found I can learn on my own in these moments of uncertainty.
So now, instead of cringing when the new idea is presented to me, I’m pausing to think through what a plan of action could be. Can I figure out how to make it happen? When I get something to work, like I did recently with that animation, it’s a gratifying feeling, knowing that I pushed through the fear and learned. Truth be told, this is often how we grow, by pushing through those moments, we realize that we’re capable of figuring it out and getting it done.