Closed heyjerrybecker closed 4 months ago
Hmm, I like where you're headed with this. I've been trying to figure out how to better align / merge our internal Design Thinking model with the Open Decision Framework and these seem to bring us closer together. Let me noodle on it a bit. The actual steps inside each phase map pretty closely to the titles you're suggesting, and this might also help people figure out how to better use the ODF steps within an agile dev model, too. Working on a refresh of the ODF in general, so I'm going to keep this open until I figure out what to do with all the ideas and get a draft ready for comment.
Ideation is the creative process of generating, developing, and communicating new ideas, where an idea is understood as a basic element of thought that can be either visual, concrete, or abstract. Ideation comprises all stages of a thought cycle, from innovation, to development, to actualization. Ideation (creative process) - Wikipedia
Because ideation comprises all stages, it is difficult to put it in a particular position of the sequence outlined above. I usually start by thinking about something based on my current knowledge before I go researching and expanding my understanding of the topic. Then I incorporate new knowledge gathered from research by further ideation.
Flipping the first 2 steps is certainly a great way to align the 2 models.
And @rolfedh you make a great point! Ideation can definitely happen in various forms throughout the process (especially post-MVP when you're into the rest of the product lifecycle). You define it as "the creative process of generating, developing, and communicating new ideas..." but true human-centered design (and Design Thinking) teach you to hold off on generating new ideas, and start first with understanding and empathizing with your users/market. This way you can allow your understanding of them to lead to the best ideas to build & deliver something of value. That's not to say you can't have an idea where you think "wouldn't it be cool if THIS existed...." If you do, you can't allow yourself to go too far down the ideation path because then you start to get married to your idea and don't allow your research to emerge new and better solutions. That's why the human-centered design community always starts with understanding.
And I think starting with understanding is a great first step when applying the ODF as well. It widens your aperture of possibilities.
Hopes this helps clarify my thoughts!
@beckerjs The ODF is applicable to any organizational decision-making process, not just product design/software development. What is a person researching and understanding if they haven't first empathized with a user, thought about a problem, and formulated questions? Ideation isn't limited to brainstorming solutions.
Aha! - I'm reading up on Design Thinking models and beginning to understand how "ideation" has a more specific meaning in that context. Unless we make Design Thinking a "prerequisite" for ODF, I'm not sure that meaning would be clear to most users.
Well I had a huge reply typed up, but I think you just saved me some time!!! hahaha Yes, the reality is that "ideation" means a specific thing in HCD and design-thinking models. But you're definitely right that it can happen in other stages as well "e.g. ideating on problem statements"
Probably, the best solution is to develop a specialized topic, "ODF for Design Thinking," that guides design teams on how to apply ODF in their context. It should include a note to help users avoid misunderstanding the ODF usage of "ideation." Concurrently, ODF might consider replacing "loaded" terminology like "ideation" with synonyms that don't conflict with adjacent frameworks.
How funny, as luck would have it, @mizmo and I were just talking about this. More to come, when we get around to it... :)
@ruhbehka @mizmo What did you talk about? What were your thoughts and conclusions?
We agreed that there's a need for some kind of supplemental guidance for design-oriented projects - @mizmo has been working on this on her own for a while, and hopes to have a draft to share in the next year. I also noted that we have an internal Design Thinking model developed at Red Hat years ago, and it can be confusing to figure out when to apply that vs. the Open Decision Framework, so we need to try to untangle that and offer guidance on how the approaches are complementary (and when one might be better than the other). This is all happening at the same time as I'm trying to figure out how to add in some "change adoption" tactics for those who join mid-decision or post-decision (or who don't get involved with the decision, but then struggle to implement it afterward). Also, some stuff aimed at helping the decision-maker create a horse rather than a camel, despite getting input that would nudge them toward the camel (the old adage about a camel is a horse designed by a committee)... thinking through how to check yourself as you incorporate ideas and address use cases, that the overall user experience isn't suffering (and that it will be as frictionless for new users in the future as for those who you're designing for today). Lots of learnings over the past few years that we need to figure out how to incorporate into a refreshed version. The challenge is always, time time time. :)
On Tue, Aug 27, 2019 at 9:27 AM Rolfe Dlugy-Hegwer notifications@github.com wrote:
@ruhbehka https://github.com/ruhbehka @mizmo https://github.com/mizmo What did you talk about? What were your thoughts and conclusions?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/red-hat-people-team/open-decision-framework/issues/37?email_source=notifications&email_token=AA3LXRJUU7SWOXPTACVNRGDQGUTTTA5CNFSM4H67STWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5HXG4A#issuecomment-525300592, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3LXROVSDHQI6SET3SOJDLQGUTTTANCNFSM4H67STWA .
It seems like bringing those topics (supplemental guidance for design-oriented projects, change adoption tactics, managing input) out into the open before they're polished might be a scary process.
Rebecca Fernandez
She / Her / Hers
Principal Program Manager, Scaling Our Open Organization
Red Hat https://www.redhat.com
M: +1-919-931-4957 https://www.redhat.com
@ruhbehka @mizmo It seems like we should create a draft to start receiving people's ideas! How do we do that?
You could create an open issue on GitHub, where people can add their ideas and suggestions... that's generally how I track external and internal ideas or RFEs that I can't easily resolve right away.
On Wed, Aug 28, 2019 at 5:46 PM Rolfe Dlugy-Hegwer notifications@github.com wrote:
@ruhbehka https://github.com/ruhbehka @mizmo https://github.com/mizmo It seems like we should create a draft to start receiving people's ideas! How do we do that?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/red-hat-people-team/open-decision-framework/issues/37?email_source=notifications&email_token=AA3LXRLY6YH7K4D3MZCJCXTQG3WZ5A5CNFSM4H67STWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5MSF7Y#issuecomment-525935359, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3LXRM6AJRSMYHSEKPTPN3QG3WZ5ANCNFSM4H67STWA .
5 years later and with the move of the community version to the Open Organization I think we will drop the design approach or version of the ODF at this time. If anyone have any material or knowledge of the work that was ongoing, do bring it up again!
Red Hat believes in a human-centric approach to product development, leadership, and decision-making. And truly human-centered approach always starts with understanding (or empathy). As such, I think it might be worth reordering the steps (or phases) of the Open Decision Framework.
Right now, the steps are as follows: -Ideation -Planning and research -Design, development, and testing -Launch
Starting with ideation, however, might lead to building the wrong thing. I think the steps should be: -Research & Understanding -Ideation -Design, prototype, and test -Develop & Launch
In my proposed steps, ideation only comes after a problem has been validated through research and understanding. The context gained in this phase will improve the quality of ideas generated in the next phase. Also, the 3rd step replaces "development" with "prototype." We should prototype ideas and get feedback before we take the time to develop so we can validate our solutions before spending the time to fully realize them. This will help buy down the risk of developing the wrong thing, as it allows us to course-correct our prototype ideas with real users prior to investing in the time/effort to develop. We should only develop once we have a validated prototype.