# Design decisions are bidirectional

**URL:** <https://forum.zurb.com/t/design-decisions-are-bidirectional/617>\
**Category:** Proving biz impact\
**Created:** [January 30, 2026, 5:24am UTC](https://forum.zurb.com/t/design-decisions-are-bidirectional/617 "2026-01-30T05:24:16Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bryan](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.zurb.com/bryan/32/448_2.png) [@Bryan](https://forum.zurb.com/u/Bryan)\
**Post date:** [January 30, 2026, 5:24am UTC](https://forum.zurb.com/t/design-decisions-are-bidirectional/617/1 "2026-01-30T05:24:16Z")

</div>

Been running into this scenario more often.

When a business problem is fuzzy, product and design leaders get stuck. Teams either accept a stakeholder-defined problem as complete or treat the situation as too complex to tackle. Work continues, but it circles the problem instead of solving the actual problem

The solution is to reframe the problem. Design decisions can move in both directions.

Sometimes they start with user needs and move toward business outcomes. Other times they start with business goals and work backward to design choices. Each direction requires different questions. Starting from the business side can help clarify what matters, reduce fuzziness, and unblock progress.

> **[Design decisions are bidirectional.

I see this pattern a lot in our customer...](https://www.linkedin.com/posts/bryanzmijewski_design-decisions-are-bidirectional-i-see-activity-7422809788704788480-tVMD)**
>
> Design decisions are bidirectional.
> 
> I see this pattern a lot in our customer work at ZURB where a team does solid design work, ties it to a business goal, and brings the concept into a review expecting momentum. Meetings get some head nods, a few...

---

<div class="post-metadata">

**Author:** ![ben](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.zurb.com/ben/32/442_2.png) [@ben](https://forum.zurb.com/u/ben)\
**Post date:** [January 30, 2026, 9:58pm UTC](https://forum.zurb.com/t/design-decisions-are-bidirectional/617/2 "2026-01-30T21:58:09Z")

</div>

Love this… orienting around the business needs feels like one of the best ways to “ground” a team to real problems to do work that actually matters.

---

<div class="post-metadata">

**Author:** ![MoData](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.zurb.com/modata/32/1182_2.png) [@MoData](https://forum.zurb.com/u/MoData)\
**Post date:** [January 30, 2026, 11:45pm UTC](https://forum.zurb.com/t/design-decisions-are-bidirectional/617/3 "2026-01-30T23:45:27Z")

</div>

> “When business goals and capabilities are the starting point, they become real constraints. Users are introduced as friction in the system.”

So introducing friction in the system is sometimes necessary?

---

<div class="post-metadata">

**Author:** ![Bryan](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.zurb.com/bryan/32/448_2.png) [@Bryan](https://forum.zurb.com/u/Bryan)\
**Post date:** [January 31, 2026, 12:46am UTC](https://forum.zurb.com/t/design-decisions-are-bidirectional/617/4 "2026-01-31T00:46:06Z")

</div>

Not just friction, but adding the users as friction.

Most design teams aim to optimize the user experience. I’m suggesting that’s the push method, and it is often difficult to create influence when used alone.