@ibaldo, I truly love this topic you brought up, and the work you are doing on human flourishing!
I get what you are saying here, and I am a big proponent of going from the “human strengths”. I think this is also present in the Humane Design Guidelines of the CHT, but they are written such that this is less clearly expressed, i.e. by writing in the form of:
current problematic practice (explicitly or not exploiting human vulnerabilities) —> humane design best practices
I really like the way you set up Human Flourishing Design Guide (HFDG). I am not schooled in psychology but a tech guy and product owner. In terms of pragmatism and practicality, looking at the PDF, what immediately came to mind was a likeness to Behavior Driven Development (BDD).
In BDD a software product starts with text-based descriptions of desired behavior which are created in close cooperation with the customer upfront. Then in the subsequent development process they translated to - ultimately - code, and importantly end-to-end tests that can verify that the behavior is adequately implemented.
In agile development a software functionality is often broken down into Epics which is then later further broke down into User Stories that can be readily implemented iteratively by a multi-disciplinary software team. Key thing is that as a customer / stakeholder and with help from the product owner you want to track and verify that nothing is lost in the translation process to source code. This unfortunately frequently happens and leads to mismatches in what is delivered.
Furthermore after Epics / User Stories become part of a software release, you still want to track their functionality and features over time to ensure nothing gets lost as the software evolves. Agile development has a weakness here, where the user story gets forgotten after it moved across the development board, and its functionality is not properly (holistically) measured by tests, nor is it properly documented in most cases.
BDD can be a powerful tool to bring improvement here. And it can be very well combined with Domain Driven Design (DDD), which effectively means: “translating the language of the customer / end-user to concepts that are present in the codebase”. Because of this and to mitigate shortcomings in agile development, both BDD and DDD are undergoing a resurgence in popularity these days.
But there is still a lot to be desired in terms of “flourishment” (I like to use this word myself). For instance BDD + DDD provide a very functional approach. It is not values-driven. Take the example from the Wikipedia BDD page (written in a variation of a Gherkin BDD script):
Title: Returns and exchanges go to inventory.
As a store owner,
I want to add items back to inventory when they are returned or exchanged,
so that I can track inventory.
Scenario 1: Items returned for refund should be added to inventory.
Given that a customer previously bought a black sweater from me
and I have three black sweaters in inventory,
when they return the black sweater for a refund,
then I should have four black sweaters in inventory.
Scenario 2: Exchanged items should be returned to inventory.
Given that a customer previously bought a blue garment from me
and I have two blue garments in inventory
and three black garments in inventory,
when they exchange the blue garment for a black garment,
then I should have three blue garments in inventory
and two black garments in inventory.
This whole thing could be a User Story, or it could be an Epic where the different scenario’s are User Stories. That depends on the amount of work involved in implementing them. Note that many software shops don’t have Epics, only User Stories. Or they have Use Cases, or Use Cases and User Stories.
With BDD text could become literally part of the codebase and is parsed and executed in end-to-end (E2E) behavioral tests that fail when any of the above no longer matches —> the functionality is monitored from now in the software development lifecycle.
TL;DR on BDD:
- Customers / end-users have more control + insight on how their wishes and desires wrt the software are implemented.
- Development teams and other IT stakeholders have more control to safeguard that customer’s wishes are fulfilled.
- Customers / end-users and IT stakeholders speak the same language throughout the development process.
- Desired behavior is automatically tracked and tested for compliance as the software evolves.
Extending to Flourishment Driven Design (FDD)
Though not mentioned in your post above, I assume you’ve given this much thought as well. Your HFDG fits really well as an extension to the BDD + DDD combined software development process.
The tracking of “Flourishment Characteristics” throughout the development process is imho vital. Hence defining the Value Proposition in terms of HFDG statements can never be enough.
I imagine Flourishment Driven Design to be an extension of BDD, such that it can become part of scripted texts that can be automated as tests in the software to ensure compliance. Now this is where it gets interesting.
If I lookup Value Proposition in Wikipedia, I see it is accurately defined, only applied to the field of business strategy and business plans. We need to translate to software development and apply holistically, i.e. across all disciplines and involving all stakeholders.
Value proposition: A promise of value to be delivered, communicated, and acknowledged. It is also a belief from the customer about how value (benefit) will be delivered, experienced and acquired.
A very nice definition. I have italicized ‘belief’ and ‘experienced’ as they apply most to flourishing from the perception of the customer / end-user. Let’s brainstorm and construct a flourishment charactistic as an example in a BDD-like context:
Feature: The Unlimited Drawing Canvas :
Value proposition: Supports the designer’s Creativity (A.3.1):
By taking away artificial boundaries (the bounding box) giving the designer a sense of freedom,
And by (B.1.3) helping designer to making satisfying decisions and minimizing choices,
So that freedom of expression is encouraged and not hampered by restrictive UI.
As a designer,
I want to draw on a canvas without boundaries,
so that I can focus fully on doing creative work without the UI getting into my way.
Scenario 1: Canvas scrolls when the tool cursor reaches the edge of the viewport.
Given that a designer performs an action with their drawing tools
when they tool cursor nearly reaches the edge of the visible canvas,
then then the canvas scrolls smoothly to accomodate the drawing action,
and the scolling speed can be adjusted by the designer to a comfortable level.
It may be a bit contrived example (I’m new to this), but note that:
- I used a more specific ‘user-in-role’ stakeholder type: the designer of a drawing app
- The options (the ‘by’s’) are implementation specific.
- I’ve added a ‘so that’ because I think that e.g. B.1.3 is not yet the end goal to be fulfilled, but more a means towards that goal (i.e. Creativity).
Looking at the above I see a great opportunity of FDD + BDD + DDD!
There is one thing remaining, which you also refer to: How do we measure this consistently?
That’s where the science comes into play, I guess, and its where I am just a noob
But I am very interested to know more about the metrics you can collect in this regard and how that measures to automating it in order to ensure ‘flourishment compliance’. Or not automating it of course if this is not feasible, but then instead making it part of an integrated process that offers the same assurances.
Some other things I noticed and would like to give feedback on.
- The options in the HFDG pdf are I assume only indicative; serve as examples. After all any positive emotion can be used here. I’d consider at least adding the word ‘Trust’ to the sheet by default, and maybe some others too.
- Your value proposition has the term “supports users”, but that is too narrow imho. It should be "supports [stakeholders’]" because we should not only look at the software from a users’ perspective, but apply holistically.