Date
April 16, 2020
Author
Pascal Barry
Summary
In this blog post I'll look at my thinking and experience of putting ethical design into practice with Akord.

Through the lens of ethical design: Akord 4 months in

It comes as no surprise when I say that privacy is a topic we care and think about deeply. It was in thinking about the ethics of privacy and ideas such as privacy by design, that the doors to sustainable UX and the broader ideas of ethical design were opened up to me. If we wanted to be ethical in regards to privacy, shouldn’t we be as ethical as we can in every other area of our work?

Defining ethical design

Let’s first get on the same page as to what ethical design means. One of the foremost voices in the field is Aral Balkan. His Ethical Design Manifesto that riffs off Maslow’s hierarchy of needs has been very inspiring, and I will use it as reference point through out.

A triangle split into three layers illustrating a hierarchy of requirements to achieve ethical designs
Aral Balkan’s Ethical Design Manifesto summarised in a hierarchy. Failure to deliver at any level renders a design unethical. Reproduced here under the creative commons license.

I also found Lennart Overkamp’s article, Daily Ethical Design, a very useful look at incorporating an ethical approach to your design process. Overkamp lists usability, accessibility, privacy, user involvement, persuasion, focus, sustainability and society, as the “areas for designers to focus on when considering ethics”.

While I wouldn’t discount any of the areas Overkamp’s defines, I have collected those ideas under a few broader areas, which I have used as the lens to look at Akord and the structure of this article. Below is a very brief definition of those areas, which I will expand upon later as each area is examined individually.

  • Sustainability
    We must consider the impact of our work on the environment and our carbon footprint. Whether it’s the materials we use or the amount of electricity we consume, physical and digital products alike have to consider questions of sustainability.
  • Accessibility
    Products that are not accessible and usable by all are discriminatory by definition. We need to think about accessibility in terms of different physical experiences of our products, as well as the different experiences rendered by the speed of the internet connection or type of device and browser used.
  • Privacy
    Privacy is a basic human right. Privacy shouldn’t be an afterthought, but should be a concern at every level and stage of developing a product. Privacy should not be opt-in, but the default. We must not expose, put at risk or exploit any personal information of the people who use our products.
  • Respect and Empathy
    Respect people’s rights and have empathy for their human experience. Products that are distracting, addictive and create noise are unethical. We must also be cognisant of our work’s impact on everyone it may affect, not just our customers, and also considering society at large.

Sustainability

Your digital carbon footprint

If your company produces a physical product, of course there are many obvious ways to be sustainable: using recycled materials in your packaging, carbon off-set your deliveries and recycling products at the end of their lifecycle, to name a few.

But if you work on a purely digital product, you may wonder how you can make your product more sustainable. In the case of Akord, I will focus on the one area where we should all be able to make sustainability gains: performance.

If the internet was a country, it would rank sixth for electricity usage, and as stated on the Sustainable Web Design site:

"Sustainability and page speed go hand-in-hand. When your website runs more efficiently, you use less processing power, which means that your site uses less energy and will have a lower carbon footprint."

Aside from environmental benefits, performance also underpins a key aspect of accessibility. A fast site or app means your product is still accessible to people who don’t have access to fast internet connections. And if your homepage is 5mb to download, that will cost 10x more than if it’s 500kb for those who pay by data usage. You can design and build something that will impress your peers, featured on all your favourite webspiration sites, but if the homepage takes 10s to get to the first meaningful paint on a 3g connection, then you’ve failed at the first ethical design hurdle.

Unfortunately, this message doesn’t seem to reach some of ethical design’s own proponents. The Sustainable Design School’s own website scores 13 for performance (and 52 for accessibility) on Google Lighthouse, and the website of Ethics for Designers scores 18 for performance (a staggering 8.1s for the first meaningful paint).

Shining a Google Lighthouse

Google Lighthouse, mentioned above, is available to anyone who opens Chrome’s Developer Tools and navigates to the Audits tab. It’s a great tool to zero in on some very practical ways you can make your site or app more performant.

When Lighthouse highlights an issue there are useful links explaining how you can go about fixing them. Using Lighthouse I was able to achieve a performance score of 97 out of 100, significantly increasing the speed of the site.

a screenshot of the Lighthouse tool
A view of Google Lighthouse’s report, highlighting some metrics and opportunities for improvement

Image optimisation

One of the simplest things you can do to try and improve performance is make sure all your images are properly optimised. If you’re thinking, I always ‘Save for web’ in Photoshop, then this is for you.

There are now ‘next-gen formats’ for images like JPEG 2000, JPEG XR, MOZjpg and WebP, which often provide far better compression than PNG or JPEG. This means faster downloads and less data consumption.

I used the free online Squoosh app to drastically reduce the size of our images after they were exported from Photoshop. Some images were reduced by more than 80%. I used the MOZjpg format as it’s read by browsers as a normal JPEG, so you don’t need to provide any fallback support in your code for browsers that don’t support these next-gen formats. Google developed the WebP format so you will see that being pushed by Lighthouse, but after comparing this against MOZjpg there didn’t seem to be any significant difference in how they performed.

A screenshot of the squoosh app displaying the results of an optimised an image
An Akord illustration, exported from Photoshop ‘Save for Web’ at 245 KB, gets reduced by 81% with hardly any perceptible difference in quality.

The illustrations on the Akord website are raster as our illustrator, Gosia Herba, does not work in vector. We could have reduced images even more by using vector illustrations, but I took on the extra file size cost as from a brand perspective I didn’t want Akord to have yet another generic Saas feel (see Khoi Vinh’s Monoculture Illustrations).

It was a price I believed we could afford to pay, as after optimising the illustrations the homepage was still reduced by 33.3% (535.5kb to 357.3kb) and our other illustration heavy page by 64.9% (1265.3kb to 444.3kb). Also, at some point there is a balance between performance and creating a delightful experience (the apex of Aral Balkan hierarchy of ethical needs). Yes we could go without this photo, video, icon or illustration; but if we strip out all ornamentation we will arguably never achieve a result that could be described as delightful.

In terms of other images on our site, we had initially set out using font awesome for icons. That was over 100 kb for just a handful of icons. I opted to use inline SVG for our icons so I could eliminate all requests to the server for these images. For optimising any SVG you can’t make inline, checkout SVG OMG, which bills itself as “SVG’s missing GUI”.

One final point on image optimisation — make sure you’re lazy loading your images and video. As Google states on their Web Fundamentals portal:

“Lazy loading is technique that defers loading of non-critical resources at page load time. Instead, these non-critical resources are loaded at the moment of need. Where images are concerned, “non-critical” is often synonymous with ‘off-screen’.”

Details on how to implement lazy loading are included in the Web Fundamentals page.

Fonts

When we first launched, we were self-hosting three fonts from the Larsseit typeface: regular, bold and italic. These files in all their various formats — .eot, .ttf, .woff, .woff2 — amounted to 872 KB.

If I really wanted to optimise wherever possible, I would just serve web safe or system fonts. And that isn’t necessarily as bad as it may seem. If you serve a system UI font stack then whoever is seeing your content will be served the OS font they’re used to. Something comfortable and familiar, and if they’re using a modern device these fonts, like Apple’s San Francisco and Microsoft’s Segoe UI, are great typefaces in their own right. The article, System Font Stack, from CSS Tricks breaks down the options for you.

In the end I opted for a bit of a hybrid technique. I dropped the italic Larsseit font for starters. Italics are a form of emphasis and, depending on your content and product, you can often get by without them by using bold, colour or quote marks for emphasis. I also dropped the .eot and .ttf formats, as these are used as a fallback for older browsers. I then added a system UI font stack after the Larsseit declaration in my Sass variables.

With this setup, users on modern browsers that support the .woff and .woff2 formats would get Larsseit and everyone else would get the system UI fonts. My reasoning was, if you’re using an older browser you’re probably using an older machine, you may not have the best internet connection, and you’re probably are already dealing with a slower than average load time. It’s better to get our content to these people quickly, considering the high bounce rate for slow sites. A 2016 study by Google found 53% of mobile users bounce if a site takes longer than 3 seconds to load.

Finally, I set font-display: swap, which means whatever setup you have you should never have to wait to start reading content. With this setting we display the system fonts in a ‘flash of unstyled text’, or FOUT as it’s known, if the self-hosted fonts are taking a long time to download.

Some designers don’t like this flicker as the text switches from one font to the other. On a fast connection this is indeed just a flash as the page initially loads, but if you’re on a slow 3G connection this may mean seconds. Loading those system fonts first means people don’t have to wait to start accessing your content, and are less likely to bounce from the site because of slow page loading.

Here’s the code:

@font-face {
  font-family: ‘Larsseit-Regular’;
  font-style: regular;
  font-weight: 400;
  src: font-url(‘3AA7CA_1_0.woff2’) format(‘woff2’),
  font-url(‘3AA7CA_1_0.woff’) format(‘woff’);
  font-display: swap
}
// font stacks
$font-stack-regular: ‘Larsseit-Regular’, -apple system,BlinkMacSystemFont,”Segoe UI”,Roboto,Oxygen-Sans,Ubuntu,Cantarell,
”Helvetica Neue”,sans-serif;$font-stack-bold: ‘Larsseit-Bold’, -apple-system,BlinkMacSystemFont,”Segoe UI”,Roboto,Oxygen-Sans,
Ubuntu,Cantarell,”Helvetica Neue”,sans-serif;

How we can continue to improve

Hosting

There are many green hosting options that are powered purely through renewable energy. We currently use Amazon Web Services (AWS) who are by no means the worst, but still not 100% renewable. AWS have committed to reaching 100% renewable energy on their AWS Sustainability page. They exceeded 50% renewable energy in 2018 and are also in the process of building six solar farms and 3 wind farms.

Considering the sustainability of hosting providers was not something on my radar at the beginning of the project, but it’s something that should be investigated if we are to pursue ethical design principles. We’re researching alternatives to AWS and will hopefully switch when the time is right to review our infrastructure.

CSS Framework

We’re a team of 3 co-founders at Akord, and none of us come from a front-end development background. For this reason we decided to use the Materialize CSS framework for the website. While this helped us get off the ground quickly, using frameworks come at a price I increasingly feel aren’t worth paying. For one, you end up serving a ton of code that is never used. Despite my best efforts to strip out what we weren’t using this was still the case on Akord, where most pages were serving 80% plus of unused CSS.

Apart from slowing the site, I’ve also always found that using a framework gets increasingly messy the further you get into a project. I find this to be particularly frustrating with interactive components that have accessibility requirements. We have an issue with our dropdown menu where the submenu options cannot be tabbed through, and despite my best efforts to rebuild the navigation I could not unpick all the conflicts with the framework and resolve the issue. Fortunately, it’s questionable whether we need those links as a main navigation dropdown, and there are access to the links within the main content.

Still, we know in the long term the codebase is not optimal or scaleable, so we have decided to hire a highly experienced front-end developer to help us rebuild the site from the ground up. The core of their brief will be to build a lightening fast site that strictly follows accessibility best practices. This project will have to wait until the end of the year when we have more resources; but I believe it is essential for us to make Akord highly performant whatever means you have to internet access, and equally accessible to anyone who may visit the site.

Accessibility

Considering disability

I was recently introduced to the social model of disability, which says that disability is not derived from a person’s characteristics (the medical model), but through their interaction with an unsuitable, broken environment. In other words, we have built our society and environments in a way that disables people. I find this idea incredibly powerful and revealing in relation to my work. It’s painfully clear much of the web and its associated technology is built with little regard to how it disables many people from effectively interacting with it.

If we want to consider the number of people using screen readers, statistics are not easily available as the devices themselves interact with the browser not the website. Also, tracking and revealing people using screen readers could end up enabling discrimination. Still, some logical assumptions would put the number of screen reader users at around 4.4 million in the US alone, about 1.4% of internet users. We would not find it acceptable if 1 or 2 people in every 100 could not use our product based on their race, so why should it be any different when considering disability? In fact, if we want our design to be ethical, no number of people or section of society would ever be acceptable to ignore.

For the longest time my knowledge around accessibility was probably on par with most designers. I was aware I needed enough contrast between background and text colours, font sizes needed to be large enough in relation to the contrast, images needed alt tags… and that was about the sum of it. I always worked with developers to whom, without really thinking about it, I had delegated the responsibility of making sure the code would be accessible to assistive technologies like screen readers.

But I think there is a natural place for the designer familiar with some experience coding to take on this responsibility. After all, isn’t it the designer who is supposed to be empathising with the people using their products? Even without the experience to work on the code, a designer can still build their awareness and knowledge of accessibility issues to a point where they can act as an effective quality control in this area, flagging issues for the dev team.

Getting down with the a11y gang

If you’re an accessibility pro then you already know that a11y stands for accessibility — the first and last letter of accessibility and the 11 represents the number of letters in the middle. The world of a11y can feel daunting for someone who, like me, is able bodied and a relative novice in the area. I hope sharing some of my experiences in trying to upskill, and some of the solutions I implemented to make a11y improvements on the Akord website, will help introduce more designers to the subject.

Tools

Extensions

You can pick up a lot by using extensions like Google Lighthouse and Axe. These tools will more than likely catch a number of instances where you’ve missed some basic accessibility best practices: ensuring all titles, alt tags and elements critical to accessibility are included, checking valid and necessary attributes and values are used, and highlighting all manner of relatively small fixes that can make your markup more coherent and semantic. The sum of these many small fixes will result in a big UX improvement for assistive technology users.

I was able to boost Akord from an average accessibility score to 100 on Google Lighthouse. But getting 100 on your Lighthouse report, as I found out, is by no means proof that your site or app is perfectly accessible in this area. Far from it. There are many issues that can only be highlighted by making a manual accessibility test, and I recommend checking out some online resources, like the video How I do an accessibility check, on how to go about doing that.

Screen Readers

If you’ve never tried navigating your site or app with a screen reader, then this is an essential first step to highlight how your design might not be at all accessible from someone who uses assistive technology.

If you use a Mac then you have built-in access to one of the best screen readers out there, VoiceOver. If you fire up VoiceOver you’re likely to feel overwhelmed as the app starts reading out whatever you mouse over or focus on with declarations that seem garbled.

I suggest checking out this free accessibility course on Udacity that, along with a run through of many fundamentals, includes videos of someone who is visually impaired using a screen reader and narrating how they use the tool. I found this a really helpful intro to the technology, providing the real world context for some of the code examples I was reading about.

Another great place to start is the Silktide extension, that that can simulate the experience of your site or app from the perspective of someone with dyslexia, colour blindness, cataracts or who is blind. I found the basic simulator for a screen reader in Silktide was a great entry tool, much simpler to use than VoiceOver, which helped quickly highlight some big issues.

The Accessibility Tree

Most digital designers and developers know about the document object model (DOM) — HTML is parsed by the browser and turned into the DOM, and together with CSS and javascript we get the graphical user interface (GUI). But what is not such common knowledge is that browsers also produce an Accessibility Tree, which is pretty much like the DOM but edited down to include only that which is semantically relevant to devices like a screen reader. It’s why having semantic markup and using the right elements for the job is so crucial when you’re writing HTML.

A diagram showing the flow from HTML to the DOM, which then splits and produces the accessibility tree as well as the graphical user interface

In Chrome you can access the Accessibility Tree through the developer tools.

A screenshot of Chrome developer tools' accessibility tree panel open
The Accessibility Tree is accessed in Chrome Developer Tools through Elements > Accessibility

Tab Order Index, Skip Links & Aria Labels

Referencing the Accessibility Tree and using VoiceOver highlighted a number of issues with the Akord website. I saw how anyone experiencing Akord with a screen reader would be taken through the main navigation first, and then move through the same list of navigation options that were coded separately for the mobile and tablet navigation. They would have to tab 23 times before getting to the main content of the page.

This issue of offscreen content, like side bars that slide out of view, being included into the tab order index is a common one. The solution is simple: use media queries to target any offscreen content and set it to display: none or visibility: hidden at desktop and then return to display: block or visibility: visible at mobile and tablet sizes.

While looking into this issue I also discovered skip links. Most people will never see a skip link, even if a site has one. They only appear as you tab through the content of a website, triggered by the very first tab and appearing from the top of the screen with a link, ‘Skip to main content’. This ability to skip past navigation is incredibly useful for people using screen readers, enabling them to avoid having to go through all the nav links that they may already know they don’t want to access.

Here’s how the code looks:


a class=”skip-link” href=”#main”>Skip to main content /a
main id=”main”
  [Main content]
/main

.skip-link {
  position: absolute;
  transform: translateY(-100%);
  left: 50%;
  transition: transform 0.3s;
  background-color: $akord-blue;
  color: #fff;
  padding: 8px;
  z-index: 100;
}

.skip-link:focus {
  transform: translateY(0%);
}

Once you’re this far into thinking about accessibility you will invariably come across Accessible Rich Internet Applications (ARIA) attributes. As Google says in its Web Fundamentals:

“ARIA provides several mechanisms for adding labels and descriptions to elements. In fact, ARIA is the only way to add accessible help or description text.”

I recommend using the Web Fundamentals material and the Udacity course mentioned above to learn more on how to correctly use ARIA.

I used ARIA labels in a few places on Akord to make it easier for screen readers to make sense of inline SVG’s used for social media icons and the hamburger menu, for example, which otherwise would not be accurately described.

Here’s a code example where I’m using ARIA labels to give the screen reader a label for the inline SVG based off of the title and description.



svg id=”linkedin” aria-labelledby=”linkedinTitle linkedinDesc” role=”img” width=”24" xmlns=”http://www.w3.org/2000/svg" viewBox=”0 0 171.93 173.97"
  title id=”linkedinTitle”>Linkedin logo /title
  desc id=”linkedinDesc”>Links to Pascal Barry's profile. /desc
   path … /
/svg

How we can continue to improve

For various reasons, we decided to kick off our work on Akord with a self-imposed deadline: a “30-day challenge” to build the visual brand, website and release the encrypted transfer part of our product vision.

There’s always a consequence to working quickly: some corners will get cut, or, at best, delayed. The accessibility work was done retroactively and, unsurprisingly, this is an area that is most effectively considered from the beginning. I’ve truly learnt that lesson and will carry that experience through all future projects.

Starting the journey

In this article, and in my work generally, I feel I’ve only begun to scratch the surface of a11y best practices. But I believe if you integrate some of these tools early on in the build process you will make progress quickly and incorporate good habits that you can build on from project to project.

One important habit I will take with me in future is to periodically tab through web pages as we go through the development process. If I had done this during Akord’s build process, we would have saved a lot of time catching the basic accessibility errors in our markup. I’m also committing to regularly spending some time reading the great resources that are online, like The A11Y Project and A11Y-101, for example.

Privacy

Take a stance

As privacy is at the core of what Akord does, we took the time out to write our own manifesto on privacy, Privacy starts with people. While writing a manifesto on privacy may feel a little extreme for most, privacy is undeniably one of the biggest issues of our time that every company must consider seriously.

Do you collect and store personally identifiable data? Do you track people in any way? How would you handle someone’s request to have their personal data deleted? How would you handle a data breach? These are questions every company should be asking.

We believe that if data is the new oil, we should all be striving for a fair data economy. The brands that embrace this new paradigm will separate themselves from the crowd, as awareness of these important issues is only set to increase.

If you, your team and company, haven’t thought much about privacy, take some time out to review your privacy policy, website and product, and audit how you handle personal data. At a minimum, it’s essential that you and your team have a basic understanding of some of the recent regulations: GDPR in Europe and CCPA in California.

Akord, the product

Currently, Akord only offers one part of the product vision: end-to-end encrypted file transfer. On the surface it seems clear that we have this area of ethical design covered. What could be a more private than end-to-end encryption?

Still, there were a number of issues we had to tackle. For example, should we collect someone’s name and email to send a transfer? It’s possible to create a magic link with the private key for decrypting the files embedded in the link, leaving you to copy and paste the link into any medium you want to use to send the files.

But without collecting this basic personal data we couldn’t deliver on a key part of our proposition — consent. When you send an Akord, you dictate the Terms of Consent, which currently include a time limit to access the files, as well as allowing you to specify whether your data can be shared with third parties. With basic personal details an audit trail is created with a record of the recipient agreeing to those terms.

To track, or not to track

Analytics

Early on we decided not to use Google Analytics as this required us to use cookies to track people on our site. We use rails across the app backend and the website, and this allowed us to use Ahoy for our analytics.

Ahoy has a number of privacy enabling features that make it GDPR compliant:
– masking IP addresses
– switching from cookies to anonymity sets
– disabling automatic linking of visits and users.

These features are great for privacy, but forced us to accept a hit on the variety of analytics we’re able to get and the quality in the display of that information.

Anyone who uses Google Analytics regularly, or even infrequently, may find it hard to stomach the setup we have in terms of the analytics UX and capabilities. We know this is not the best option in terms of helping us analyse data, but it’s the best option in terms of respecting the privacy of the people who visit our site.

Cookies

When most people build sites at the moment they will probably think a few days before launch, “Oh, we forgot about the cookie banner!” And hastily plug something in to legally cover their backs.

For us, the discussion around cookies went on for days. It was part of a wider topic of tracking, and a commitment we all made to track people as little as possible.

We loved the idea of trying to reimagine this whole experience. But as we had set ourselves an ambitious deadline for launch, we decided not to get too sidetracked. We decided to use CookieHub, who have a Consent Log feature that allows us to prove the consent choices of users as demanded by GDPR.

Currently, our site uses only 2 cookies: a session cookie from Rails that’s classed as necessary in providing core functionality, and the cookie used by the CookieHub tool itself. While this is likely to expand as we develop the account features, we commit to no analytics cookies, no advertising, no third parties, no unnecessary tracking whatsoever.

Email

In terms of email communication, we decided to commit to only emailing people who used our product when strictly necessary. This would mostly be in the realm of the product experience: confirming a transfer was sent, for example.

There will be no unsolicited onboarding emails, reminders, tips, or general marketing. We won’t automatically sign anyone up for news and updates. Unless you specifically sign up to hear about product features and news, you shouldn’t hear from us.

We will also never use pixel tracking. Pixel tracking is a common marketing practice used by many saas companies where emails are embedded with a code snippet that can track whether you go to a company’s website, the OS you use, mailbox type, screen resolution, the time spent on email, IP address, and actions you take on the actual site (eg, the additional pages you visit).

Rel attribute

Here’s a useful tidbit — when using an external link that’s to open in a new window, if you do not add the rel attribute with “noopener noreferrer” values it means that people accessing that external link can be tracked from where they’ve come from and a security vulnerability is also introduced.

The noopener tag works as a security fix, preventing hackers from reaching the user’s currently opened website with a fake website and potentially stealing personal data, such as login details and credit card details. The noreferrer attribute stops that user being tracked across your site and the external site they’re taken to. Here’s the code:


a 
href="www.external-site.com" title="The title of a link" target="_blank" rel= “noopener noreferrer”>www.external-site.com
/a

How we can continue to improve

While we offer end-to-end encrypted file transfer, and we will never be able to see the unencrypted data, we can still see the file names of any documents transferred. It’s possible, therefore, to have a limited view as to what the transfer was about.

If we encrypt this data then we cannot provide some basic user experience in future product development such as search. We’ve decided to explore providing a setting where people can decide if they want to trade or limit certain features, such as search, in exchange for the ability to encrypt this kind of meta-data.

If we grow as a company it will also be crucial to limit internal access to any sensitive data. As we expand and the product evolves in terms of complexity, we plan to include a few advisors who can bring a deep level of experience regarding cyber security and cryptography.

Empathy and Respect

Human-centred, delightful design

In our initial product development we have constantly sought to put ourselves in the shoes of the people using the product. We conduct research interviews and test our prototypes with a broad enough range of people that we think may use our product. Although we don’t dogmatically follow any process frameworks, in spirit and intention we closely align with the Human-Centred Design approach. The description on Wikipedia captures the core idea perfectly:

“Human-Centred Design is an approach to problem solving, commonly used in design and management frameworks that develops solutions to problems by involving the human perspective in all steps of the problem-solving process. Human involvement typically takes place in observing the problem within context, brainstorming, conceptualizing, developing, and implementing the solution.”

We respect people’s time and value a delightful experience as much as a functionally robust one. In Aral Balkan’s Ethical Design Manifesto, ‘Delightful’ is at the apex of his ethical hierarchy of needs. Our time is scarce, so don’t expect people to spend it on a drab product. This part of the product development doesn’t come at the end of our work, the ‘skin’ we slap on to the code, but throughout the process we seek every opportunity to create a delightful experience.

Dark UX patterns

The web abounds with dark UX patterns, also referred to as ‘black hat’ practices, that seek to manipulate behaviour solely for the purpose of tricking users into taking actions that are for the benefit of the company and not necessarily for the user.

If only design was as simple as good versus evil. Dark UX patterns are defined by the UX practitioner who coined the phrase as being “carefully crafted with a solid understanding of human psychology”. Some of these patterns are truly egregious and consciously manipulative, but other patterns may not appear to some designers as outright unethical. Partly because they have become so habituated to seeing them online themselves, and absorb those patterns as part and parcel of how things are done in certain contexts. And so they’re carelessly repeated or, worse still, evolved and made more effective.

We must question our motives whenever we seek to persuade someone into an action. For whose benefit is this? Who will always benefit – the user or the company? It’s tempting to not dwell on something you tell yourself is no big deal, to give yourself a free pass, justifying a decision by saying that everyone else does it. Don’t.

We commit to respecting people’s autonomy. To respecting the individual’s most precious resource: time. We do not seek to manipulate, or create distraction, addiction and noise with the products we put into the world.

The wider consequences

What are the wider consequences for people and society at large who may or may not directly use your product? We must ensure that what we build respects the people who will use the product and delivers a desired and positive benefit. To design ethically is to step back and consider what could be some unintended, worst case scenarios from your product. How could this negatively affect people and society, directly or indirectly?

Seemingly benign services with noble goals can create massive issues for communities. Airbnb’s mission, for example, was to connect people through the ability to host a stranger in your own home. But the company is now responsible for reshaping neighbourhoods negatively, pushing properties into permanent airbnb locations instead of providing homes to locals.

With Akord, we frequently discuss the consequences of encryption if people using our product use it to engage in illegal activities. Are we facilitating that behaviour? Are we responsible in some way? What can we do to limit this possibility?

Currently the EARN IT act is being introduced to Congress in the US. The bill is focused on reducing child exploitation, but many believe it to be a sneak attack on end-to-end encryption services. If the bill passes into law it may be used as justification in forcing companies to provide backdoors to encrypted services.

We believe encryption to be an essential tool, without which our fundamental human right to privacy would not possible online. I agree with the words of Kate Ruane, senior legislative counsel of the American Civil Liberties Union, when she says of the EARN IT act:

“The EARN It Act threatens the safety of activists, domestic violence victims, and millions of others who rely on strong encryption every day. Because of the safety and security encryption provides, Congress has repeatedly rejected legislation that would create an encryption backdoor. This bill is not the solution to the real and serious harms it claims to address.”

These issues are complex and we have to engage with them completely and consistently. We must constantly ask ourselves as our product evolves and can be used in different, potentially unforeseen ways, what the wider consequences may be and if we believe our tool is truly delivering a positive benefit to individuals and society at large.

How we can continue to improve

Right now we’re in the middle of a global pandemic. It’s most definitely not business as usual. Everyone has been forced to respond with extreme measures. We’ve particularly been inspired by the companies who’ve switched their manufacturing to products needed by healthcare professionals, like masks, hand sanitiser and ventilators.

We also recognise that this is a dangerous time when our rights can easily be eroded in the name of fighting an enemy. We see contact tracing solutions being proposed to help track the virus using people’s smartphone location data. This is a potential nightmare for privacy.

Ultimately, any ethical product development must be rooted in empathy for others. I believe if we keep coming back to this idea we will be rewarded with a more satisfying journey, and more likely to deliver a product that genuinely benefits individuals and society.