I wrote a longer piece all about design ethics on Medium – it takes about 15 minutes to read.
Ethics is part of everything we do at Ghyston. In a nutshell, design ethics means considering the full effect of what you design and build (not just the one at the top of the brief). Everything is designed and all design has an effect – “you cannot not communicate”. Some effects are good, some are bad. They can be empowering, or damaging. We design for businesses so this is closely tied with business ethics - what are your business models and how do they affect your decisions? What are your algorithms doing and what outcomes do they coerce? (by the way check out mathematician Cathy O'Neil's new algorithm auditing consultancy O.R.C.A.A)
Example from a recent digital transformation project
We built a system that featured a task list for care staff, which significantly improved safety, but it would have also had unwanted effects had it not been for proper consideration and user testing. It would have put unnecessary pressure on staff and take some control away from them – inevitably leading to staff putting less thought into care actions, instead focusing on satisfying the task list.
There are many points where you can catch potential side effects. They can be evident straight away from a project brief. They may arise in user testing. They may take a while to present themselves.
For this reason we make testing part of our process throughout an agile project, from discovery to delivery and supporting business change management. We raise these issues early and often – and work with the whole project team to solve them. This article outlines what we do at Ghyston to ensure that we really design for what is good for people.
Really, really define your aims
Project aims should not read like company straplines – they should avoid all fluffiness. Everyone on a project team should know exactly and unambiguously what the project is aiming to do. We will challenge stakeholders and project teams to define exactly what it is they want the project or the product to do.
Honest user stories
We write user stories for everything that we build – this is basic agile methodology and is one of the best changes towards user-centred design in recent years. But they’re not all ‘user stories’ – as in, they are not all things that the user actually wants to do.
“As a customer, I want to enter in all my personal details so that I can purchase my train ticket”.
Doesn’t sound quite right, does it? More like:
“As a company, we need to capture personal identifiers so that we can prevent fraud”.
After this admission, there may be other stories about making that process as quick, painless and fair as possible for users. After all, the user just wants to purchase a ticket. Actually, they just want to have the ticket. They just want to catch the train. They just want to be in a place. They just want to visit friends.
We can see how many steps there really are between what you as a company needs the user to do and what the user actually wants. What we are really doing is allowing them to do something that they have come to expect faster and more easily. Now I’m not advocating one single story of “the user wants to visit their family” – I’m advocating an admission that most things are a compromise of some sort between what the user really wants and how the business want to provide for it.
Once you write it all out honestly, you may realise how little the user really needs something.
Open collaborations
We workshop and stand-up and never go too long without checking in with customers. We actively look for ambitious companies who will work with us and tackle the big problems head-on. We believe this is only possible with strong collaboration – we hope you do too.
Put a manifesto on the wall
We have put ind.ie’s design poster up on our walls – sending the message to customers that we follow this – and providing an accessible framework to reference.
Question everything
All features are worth questioning. As mentioned in the Medium post, the author Dave Eggers (‘The Circle’ and others) questioned why surveillance was ‘baked in’ to all technology – and from that questioning the novel was born.
We will advocate and advise – but never just assume that features must be included – we will raise it with you and help you make good decisions.
Build bespoke!
Bespoke software naturally affords the questioning of products and features. We get to the root of what it is that will provide most long-term value for users – and solve your business needs without approximating them. This exercise not only pays for itself – but also is extremely satisfying!
Test properly
We test software to make sure users can’t ‘break’ it. We also regularly test with real end users – to make sure it won’t break them. Usability is one thing – but the full effects of a product may be long-term and cumulative and change a whole culture. We bring proper design thinking and years of experience from UX, Design, and long-term Build and Support projects and are able to foresee most issues. However there will always be improvements you want to make based on specific use cases or observations. For this reason we advise you test with users before and after launch to catch new perspectives.
Open discussions
Frequently around the office you will hear discussions about the ethics of technology, companies, privacy, and all those philosophical questions inherent in providing digital services.
Long-term relationships
Most of our customers are long-term, which not only means that we get to know their aspirations and their estate – but we also see all the long-term effects, monitor how products are developing and take both responsibility and pride in how our products effect people.
If you want to chat more about design ethics, do get in touch with Ghyston.
