Cycles: Design in an Iterative Workflow

For years, we worked on our projects using the waterfall method: concept, sketch, design, front-end, back-end, and handover. It’s a solid method because the foundation of any process is to communicate concrete steps effectively. However, as you grow in projects and experience, you gradually realize that you’re looking for a more flexible and engaging process. Before I continue discussing this new process, let me share a bit of history.

Scrum as the Foundation

A year and a half ago, Topicus asked us to set up the design system for Digdag. Digdag is an application suite for childcare—think of apps and responsive web apps for childcare centers, educators, and parents. At that time, the Digdag development team began using the Scrum methodology, and I participated in that process.

Working with Scrum is great; with a sprint every two weeks, you know exactly what is coming. After each sprint, you decide what will happen in the next sprint. Evaluations and experiments led to a continuously stronger Scrum process during the development of Digdag.

The beauty of Scrum is focus. By concentrating on one component, you achieve better quality. That appealed to us as well. However, Scrum comes with rules that don’t suit a small team working on multiple projects simultaneously. With Scrum, you work full-time in a fixed team. We needed a Scrum method that serves small design teams—one where you work just a few days on a project, with perhaps a maximum of two or three people.

Cycles

After a brief and energetic brainstorming session, the Cycles were born. A Cycle lasts approximately one to three weeks during which a concrete component is developed. This is a significant departure from the waterfall method: designing a website or web application cycle by cycle, where in principle the site could go live after a single Cycle.

Cycles also solve another problem inherent in the waterfall method: fixed pricing. It is difficult to accurately estimate the cost of a project upfront using the waterfall method. With Cycles, you can agree on pricing on a per-Cycle basis.

Guidelines for Cycles

• Cycles last on average one to three weeks, similar to Scrum.
• You decide how many days per week you work on a Cycle for a project—usually one to three days.
• Within a Cycle, you deliver at least one concrete, working component.
• The content of the Cycles is determined in a preliminary phase through user stories. Based on priority, we decide the next Cycle.
• With every Cycle, the client is actively involved.

Three Steps

• Brainstorming and sketching with the client: This step is important; as designers we know a lot about the web, but the client knows everything about their industry, organization, or product. Involve your client actively—brainstorm and sketch on a whiteboard.
• Designing and developing in HTML/CSS.
• Testing and evaluating.

Pitfalls

Not everything can be addressed with Cycles, so there are some pitfalls:

• Don’t lose sight of the overall concept: Keep the main goals clear.
• The design system can deteriorate: Always ensure consistency and neatness in both design and code.

Cycles represent our interpretation of an iterative design workflow and will continue to evolve over time. So far, we have executed six projects using Cycles; as we progress further, I will post an update with findings and adjustments to the Cycles.

— This post was originally written on the Studio Wolf blog.