Human Flourishing Design Guide: the science of well-being in the service of technology design

Hello everyone! I’m a designer who recently finished an MBA in psychology, and my graduation work was the creation of a science-based design guide for technology that supports human flourishing. I’m calling it Human Flourishing Design Guide (HFDG).

For obvious reasons, I’d like to share the guide here with you all, but I believe one reason is particularly important: the guide I developed was intended to be an “upgrade” of the Humane Design Guide (HDG) developed by the CHT. I’m assuming that some people here are already familiar with the HDG - maybe even using it in your own projects - and I would be immensely grateful if some of you could share your opinions and suggestions of improvements for the HFDG.

You can download the guide here

The HFDG tries to accomplish the following challenges:

  1. Provide a pragmatic, easy to use guide for designers and technologists to develop technologies that enable human flourishing.
  2. Introduce a measurable, science-based concept of human flourishing in technology development practices.
  3. Advocate the idea that technologies doing anything less than supporting human flourishing have no reason to exist.

The intention to develop technologies that enable human flourishing is not new to this community or people interested in a world with humane technology. This very own community defined human flourishing as the ultimate goal of technology on the Pyramid of Humane Technology. Aza Raskin, form the CHT, also mentioned that we want human flourishing as the inverse of the human downgrading provoked by the current state of technology.

My work is based on Corey Keyes’ research on mental health, which concludes that “anything less than flourishing mental health is associated with impaired functioning both for those with a mental illness and individuals free of a mental illness” (KEYES, 2013). Therefore, I suggest that any technology that does less than contributing to the user’s flourishing has the same value as an explicitly harmful technology. In other words, there’s no “neutral” tech.

However, the lack of definition of what human flourishing is during the development of technology makes the evaluation of its flourishing potential and/or effectiveness difficult and problematic. Having only subjective definitions for what human flourishing is makes it easy for organizations behind the technology to define it and argue in favor of their own agendas. Thus, the lack of a commonly accepted definition of flourishing is partially an ethical issue.

But it is also a pragmatic one. Being the technology development an objective practice, will also be the methods and techniques resulting in a flourishing enhancing tool. Therefore, we need an operational definition of flourishing in order to conceive these methods and measure their effectiveness.

Luckily, the study of human flourishing has strongly evolved on the science of well being during the past few decades, and we’ve been able to see the emerging of operational definitions of flourishing and measurement scales and techniques. In particular, the discipline of positive psychology, which has grown popular in this new millennia, has the promotion of human flourishing as it’s the ultimate goal.

Maybe the most popular model proposed by the positive psychology, the PERMA model for human flourishing, defined by Martin Seligman, was the one adopted in the elaboration of the HFDG. According to PERMA, human flourishing requires high levels of positive emotions, engagement, positive relationships, meaning, and accomplishment.

Therefore, the HFDG was designed to guide the technologist define a value proposition for the technology that elevates one or more elements of the PERMA, while also providing a direction on how this should be accomplished, based on theories of positive psychology interventions and positive psychotherapy. Long story short, while the HDG focuses on human vulnerabilities, the HFDG focuses on “human strengths” (more precisely, Character Strengths and Virtues).

The whole work was made in Portuguese, my primary language, and so far I was only able to translate the guide itself to English. I’m planning to translate the dissertation in the near future so people interested in the science behind it can understand it, review it, or criticize it.

2 Likes

Sounds great! Could you send a link to or copy the dissertation?

@ibaldo, I truly love :heart: 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 :

Stakeholder: Designer

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 :slight_smile:

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.

Other observations

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.

Of course!
Here it is: https://www.dropbox.com/s/ql74wz1lyy8a2k0/TCC-Henrique_Castilhos_Ibaldo-c_anexos.pdf?dl=0

1 Like

@aschrijver, thank you so much for sharing your thoughts and contributing with ideas! This really motivates me to keep working in this direction! :slightly_smiling_face:

I wasn’t familiarized with BDD, but I did keep Agile and other common approaches like Lean and Design Sprints in mind while working on it, so I’m really happy to know that you could trace this parallel. The possibility to use HFDG with your preferred methodology was intentional and a pre-requisite while designing it.

Through my own experience as a product person, I knew that the guide should be ridiculously easy and fast to use, otherwise it wouldn’t be useful. There are other positive psychology-based methods of design and tech development, but they are all dense, complicated, and non-pragmatic.

For example, Positive Computing (Calvo and Peters, 2014) actually suggests bibliographic topics as part of the process. Instead of asking technologists to read books and learn stuff, I figured I’d have to do the heavy lifting and learn all the science behind it, and than make the process as easy as answering a simple question, with pre-determined answers to choose. So it was important to me that in HFDG people wouldn’t need to read or even learn anything.

Hence, I do believe that people should have access to the science behind it to learn more if they feel compelled to. As I mentioned, I intend to make it available in the future.

I have reservations about letting users decide what they want in terms of flourishing. People rarely know how to achieve flourishment by themselves (there wouldn’t exist a science about it if this was the case), but I do think that HFDG would be a good tool to validate the flourishment potential of any user request.

Yes! The HFDG was designed to be used in cyclical methods like BDD!

Yes, after looking at your experiment, you convinced me there’s something there! You’re directing HFDG to a more sophisticated format.

Now, I’m not sure if it’s an HFDG flaw and this wasn’t clear at the instructions, or if you intentionally disrupted it, but A.3’s should be used with B.3’s only. To me, the beautiful thing is that “The Unlimited Drawing Canvas” would potentially enable flourishing by allowing the designer to enter a “flow” state of work, which is option B.3.1. - the Flow state, or Engagement, is one of the main pillars of the PERMA model of flourishing.

You could learn more about this by reading Flourish (Seligman), or Flow (Csikszentmihalyi). But the most important thing to me is that the HFDG was validated in your experiment.

So the science is behind all HFDG, from the flourishing definition, to what we know about how people achieve it, to how to measure. In science, like “happiness”, “flourishing” is a construct, which allows it’s operationalizations (measuring it, if you please). In Psychology, we call this a “psychometric”. In HFDG I used Seligman’s PERMA model. PERMA model does have it’s own operationalization method, the PERMA-P, or PERMA Profiler. However, Seligman suggests that you can measure PERMA based interventions with any kind of well-being operationalizations. Other examples are the MHC-SF and the FS.

They are actually very science-based. I only used behaviors in which well-being/flourishing inducing effectiveness is evidence based. I would discourage people to change it without any scientific basis. For the Trust request, “trust” is a manifestation of the character strength of “Integrity”. So in theory, your app could either focus on “integrity” or just write “trust” instead of integrity. These words you see on A.3.X. are Character Strengths. Because these can be manifested in different ways and expressed by different concepts among different cultures, Character Strengths were in fact defined with “alternative” words. I did suspect that the HFDG should have all different alternative concepts listed, so your comment is really valuable to me because it confirms it should.

Makes sense to me! I’d love to hear more about this holistic approach of software development. I’m not familiarized with it.

To be honest, I imagined that HFDG could be a replacement for HDG in the beginning, but given the current problematic state of contemporary technology, I’m more convinced that the HDG vulnerabilities approach is necessary. It’s a sad realization. I do believe these guides could work great together, though.

This. Super important to be KISS. I’ve found that even the slightest friction will lead to developers making shortcuts or starting to hate on the methodology as ‘overkill’.

What’s very nice with BDD is that the feature descriptions necessarily evolve with the code. In fact they are part of the version managed code repository. They are written in a human-readable plaintext format, readable by anyone and supported by the same tools developers already use. Similarly you have docs-as-code and infrastructure-as-code. I’d keep the same requirement on HFDG / FDD scripts.

Yes, I agree. It is important that people have an easy way to learn about the rationale of using HFDG. My advice would be to structure this as a pattern library where one can do gradual drilldown to more scientific background information. The patterns themselves should be comprehensive and intuitive 1-2 page descriptions that are all structured in similar ways.

The basic format should also be in plaintext, e.g. Markdown, from which they can be processed to other target formats and e.g. embedded / auto-linked in generated documentation.

I recently reference 2 pattern libraries on this forum: Humane By Design and Data Patterns Catalogue. Other example in a bit different field is Sociocracy Patterns.

Besides patterns it might be interesting to also investigate anti-patterns and dark-patterns and document those too. Especially with dark patterns it will be interesting to see how they effect the “Flourishment Experience”, the FX ( :wink: )

It is fine if the flourishment analysis is done upfront within the IT organization. But not truly involving the customer / end-user at a certain stage would be a fundamental mistake, imho.

For instance an oft-made mistake these days is that UX designers make assumptions on the things a user will like, while in fact it is mostly e.g. the customer’s project manager that likes it. An modern eye-appealing bright-colored UI with flat-pixel buttons, etc. might completely destroy the UX of users that before used an ugly-looking but highly functional dense screen layouts. Productivity and user happiness suffers.

Brainstorming an example:

Intuitive task-oriented UI supports users’ (A.1) positive emotions (B1.3) by helping to making satisfying decisions and minimizing choices

Is that true, if users are comfortable with a UI that implicitly supported:

All-in-one keyboard-accessible overview screens supports users’ (A.1) positive emotions (B1.3) by helping to making satisfying decisions and minimizing choices

The new functionality could lead to a more point-and-click interaction and hidden UI sections where before just pressing Tab-key would really quickly follow the desired user flow.

Note that this is again a contrived example, because in current practice many of these choices are part of other disciplines of IT development (interaction design, usability studies, etc). But if you want FDD to be a seamlessly integrated part of product development flow, then these integrations should be considered.

No, I did not disrupt intentionally. It was an oversight on my part. But I think seeking disruptions like that is a valuable exercise.

I would certainly have chosen ‘Flow’ if that was part of the HFDG sheet. I absolutely adore “flow” as a state of mind, have had it many times. But the description of B.3.1 of “through their engagement in [objective activity/practice]” did not lead me to think it was related to flow. I interpreted more like involvement, embracing/acceptance of the software.

This just means in the broadest sense 'elaborate, weigh and consider the needs of anyone that is affected by the software in any way.

It is an investigation that leads to finding additional requirements that were not immediately clear. Requirements that you can then subsequently prioritize in terms of relationship of the various stakeholders to the delivered product or service.

So while the Designers might love the Diagramming & Drawing product, the Admin might hate it because of the added maintenance burden. The Marketing department might want to know most fitting terminology and avoid selling ‘hot air’. The Board of Directors might want accurate insights of all the costs incurred by offering the service. Etcetera.

The stakeholders could also include people from the IT company that develops the service. How are updates and security patches rolled out. If the product has a built-in Marketplace for 3rd-parties to offer plugins, then a whole host of new stakeholder needs must be taken into account.

A think an interesting challenge for me is to bring the various new disciplines that are evolving around the theme of humane technology together in a comprehensive framework. The opportunity is certainly there.

1 Like