Halvor William Sanden

Iterating instead of redesigning

When we work as if interfaces can reach completion, our fixes and new features tend to turn into redesign projects. We set out to make things right this time around; we might improve them but also change them to a degree where we introduce new issues.

This form of redesign not only makes testing both less viable and valuable, but it also hinders building the team’s experience.

We can counter this by iterating.

The unfinished business-business #

Interfaces are production-free

Interfaces are living pieces of work. Their ability to have something changed independently on a microscopic level, and the potential for it to make a significant difference, makes them versatile in a way that step-wise workflows cannot exploit.

When we must perform set steps and phases to change the interface noticeably, it’s inefficient and contradictory to its nature and properties. Such workflows create pressure to have a minimum number of changes before justifying firing up the process to get as much value as possible from a development phase.

Iteration enables us to work primarily without design and production phases and vice versa.

Continuous experience #

A project can still finish even if the interface continues to iterate.

It can adapt to user feedback, new features, new requirements, new technology and deprecation.

The work is not constant but continuous – we can at any time continue working on it because the interface and its code is, to a great extent, a tale of its process. We can improve it on shorter notice, faster and with more certainty when we don’t have to run projects with stop-inducing steps. It takes the pressure off of starting from scratch to change something.

Increased collective experience #

Getting things right is not what drives us. We are driven by building better interfaces and better teams with each iteration.

It gives us an unbroken streak of test data and experience that leads to stronger interfaces, better services, decisions we will repeat and some we will not.

The iterating team evolves beyond the redesigning one. Interfaces are improved gradually from and in what we have, giving users continuation while we gain continuous experience and domain knowledge through a direct connection to the things we make. Code, the thing interfaces are made of, provides that otherwise unattainable interface expertise.

It leads to ownership, responsibility and trust, something that redesign and hand-offs hinder and risk erasing.

Redesign is waterfall #

The threshold between iteration and redesign depends more on how we work than the size of the changes we make.

Redesigning is like restarting a cycle of sequential phases. No matter how small these cycles are, it’s still a waterfall or production line, a sequential-functional team essentially churning out new interfaces instead of improving the current ones.

In contrast to continuous and iteratively interface making, redesign breaks off from the service’s environment. When designing separately and using re-implementation to fill a lost connection to the interface, the interface isn’t part of its own process.

To not make testing pointless #

Increased experience lowers the need for testing. We should be able to figure out certain things independently, for instance, which one of two wildly different solutions is the best. If we spend time getting users to tell us what we already know, we are doing something wrong.

Testing provides the most meaningful results when versions are comparable. When able to make small enough changes to make a difference and still have the service be comparable to its previous release, we can tell the effect of a change, keep working on it or revert it.

Enabling more minor changes over time instead of one big launch also creates less friction for the users as long as the interface isn’t constantly changed.