Expose decisions to redistribute power.

The “why” behind design-bias product decisions.

Building a software product can be broken down into core decisions. These may vary for the teams you work with. Likely, they should. Frameworks like this are intended to flex to the context of your organization. Regardless, this is a set of design-bias product decisions that I’ve found work best for the teams I work with.

Core decisions of a software product

1. Business goals
2. User goals
3. Content
4. Workflow
5. Presentation (features)
6. Technology

There is much to be said about this particular set of decisions as a strategy and practice, but I find it most important to first articulate the why. Why does this exist, and why does it need to be articulated?

Power

The primary motivation behind this framework is to enable the redistribution of power within teams and organizations.

Teams that create products work together better when all team members feel they have appropriate responsibilities that match both their desire and skill level. Teams work together better when power is exposed and equalized to this reality.

Unfortunately, and especially within larger enterprise organizations, there are often gaps between given responsibilities and the human potential of team members. These gaps are often found where a select few have too much responsibility and too much power. In these situations, inequality pervades, and team cohesion begins to unravel (to say the least).

To create and expose a decision-making framework is to introduce a new, shared language to teams (and organizations) that informs how they can more equitably make product decisions in a way that does not undermine their aspirations or motivations.

To expose decisions is to have the ability to articulate the inequalities of power.

Inequality of decision making

Inequality of power within software product creation is real. I experience it, and I see and hear others live it much more. It is infuriating.

What does power inequality look like?

• It looks like bringing objective evidence and facts to a team and having these facts be reacted to as a personal attack.
• It looks like bringing your strengths and expertise to the situation, only to have it be disregarded because of fear.
• It looks like being openly hopeful for a better future to those who should support you, but to have those same people deflect or disregard.
• It looks like being attacked or accused for the failure of others for doing what you know to be right.
• It looks like experimentation and learning being treated worse than complacency.

All of this is cultural in nature. It is also heavily steeped in individuals’ prejudice and privilege.

How are we to serve others, to prioritize the most vulnerable, and to ensure software products are forces of good, when we cannot bring equality to our own teams?

Why design-bias decisions?

If a team or organization can be thought of as three lenses of a Venn diagram — one lens for each of business, design, and technology — it is often the design lens that lacks realized responsibilities and squanders human potential the most. Thus, it is the design lens that often lacks power.

This is the reason and need for a more nuanced, design-bias framework of product decisions. Intentional, ethical, and just design can be the fundamental shift in power and policy within the technology industry.

From here, and for now, I leave you with these four questions to begin the process of instigating change:

1. What are your team’s core decisions?
2. Who is currently responsible for what decisions?
3. What is unfair and to whom?
4. What steps do we take, together, from here?

More on the evidence for changing power structures.

Thank you for taking the time to read.

I’m open to write more in depth about any of the above, so let me know.

Feel free to like, share, or comment.

“Structure” by p medved is licensed under CC BY-NC-SA 2.0