Asking When: Ethics in the Product Development Process Part 2

In my previous article in this series, I spoke about the ethical mindsets and methodologies that can be employed during the discovery phase of a project. From fact-checking during problem finding, to referencing IDEO’s “The Little Book of Design Research Ethics”, to running a post-ideation session with the Tarot Cards of Tech, there are a plethora of resources you can reach for and keep on hand in your ethical product development toolbox. 

It took some time—and a hefty amount of research—but I turned my sights to ethics in the delivery phase of a project. Ethics in delivery is complex, due to a myriad of reasons, not least because ethics is often associated with strategists and designers. These product builders run activities where ethics can be more clearly baked in, from defining a product vision, to forecasting the implications of that vision, or running user interviews. Delivery folk, on the flip side, are usually found behind closed doors, working algorithmic and visual magic until the final ta-da of release.

Naturally, there’s a but here: much like in discovery, there are mindsets and methods to employ throughout the delivery process. Let’s take solution architecture to start. Designing the technical requirements and overall vision you have for your product is a place where, right off the bat, things can get terribly unethical. This is driven by the very nature of software itself; software is prescriptive, rather than open for interpretation.

Compared to past social systems—governed by social conventions or laws—software gives less space for personal reinterpretation or disobedience. It tends to code up exactly how we are intended to interact. Social software… guides us much more strictly through certain actions and ways of relating. As a result, we have less of a chance to pursue our own values. The coded structure of push notifications makes it harder to prioritize a value of personal focus; the coded structure of likes makes it harder to prioritize not relying on others’ opinions; and similar structures interfere with other values, like being honest or kind to people, being thoughtful, etc.

Joe Edelman

Code is law, not just a wall of writing. Bringing ethical reasoning tools into your architectural process can be a valid start, as well as documenting the time of your architecture (e.g. anticipating it’s evolution). When it comes to devising your architecture, one of the most obvious ethical things to think about are security and data. Where are your components coming from? Are you building or buying? Or, perhaps leveraging open source solutions? Whatever your decisions may be, you should be hyper-aware of how security and data play a role in those solutions, to make sure what you are building is trustworthy and accountable from day zero. Here’s a roundtable of some considerations to bring into your practice:

• If you are considering leveraging existing solutions into your overall architecture, then make sure you do your due diligence. It is completely acceptable – not to mention, smart – to say, get a boost from something like Stripe if you need a credit card payment platform. You don’t have to build everything from scratch, but you should be finding people that you trust to facilitate these interactions. Thinking about frameworks like Privacy by Design is key when you go about selecting potential partnerships.
• On the note of using external components, make sure whatever you are using is being maintained and regulated by a large enough community. No one needs another Node.js module disaster. Essentially, the checks that you do should go beyond reading the licenses. Do you know everything that the system is doing (is it – cough – mining bitcoin – cough)? 
  • And, if you are considering using open source, do it for small, inconsequential areas of your project – it’s useful in doing an initial audit (less to review!) and it means that any future security issues that arise will impact your product less (although, even with open source, you’re still at the whims of that group that created it to maintain the integrity of the project)
• When you start to think about data, look at the laws for storage, transfer, and collection within the region you are targeted—in Canada, that would be PIPEDA—and apply them to your work  
  • Data could be another article in and of itself, but: how is your data being managed? This article provides some useful things to think about, from compliance to retention
  • You need to appreciate how your data will be expressed in all of the different points in your architecture, from in transit to at rest. Making sure that it will be encrypted on a server is one step – but what happens when it’s restored? Who has access to your data (and do they really need to)? 
    • Access should be role-based per environment as well, from development, to staging, to production.
  • All in all, get comfortable with the idea of Datensparsamkeit when you’re figuring out your plans around data capturing and storage. Do you really need to collect all of the data? 
• Lastly, using frameworks like the Ethical Operating System can challenge you to think about future consequences of your system, like if  it will play well with new drivers, or the next generation OS. The speed of innovation these days is leaps and bounds; make what your planning has adaption baked-in

This is a bite-sized amount of all of the considerations at play. Ethics is a continual conversation—so it’s almost impossible to collect all of the resources and questions that may pertain to a particular product. But, nonetheless, this is a useful starting point for solution architecture and, hopefully, a good lens to bring into your day-to-day as a practitioner.

Stay tuned for the next part in this mini series: Back-end implementation!

Lisanne Binhammer

Senior Product Designer

Lisanne Binhammer is a Senior Product Designer at Connected with a passion for ethical and inclusive design. Most recently, she has worked on a discovery-based project for a client in the civic technology space. Outside of her day-to-day, Lisanne is the Director of Product Design Education at Bridge, a non-for-profit that levels up skills for marginalized groups in the tech sector.

More Posts