UXDX Blog
The UXDX Blog has its own subscriptions, separate from our newsletters.
Every Feature Can Be Broken Down into Separate Releases
When proposing to break down a feature into smaller increments, the resistance often stems from a deeply ingrained belief: the feature will only work if all the requirements are in place. You’ve spent a lot of time understanding what customers want and designing prototypes to val
Read edition ↗
The Product Model #245 - Where Should You Focus Your Engineering Efforts
The "Not Invented Here" syndrome is a common challenge in software development, where teams often prefer building everything from scratch rather than leveraging existing solutions. While building custom solutions can provide unique value, it can also lead to wasted time and resou
Read edition ↗
How to Decide Where to Focus your Engineering Efforts (using Wardley Mapping)
“Yes, there are products that deliver some of the functionality we need for our feature, but those products are overkill; we only need a fraction of the functionality. By the time we integrate with the other product, we could have built it all ourselves.”
Read edition ↗The Product Model #244 - Breaking Down Complex Solutions
After doing fantastic Continuous Research and Continuous Design work, you have a validated prototype. The only problem is that it would take weeks or months to build. Most features fail to deliver the expected business value, so this is unacceptably long to work on the feature. W
Read edition ↗
Breaking a Complex Solution into Multiple Releases using User Story Mapping
Imagine you’re working on a team and you get a requirement to add a new expense tracking feature. The prototype has received rave reviews and the internal teams are really excited to start saving time on the monotonous receipt submission process. However, there is a significant c
Read edition ↗The Product Model #243 - Managing Test Case Explosion with Feature Flags
Feature flags let development teams release features incrementally.. However, they come with a significant challenge: test case explosion. As each feature flag essentially creates a duplicate version of the system, the number of potential paths requiring testing grows exponential
Read edition ↗
Managing Test Case Explosion with Feature Flags: Strategies and Solutions
When a system implements feature flags, each flag doubles the number of possible states the system can be in. One feature flag results in two different paths but with just 10 feature flags, there are theoretically 2¹⁰ (1,024) different combinations to test. Testing each configura
Read edition ↗The Product Model #242 - DevOps: A Cultural Change, Not a Technical Revolution
DevOps is often framed as a technical solution: continuous integration and delivery (CI/CD) pipelines, automated testing, and infrastructure as code. But the technology would be pointless without the necessary cultural changes.
Read edition ↗
DevOps: A Cultural Change, Not a Technical Revolution
Before DevOps, development teams often operated in isolation from QA and operations. Each group had its own goals:
Read edition ↗The Product Model #241: The Real Cost of Changing Designs
Duke Nukem Forever took over 14 years to develop due to a string of requirements changes, scope creep and unforeseen challenges. The team were struggling to create the graphics they needed with their game engine and decided to swap game engines after over a year and a half of wor
Read edition ↗
The Real Cost of Changing Designs
Duke Nukem Forever took over 14 years to develop due to a string of requirements changes, scope creep and unforeseen challenges. Originally announced in 1997 as the highly anticipated follow-up to the wildly successful Duke Nukem 3D, things didn’t go according to plan. The team w
Read edition ↗The Product Model #240: The Hidden Costs of Big Design Up Front
Even when people say they are working in an Agile environment, there is often a big design phase, and for good reason - a single new requirement can result in a complete redesign of the solution.
Read edition ↗
The Hidden Costs of Big Design Up Front (And How to Avoid Them)
The software delivery lifecycle includes six key stages: plan, analyse, design, build, test, and deploy. Whether you are following the Waterfall or Agile methodology, you will need to go through these stages but the difference lies in the size of the work you do in each stage. In
Read edition ↗