Privacy concerns are a hot topic worldwide, and for good reason. Our personal information and digital world has never been more vulnerable to exploitation, manipulation or abuse.
Massive data breaches from hackers and other bad actors are commonplace. A whole industry of data brokers are making billions buying and selling data. Giant corporations are busy hoarding vast treasure troves personal data from both software and hardware used by millions.
Anyone running a website is interacting with users. But as you build or manage these sites, how careful are you with your users’ personal data? Is it safe and protected? Did you plan this out carefully?
To many it is a passing concern, and not part of any thought out and repeatable process. But there is a new awareness of how we can all contribute to a better experience for user privacy. This new set of best practices and procedures is what we call Privacy Experience.
Privacy Experience, or PX for short, is a newer discipline or phase to add to any web design project. With PX, the end user’s privacy is fully considered (and planned for) as part of the overall project. PX touches all phases of a website redesign or new build, from the initial planning to the time of launch.
Historically, the more common privacy experience for most projects is little or no consideration. Maybe at the end of a project, right before launch, someone mentions a privacy policy and a page gets hastily added to the site. The policy itself is often a cut and paste job from some older writings, or inspired by the policies of other sites.
The problem with this approach is that very little discussed or planned for the needs of your specific website and your specific users. But there’s so many points along the process where some thinking about privacy could be valuable.
Take the first stage of a site redesign–planning. Depending on the scope and scale of the project, this is often the phase focused on a few key areas–meeting audience needs, scoping the technical aspects of the build, and planning for content and design. How should privacy be part of the conversation?
Define and document
First, define what personal information you have to collect. Document and discuss. For some, such as a membership based site, it may be a lot. For others, there may be little or no need. Regardless of the situation, begin by compiling your list, and then start paring it down.
Far too many sites collect more information than they need. Do you need to know someone’s birth date, for example, or street address? Could your forms be shorter? The reasoning is often that you collect everything you can capture, and perhaps that becomes useful at a later date for some currently unknown use.
The problem with this approach is exposure. Every piece of personal information you collect becomes something you are responsible for protecting. Data breaches are commonplace, and the law is establishing privacy rights. The less you collect, the less likely you can be held accountable for misuse. The less your team has to worry about if a user requests data be deleted, or a full record of personal information made available for download.
Technically, as you are planning content types, online forms and different forms of data tracking, you can be compiling a list of known data you are collecting. How will you technically be able to export or remove records on demand? How will data be purged or regulated? Now is the best time to ask these questions.
Some privacy laws may require an organization to draft a "Privacy Impact Assessment", detailing any and all privacy risks in the data you are collecting. While this is not a document to be taken lightly, you may wish to use the same rough outline when assessing your website's technical data and risk.
Web developers have access to a lot of data, including any and all personal records your site might collect or serve to users. With this access comes responsibility. So how does a web developer or team of developers practice good PX?
Some of the more obvious best practices include implementing a strong password protection and use of secure, encrypted connections to lessen exposure to hackers. Make sure your software is up to date and any and all relevant security patches are applied.
Less obvious to privacy might be the act of data handling. When your developers work, they’ll often download a copy of the website to do their work “locally”, prior to pushing their changes back to the servers. During this process, a full copy of the website gets downloaded to their local machine, including any and all personal data held by the site.
But in developing a new feature, developers rarely need specific data. They’re typically more concerned with the feature working properly. So instead of working with actual user data, could they use fake data instead? This is done all the time before real site content becomes available. There are all sorts of fake data generators that could be used to render made up names and other personal info, for coding and testing.
During technical planning, your organization can be planning how to deal with privacy and personal data. But it will also take changes in the behavior of your developers to ensure its success.
Far too many sites collect more information than they need
You’ve done your planning with privacy in mind, and implemented new procedures for your developers for protecting data. So what’s left? The user experience!
Websites are designed for users. People visit, browse and click around, and typically “do” something. This could be an active exchange, such as buying something, sharing a story on Facebook, or filling out a contact form. Or it could be a passive exchange, such as simply browsing pages and reading articles. Either way, during this process of being a user, there’s an exchange of data.
Your site visitors need information. What data are you collecting on site visitors? Are you running scripts to track their movements? Does your site use cookies to save data, or allow third-parties such as Facebook to track data? Tell your users everything!
Drafting a Privacy Policy
While it’s not the only step you take for Privacy Experience, it’s still an important one. Ideally you are consulting with a lawyer, but the guiding principles should be:
- Make your policy simple and easy to read
- Make it as short as possible (again, for the end user)
- Clearly, without legalese, spell out what data you are collecting, how you will use, and how users can opt-out.
There are some policy generators out there you could try, if consulting a lawyer isn't an option. For a small fee, these services will gather some data specific to your organization and generate a privacy policy to use. I can't recommended one particular service over the other, but a quick search will turn up some options to evaluate, or you can find reviews and lists of different policies.
Cookie Banners
You should alert users to the presence of cookies on your site, and ask for their consent. If you are trying to comply with GDPR or CCPA, it is required. The most common way to do so is through "cookie banners."
Cookies are the little tracking scripts found on most sites that measure site analytics, run ads, or other services. Cookie consent banners alert users when they first visit your site to the presence of tracking cookies. Ideally they give your users full information about any and all cookies present, and the option to opt-out of tracking for any non-essential ones.
Essential cookies, such as those used for tracking a login or a shopping cart, can’t be disabled or the site wouldn’t work. Non-essential cookies, however, such as analytics or tracking pixels, are not required for using the site. And as such, you should give users the option to opt-out.
If your site is powered by Drupal or WordPress, there are existing plugins to make it easier to install these banners. There are also third-party services such as Cookiebot that will handle these alerts on you site for a fee.
Access to Data
Practicing good PX means giving your users full rights to their personal data. You can details what data you are collecting about them in a privacy policy or cookie banner. But you also need to consider access to data.
In the spirit of transparency, and in following certain privacy laws, users need the ability to:
- Understand what data is being collected
- Be able to opt-out of collection
- Request a copy whatever personal data a site may be holding
- Ask that all personal information be deleted
Depending on the complexity of your particular website and system, complying with these requirements may be difficult. As you are in your planning stage, you can have conversations about what programs or systems you need to build to meet these requirements.
For a site that collects personal information in a webform, it may be as simple as regularly purging records from the server. If you use the Webform module in Drupal, you can easily export contact records to a spreadsheet, or delete data. But certain ecommerce platforms or membership sites may need custom solutions to meet these goals.
For a large corporation like Facebook, offering users the ability to download a full copy of their personal data (which you can now do!) was likely a difficult ask. But respecting a user's personal data, and their inherent ownership of such data, is all part of a good Privacy Experience.
It’s not just good user experience. It’s become a legal question as well.
When the GDPR became law in the European Union, privacy experience was at the forefront of the rules. All users were guaranteed a right to their data and how it was being collected. A right to ask for a copy of their data and a right to be “forgotten” (have their data deleted).
In the United States we now have the CCPA in California, following many of the same rules and regulations. Other nations around the world, such as Australia, Canada and Brazil, each have their own privacy laws, and a number of states are considering their own.
Designing and implementing a good privacy experience should take these laws into account, and however your audience may be impacted. By having PX part of your site building, you’ll have a built-in process for discussing any issues related to legal compliance and not have to retroactively consider everything post-launch.
Much like accessibility concerns, there isn’t truly a one and done process to PX. It’s an ongoing process, and one that becomes as much a part of maintaining a site as it is building one.
Make sure your organization has policies in place to deal with ongoing concerns. What will you do if there's a data breach? Think about it before it happens, and put someone in charge of the response. It likely isn't part of anyone's particular job description, but take time to assign the responsibility to someone, and offer them training and support. Larger organizations could consider staffing a full-time data officer.
Have regular procedures in place to track any changes in data collection, and update your policies as needed. Keep track of privacy laws and your particular exposure. Have automated scripts to regularly delete personal data from servers once it is no longer needed.
Practicing good PX is a journey, not a destination. Learn what you can about your privacy practices and how you are protecting your users, at site launch and for all the years after.
Join the Discussion +