having observed "design advocacy" in many orgs, I've noticed some patterns:
1/n: the very things that get design the "seat at the table" become the limiters for further advocacy. So much effort to create a box ... and then you forever get put in it
2/n: @ryanrumsey talks about this eloquently, but you often see a complete resistance to making a cogent "business case" for why people should care.
Part of this is pride -- which is understandable -- but it becomes "design advocacy" vs. "design as a catalyst for X advocacy"
3/n: Instead of partnering to re-imagine a design-outcomes-friendly flow of product development, the focus is on advocating for how design should "fit in with" or "integrate with" X (whatever the engineering team is doing).
not sure this anyone would find this interesting...but this is how I go about doing my "loops" diagrams
1. first I use write simple things like this to get connections out of my head. at this point it is very rough...
2. I get a little more detailed/structured. All the while I validate these along the way and try to involve other people (hence my initials here vs. other contributors).
3. I do a lot of these ... it gets a bit out of control. I might end up with with hundreds of hypothesis connections
anti-pattern: using one process/tool to do too many jobs
1/n teams "hire" processes and frameworks to do certain things. the trouble is that we humans get greedy. when someone says "well that does A,B, and C" we get excited. 3 for the price of 1!
The problem? ...
2/n First, it is hard to do lots of things well. The process rarely delivers across all of those jobs. It might do one thing well, but be kind of crappy at the other things...
3/n Second, communicating the Why can be very difficult. Say you have a process that is meant to promote learning/experimentation AND can be used to manage people and promote accountability.
1/n - There is so much you can do IF you accept that you have to do the old thing AND your new idea. People might look confused, but you will not get fired. Here's what I mean...
2/n - Say you work in a feature factory and features get thrown over the wall for you to "deliver". That doesn't stop you listing the various risks with that bet. It doesn't stop you describing the higher level bet/rationale.
3/n - Nothing is stopping you setting up a decision review a couple weeks after the thing has been "delivered", and your team has moved on to the next project. "We expected this ... but this is what happened.." (tip @Amplitude_HQ helps with this)