How To Build Confidence In Your UX Work<\/h1>\nVitaly Friedman<\/address>\n 2025-03-11T15:00:00+00:00
\n 2025-03-11T23:04:38+00:00
\n <\/header>\n
When I start any UX project, typically, there is very little confidence in the successful outcome of my UX initiatives. In fact, there is quite a lot of reluctance and hesitation<\/strong>, especially from teams that have been burnt by empty promises and poor delivery in the past.<\/p>\nGood UX has a huge impact on business. But often, we need to build up confidence in our upcoming UX projects. For me, an effective way to do that is to address critical bottlenecks<\/strong> and uncover hidden deficiencies<\/strong> — the ones that affect the people I\u2019ll be working with.<\/p>\nLet\u2019s take a closer look at what this can look like.<\/p>\n
.course-intro{–shadow-color:206deg 31% 60%;background-color:#eaf6ff;border:1px solid #ecf4ff;box-shadow:0 .5px .6px hsl(var(–shadow-color) \/ .36),0 1.7px 1.9px -.8px hsl(var(–shadow-color) \/ .36),0 4.2px 4.7px -1.7px hsl(var(–shadow-color) \/ .36),.1px 10.3px 11.6px -2.5px hsl(var(–shadow-color) \/ .36);border-radius:11px;padding:1.35rem 1.65rem}@media (prefers-color-scheme:dark){.course-intro{–shadow-color:199deg 63% 6%;border-color:var(–block-separator-color,#244654);background-color:var(–accent-box-color,#19313c)}}<\/p>\n
This article is part of our ongoing series<\/strong> on UX<\/a>. You can find more details on design patterns and UX strategy<\/strong> in Smart Interface Design Patterns<\/a> \ud83c\udf63 — with live UX training coming up soon. Free preview<\/a>.<\/p>\nUX Doesn\u2019t Disrupt, It Solves Problems<\/h2>\n
Bottlenecks<\/strong> are usually the most disruptive part of any company. Almost every team, every unit, and every department has one. It\u2019s often well-known by employees as they complain about it, but it rarely finds its way to senior management<\/strong> as they are detached from daily operations.<\/p>\n<\/p>\n <\/p>\n
<\/p>\n
<\/a>\n The Iceberg of Ignorance<\/a>: Sidney Yoshida discovered that leadership is usually unaware of the organization\u2019s real problems. (Large preview<\/a>)
\n <\/figcaption><\/figure>\nThe bottleneck can be the only senior developer on the team, a broken legacy tool, or a confusing flow that throws errors left and right — there\u2019s always a bottleneck, and it\u2019s usually the reason for long waiting times<\/strong>, delayed delivery, and cutting corners in all the wrong places.<\/p>\nWe might not be able to fix the bottleneck. But for a smooth flow of work, we need to ensure that non-constraint resources don\u2019t produce more<\/strong> than the constraint can handle. All processes and initiatives must be aligned to support and maximize the efficiency of the constraint.<\/p>\nSo before doing any UX work, look out for things that slow down the organization. Show that it\u2019s not UX work that disrupts work, but it\u2019s internal disruptions that UX can help with<\/strong>. And once you\u2019ve delivered even a tiny bit of value, you might be surprised how quickly people will want to see more of what you have in store for them.<\/p>\nThe Work Is Never Just \u201cThe Work\u201d<\/h2>\n
Meetings, reviews, experimentation, pitching, deployment, support, updates, fixes — unplanned work blocks other work from being completed. Exposing the root causes of unplanned work<\/strong> and finding critical bottlenecks that slow down delivery is not only the first step we need to take when we want to improve existing workflows, but it is also a good starting point for showing the value of UX.<\/p>\n<\/p>\n <\/p>\n
<\/p>\n
<\/a>\n The work is never just \u201cthe work.\u201d<\/a> In every project — as well as before and after it — there is a lot of invisible, and often unplanned, work going on. (Large preview<\/a>)
\n <\/figcaption><\/figure>\nTo learn more about the points that create friction in people\u2019s day-to-day work, set up 1:1s with the team<\/strong> and ask them what slows them down. Find a problem that affects everyone. Perhaps too much work in progress results in late delivery and low quality? Or lengthy meetings stealing precious time?<\/p>\nOne frequently overlooked detail is that we can\u2019t manage work that is invisible. That\u2019s why it is so important that we visualize the work first<\/strong>. Once we know the bottleneck, we can suggest ways to improve it<\/strong>. It could be to introduce 20% idle times if the workload is too high, for example, or to make meetings slightly shorter to make room for other work.<\/p>\nThe Theory Of Constraints<\/h2>\n
The idea that the work is never just \u201cthe work\u201d is deeply connected to the Theory of Constraints discovered by Dr. Eliyahu M. Goldratt. It showed that any improvements made anywhere beside the bottleneck are an illusion<\/strong>.<\/p>\nAny improvement after the bottleneck is useless<\/strong> because it will always remain starved, waiting for work from the bottleneck. And any improvements made before the bottleneck result in more work piling up<\/strong> at the bottleneck.<\/p>\n<\/p>\n <\/p>\n
<\/p>\n
<\/a>\n Components of UX Strategy<\/a>: it\u2019s difficult to build confidence in your UX work without preparing a proper UX strategy ahead of time. (Large preview<\/a>)
\n <\/figcaption><\/figure>\nWait Time = Busy \u00f7 Idle<\/h3>\n
To improve flow, sometimes we need to freeze the work and bring focus to one single project. Just as important as throttling the release of work<\/strong> is managing the handoffs<\/strong>. The wait time for a given resource is the percentage of time that the resource is busy divided by the percentage of time it\u2019s idle. If a resource is 50% utilized, the wait time is 50\/50, or 1 unit.<\/p>\nIf the resource is 90% utilized, the wait time is 90\/10, or 9 times longer. And if it\u2019s 99% of time utilized, it\u2019s 99\/1, so 99 times longer than if that resource is 50% utilized. The critical part is to make wait times visible<\/strong> so you know when your work spends days sitting in someone\u2019s queue.<\/p>\nThe exact times don\u2019t matter, but if a resource is busy 99% of the time, the wait time will explode.<\/p>\n
Avoid 100% Occupation<\/h3>\n
Our goal is to maximize flow: that means exploiting the constraint but creating idle times for non-constraint<\/strong> to optimize system performance.<\/p>\nOne surprising finding for me was that any attempt to maximize the utilization of all resources — 100% occupation<\/strong> across all departments —\u00a0can actually be counterproductive<\/strong>. As Goldratt noted, \u201cAn hour lost at a bottleneck is an hour out of the entire system. An hour saved at a non-bottleneck is worthless.\u201d<\/em><\/p>\nRecommended Read: \u201cThe Phoenix Project\u201d<\/h3>\n<\/p>\n <\/p>\n
<\/p>\n
<\/a>\n \u201cThe Phoenix Project<\/a>\u201d by Gene Kim, Kevin Behr, and George Spafford is a wonderful novel about the struggles of shipping. (Large preview<\/a>)
\n <\/figcaption><\/figure>\nI can only wholeheartedly recommend The Phoenix Project<\/em><\/a>, an absolutely incredible book that goes into all the fine details of the Theory of Constraints<\/strong> described above.<\/p>\nIt\u2019s not a design book but a great book for designers who want to be more strategic about their work. It\u2019s a delightful and very real read about the struggles of shipping<\/strong> (albeit on a more technical side).<\/p>\nWrapping Up<\/h2>\n
People don\u2019t like sudden changes and uncertainty, and UX work often disrupts their usual ways of working. Unsurprisingly, most people tend to block it by default. So before we introduce big changes, we need to get their support for our UX initiatives.<\/p>\n
We need to build confidence and show them the value that UX work can have<\/strong> — for their<\/em> day-to-day work. To achieve that, we can work together with them. Listening<\/strong> to the pain points they encounter in their workflows, to the things that slow them down.<\/p>\nOnce we\u2019ve uncovered internal disruptions<\/strong>, we can tackle these critical bottlenecks and suggest steps to make existing workflows more efficient. That\u2019s the foundation to gaining their trust<\/strong> and showing them that UX work doesn\u2019t disrupt but that it\u2019s here to solve problems.<\/p>\nNew: How To Measure UX And Design Impact<\/h2>\n
Meet Measure UX & Design Impact<\/a> (8h), a practical guide for designers and UX leads to measure and show your UX impact on business. Watch the free preview<\/a> or jump to the details<\/a>.<\/p>\n\n
\n 
\n <\/a>
\n<\/figure>\n\n\n
\n 2025-03-11T23:04:38+00:00
\n <\/header>\n
Good UX has a huge impact on business. But often, we need to build up confidence in our upcoming UX projects. For me, an effective way to do that is to address critical bottlenecks<\/strong> and uncover hidden deficiencies<\/strong> — the ones that affect the people I\u2019ll be working with.<\/p>\n Let\u2019s take a closer look at what this can look like.<\/p>\n .course-intro{–shadow-color:206deg 31% 60%;background-color:#eaf6ff;border:1px solid #ecf4ff;box-shadow:0 .5px .6px hsl(var(–shadow-color) \/ .36),0 1.7px 1.9px -.8px hsl(var(–shadow-color) \/ .36),0 4.2px 4.7px -1.7px hsl(var(–shadow-color) \/ .36),.1px 10.3px 11.6px -2.5px hsl(var(–shadow-color) \/ .36);border-radius:11px;padding:1.35rem 1.65rem}@media (prefers-color-scheme:dark){.course-intro{–shadow-color:199deg 63% 6%;border-color:var(–block-separator-color,#244654);background-color:var(–accent-box-color,#19313c)}}<\/p>\n This article is part of our ongoing series<\/strong> on UX<\/a>. You can find more details on design patterns and UX strategy<\/strong> in Smart Interface Design Patterns<\/a> \ud83c\udf63 — with live UX training coming up soon. Free preview<\/a>.<\/p>\n Bottlenecks<\/strong> are usually the most disruptive part of any company. Almost every team, every unit, and every department has one. It\u2019s often well-known by employees as they complain about it, but it rarely finds its way to senior management<\/strong> as they are detached from daily operations.<\/p>\n <\/p>\n <\/a> The bottleneck can be the only senior developer on the team, a broken legacy tool, or a confusing flow that throws errors left and right — there\u2019s always a bottleneck, and it\u2019s usually the reason for long waiting times<\/strong>, delayed delivery, and cutting corners in all the wrong places.<\/p>\n We might not be able to fix the bottleneck. But for a smooth flow of work, we need to ensure that non-constraint resources don\u2019t produce more<\/strong> than the constraint can handle. All processes and initiatives must be aligned to support and maximize the efficiency of the constraint.<\/p>\n So before doing any UX work, look out for things that slow down the organization. Show that it\u2019s not UX work that disrupts work, but it\u2019s internal disruptions that UX can help with<\/strong>. And once you\u2019ve delivered even a tiny bit of value, you might be surprised how quickly people will want to see more of what you have in store for them.<\/p>\n Meetings, reviews, experimentation, pitching, deployment, support, updates, fixes — unplanned work blocks other work from being completed. Exposing the root causes of unplanned work<\/strong> and finding critical bottlenecks that slow down delivery is not only the first step we need to take when we want to improve existing workflows, but it is also a good starting point for showing the value of UX.<\/p>\n <\/p>\n <\/a> To learn more about the points that create friction in people\u2019s day-to-day work, set up 1:1s with the team<\/strong> and ask them what slows them down. Find a problem that affects everyone. Perhaps too much work in progress results in late delivery and low quality? Or lengthy meetings stealing precious time?<\/p>\n One frequently overlooked detail is that we can\u2019t manage work that is invisible. That\u2019s why it is so important that we visualize the work first<\/strong>. Once we know the bottleneck, we can suggest ways to improve it<\/strong>. It could be to introduce 20% idle times if the workload is too high, for example, or to make meetings slightly shorter to make room for other work.<\/p>\n The idea that the work is never just \u201cthe work\u201d is deeply connected to the Theory of Constraints discovered by Dr. Eliyahu M. Goldratt. It showed that any improvements made anywhere beside the bottleneck are an illusion<\/strong>.<\/p>\n Any improvement after the bottleneck is useless<\/strong> because it will always remain starved, waiting for work from the bottleneck. And any improvements made before the bottleneck result in more work piling up<\/strong> at the bottleneck.<\/p>\n <\/p>\n <\/a> To improve flow, sometimes we need to freeze the work and bring focus to one single project. Just as important as throttling the release of work<\/strong> is managing the handoffs<\/strong>. The wait time for a given resource is the percentage of time that the resource is busy divided by the percentage of time it\u2019s idle. If a resource is 50% utilized, the wait time is 50\/50, or 1 unit.<\/p>\n If the resource is 90% utilized, the wait time is 90\/10, or 9 times longer. And if it\u2019s 99% of time utilized, it\u2019s 99\/1, so 99 times longer than if that resource is 50% utilized. The critical part is to make wait times visible<\/strong> so you know when your work spends days sitting in someone\u2019s queue.<\/p>\n The exact times don\u2019t matter, but if a resource is busy 99% of the time, the wait time will explode.<\/p>\n Our goal is to maximize flow: that means exploiting the constraint but creating idle times for non-constraint<\/strong> to optimize system performance.<\/p>\n One surprising finding for me was that any attempt to maximize the utilization of all resources — 100% occupation<\/strong> across all departments —\u00a0can actually be counterproductive<\/strong>. As Goldratt noted, \u201cAn hour lost at a bottleneck is an hour out of the entire system. An hour saved at a non-bottleneck is worthless.\u201d<\/em><\/p>\n <\/p>\n <\/a> I can only wholeheartedly recommend The Phoenix Project<\/em><\/a>, an absolutely incredible book that goes into all the fine details of the Theory of Constraints<\/strong> described above.<\/p>\n It\u2019s not a design book but a great book for designers who want to be more strategic about their work. It\u2019s a delightful and very real read about the struggles of shipping<\/strong> (albeit on a more technical side).<\/p>\n People don\u2019t like sudden changes and uncertainty, and UX work often disrupts their usual ways of working. Unsurprisingly, most people tend to block it by default. So before we introduce big changes, we need to get their support for our UX initiatives.<\/p>\n We need to build confidence and show them the value that UX work can have<\/strong> — for their<\/em> day-to-day work. To achieve that, we can work together with them. Listening<\/strong> to the pain points they encounter in their workflows, to the things that slow them down.<\/p>\n Once we\u2019ve uncovered internal disruptions<\/strong>, we can tackle these critical bottlenecks and suggest steps to make existing workflows more efficient. That\u2019s the foundation to gaining their trust<\/strong> and showing them that UX work doesn\u2019t disrupt but that it\u2019s here to solve problems.<\/p>\n Meet Measure UX & Design Impact<\/a> (8h), a practical guide for designers and UX leads to measure and show your UX impact on business. Watch the free preview<\/a> or jump to the details<\/a>.<\/p>\nUX Doesn\u2019t Disrupt, It Solves Problems<\/h2>\n
<\/p>\n
\n <\/figcaption><\/figure>\nThe Work Is Never Just \u201cThe Work\u201d<\/h2>\n
<\/p>\n
\n <\/figcaption><\/figure>\nThe Theory Of Constraints<\/h2>\n
<\/p>\n
\n <\/figcaption><\/figure>\nWait Time = Busy \u00f7 Idle<\/h3>\n
Avoid 100% Occupation<\/h3>\n
Recommended Read: \u201cThe Phoenix Project\u201d<\/h3>\n
<\/p>\n
\n <\/figcaption><\/figure>\nWrapping Up<\/h2>\n
New: How To Measure UX And Design Impact<\/h2>\n
\n
\n <\/a>
\n<\/figure>\n