Iteration

At GitLab, we iterate to do the smallest valuable thing to get fast feedback and efficiently reach a desired end goal. Feedback can be from internal users (dogfooding), or through feedback from our broader user community. We validate each iteration and adjust, but not at the expense of the user experience that we deliver to our customers.

Back to the universal principles

Under, just right, over.

SituationUnderJust RightOver
A big change that could be a sliceBuilds the whole thing before anyone uses it.Ships the smallest slice that a real user can complete, and learns from that.Ships a slice so thin that the user cannot do the job, and calls the confusion learning.
Feedback from the people who use itAsks the team what they think and never asks a user.Puts the slice in front of a user, or uses it yourself as they would, and changes the next slice.Rewrites the slice after every comment, including comments that do not bear on the goal.
The current experienceBreaks the path people already rely on so the iteration can move faster.Keeps the current path working and adds the slice beside it until the new one is ready.Preserves every old path forever and the iteration never replaces anything.
Validating the sliceStarts the next slice before you know whether this one worked.Names what would prove the slice worked, checks that, and only then continues.Demands statistical certainty from a handful of uses and stalls.
A step that teaches nothingPolishes an internal detail and calls it an iteration.Chooses a step that answers a real question about the end goal.Makes the step so large that the feedback arrives after the design is frozen.
Dogfooding the changeShips to users a thing the team has not tried to use.Uses it for a real task first, fixes the break you hit, and then asks others.Refuses to show users anything until the team is fully satisfied with it.

Sources and essays on this principle.

See something wrong or missing? Fix it in Facet.