"go die on a hill" haha. Not from my side. That' not helping either of us.
We know the problem with the stakeholders early in the process as well. What we did is specifically talking a language that fits the stage. We do not allow our team to use the UI Library elements for early discussions. We just do it Wireframes or even more abstract. As soon as a design "seems" finished (but it's nowhere near to that) by using library components, the discussions get heated up. Like you said with pixels etc. The more abstract we are, the more we discuss problems not visuals.
Figma helps also with that. All relevant people in the same file, gray squares, descriptions and cursors pointing where something is missing. "Here we're missing the VAT information". (I love missing VAT information btw.)
But once you've got that solved, it's extremely valuable to get stakeholders knowledge as early as possible. And as visuals are consumed much faster than confluence pages, we have a lot of visual discussions. Even with accountant and or sysarchitecture guys.
for example: we've solved the whole unexpected errors flow visually in figma. It was way easier for all the architects and devs to see what should happen. A pimped flow chart so to say.
To not include stakeholders out of fear from that discussions is in my opinion the wrong approach. I agree it's a challenge to adapt visuals and discussion style to the production stage. But it's harder to adapt "finished" designs when problems are not fully solved yet.
And one side-note. In our company I introduced the Design-Process in a totally Dev-Driven Company two years ago. Everybody thought of Design as a "make things beautiful". Therefore I had to include our CEO in early stage discussions. So he saw the value of solving problems, making better products and being faster in development. Being visual with Figma helped a lot. We're now heading towards fully design driven.
"go die on a hill" haha. Not from my side. That' not helping either of us.
We know the problem with the stakeholders early in the process as well. What we did is specifically talking a language that fits the stage. We do not allow our team to use the UI Library elements for early discussions. We just do it Wireframes or even more abstract. As soon as a design "seems" finished (but it's nowhere near to that) by using library components, the discussions get heated up. Like you said with pixels etc. The more abstract we are, the more we discuss problems not visuals.
Figma helps also with that. All relevant people in the same file, gray squares, descriptions and cursors pointing where something is missing. "Here we're missing the VAT information". (I love missing VAT information btw.)
But once you've got that solved, it's extremely valuable to get stakeholders knowledge as early as possible. And as visuals are consumed much faster than confluence pages, we have a lot of visual discussions. Even with accountant and or sysarchitecture guys.
for example: we've solved the whole unexpected errors flow visually in figma. It was way easier for all the architects and devs to see what should happen. A pimped flow chart so to say.
To not include stakeholders out of fear from that discussions is in my opinion the wrong approach. I agree it's a challenge to adapt visuals and discussion style to the production stage. But it's harder to adapt "finished" designs when problems are not fully solved yet.
And one side-note. In our company I introduced the Design-Process in a totally Dev-Driven Company two years ago. Everybody thought of Design as a "make things beautiful". Therefore I had to include our CEO in early stage discussions. So he saw the value of solving problems, making better products and being faster in development. Being visual with Figma helped a lot. We're now heading towards fully design driven.