Choose the first workflow your software should handle

Start with the work between two moments

A first software release needs a workflow small enough to finish and substantial enough for someone to use again. Begin with two observable moments: what starts the work, and what tells the person it is done. Between those moments, list the actions, decisions and handoffs. A workflow framed that way is easier to test than an ambition such as helping teams collaborate better.

Imagine a small studio receiving a client change request. The trigger is a request arriving. The finish is a confirmed answer with an owner and a next step. Between those points, someone checks the request, asks for missing information, compares it with the scope and communicates a decision. The first product might handle that sequence. It does not need to manage every part of the client relationship.

Observe a complete instance

Ask a prospective user to show a recent example from beginning to end. Let them use their current tools and explain the choices they made. Record the sequence rather than jumping to interface ideas. A pause may reveal missing information, an unclear responsibility or a deliberate review step. Those are different problems and can call for different products.

Use public or sanitized examples where possible. The observation does not require copying confidential client conversations. Note the type of information, the person responsible and the decision it supports. At the end, ask what the user had to remember that the tools did not show. That answer often points to the fragile part of the workflow: a promise, an exception or an unfinished handoff.

Compare three candidate workflows

For the studio, possible first workflows might be new request intake, weekly status preparation and final project handoff. Compare them on frequency, number of handoffs, cost of a mistake, clarity of the finish and access to test users. Write the evidence beside each judgment. A simple low, medium or high rating is useful only when the team can explain the event behind it.

Request intake may happen daily, require two people and end with a clear assignment. Weekly status preparation may be frequent but depend on many scattered project updates. Final handoff may have a clear result but occur too rarely for a short learning cycle. Those observations could make request intake the better first test. Another studio with a different pattern could make a different choice using the same comparison.

For this example, request intake offers the shortest repeatable test: a daily trigger, two people and a decision that can be checked. Status preparation depends on several updates arriving, while project handoff provides fewer opportunities to observe another complete instance. These are qualitative judgments for the illustrative studio, not measured scores.

Prefer a visible finish

A workflow with a visible finish gives both builder and user a way to judge the prototype. For a change request, the finish could be a decision sent to the requester with an owner and a next action. Avoid treating a record's creation as the finish if the user still has to do the important work elsewhere. The product should carry the job to a useful outcome.

Write the finish as a sentence a user can verify. The client knows the decision. The responsible person knows the next action. The evidence remains available. Those statements help the founder decide what belongs in the first release. A new dashboard is optional if the user can already complete the sequence without it. A missing notification may be essential if the requester otherwise never receives the answer.

Map the exception that changes the design

Choose one common exception before polishing the happy path. A request may arrive without enough detail. An owner may be unavailable. Two reviewers may disagree. Work through the case in the prototype and see whether the user can recover without inventing a workaround. The exception should teach something about the workflow, not expand the first release into a universal system.

For the request example, missing information might require a waiting state with a named next action. That state is different from an unassigned request. If both look identical, the tool will invite repeated checking. Give each state a plain description and make the person responsible visible. The user can then see why the work is paused and what would move it forward.

Build the record before the dashboard

A first prototype can begin with one well-designed record. It should contain the trigger, relevant evidence, current decision, responsible person and completion event. The dashboard can come later, once several real records show which overview is useful. Starting with a broad dashboard often hides the fact that the underlying workflow is still unclear.

GitHub documents customizable views over project records. Its tables, boards and custom fields are a useful reference for the difference between information and presentation. For a first product, choose the smallest stable record that supports the job. Then test which view makes the next action easiest to find. A board is a display choice, not the workflow itself.

Watch someone complete it

Give the prototype to a person who regularly does the job. Set up a realistic example, explain the intended outcome and let them proceed. When they hesitate, ask what they expected to happen. Avoid narrating the interface. If the founder has to explain every action, the session is testing a guided demonstration rather than the product.

Record where the user leaves the prototype, what they copy into another tool and which information they check twice. Those moments identify unfinished parts of the job. Some external tools should remain in the workflow, and the prototype can link them clearly. Other detours reveal a missing action. Decide based on the observed sequence rather than a desire to keep every click inside the new product.

Make the controls understandable

The first release should give actions names that describe their effect. A button labeled complete can be ambiguous if it both closes a request and sends a customer message. Separate the actions or explain the combined outcome before submission. Show errors where the user can correct them, and preserve the information they already entered.

W3C's forms tutorial recommends clear labels, grouped related controls and understandable notifications. Apply those principles during the prototype rather than treating them as decoration for a later release. A user who can understand the form and its confirmation is better placed to complete the workflow independently.

Decide what evidence earns another iteration

Before the next test, write down what would justify continuing. Perhaps several users complete the request sequence without help, return to it for another request and can explain its current state to a colleague. Those are concrete observations. A positive comment about the appearance is useful feedback, but it answers a different question from repeated use.

Keep the next release decision small. Fix a confusing state, remove an unused field or make a handoff explicit. If the workflow repeatedly fails to reach the intended finish, revisit the job before adding adjacent features. A founder can learn more from a complete narrow sequence than from a broad collection of partially connected screens.

Give the first workflow a lasting identity

A focused product can carry a broader name from its first release. RLER.com is one possible identity for a founder building beyond a single tool. The product description can name the narrow job while the brand stays consistent across the invitation, workspace and purchase order. Observe one real workflow end to end, choose the first useful finish, and build the smallest complete path to it.