The Wiredcraft Way

The Wiredcraft Way is our shared approach to creating and improving digital products. It helps us move from understanding a problem to delivering something useful, then learning from how it performs. Strategy, design, engineering, data, and delivery work through the same steps together.

The six steps organize decisions and deliverables. A short engagement might capture an outcome on one page; a larger project might need a fuller investigation. We adjust the timing and depth as we learn. We make the work visible to the client and to each other so that assumptions, gaps, and changes can be discussed early.

Strategy: find the right direction

1. Research

We start with what we know, what we can observe, and what we still need to learn. That means collecting existing material such as research, analytics, product documentation, and business goals. We talk to users and stakeholders, look at the current experience, and ask where the constraints are. The goal is to understand the problem before committing to a solution.

Research usually produces three kinds of work:

• Discovery brings the available information together and identifies the questions we still need to answer.
• Audit examines what exists today, across the product, experience, technology, or data as relevant to the project.
• Benchmark looks at competitors and other useful examples. It gives us points of comparison and ideas to evaluate against the project’s needs.

The result is a clearer picture of the starting point, including evidence, assumptions, and risks. We return to research whenever new questions arise.

2. Align

Research is useful only when it helps people make decisions. We bring the team and client together around a shared understanding of the goal, who we are designing for, and how we will recognize progress. We discuss trade-offs openly: what is most valuable, what depends on something else, and what can wait.

Three outcomes help make that direction concrete:

• Brief captures the context, goal, users, definition of success, and important risks. It gives everyone a point of reference when decisions get harder later.
• Happy path shows the experience we want people to have, from how they arrive to what they need to accomplish and what happens next. A simple storyboard or journey can reveal gaps that a feature list misses.
• Roadmap organizes the major opportunities and dependencies into near- and longer-term priorities. The team reviews it as the project develops and new evidence emerges.

Alignment includes the people who will do the work. A direction that has not been discussed with design, engineering, and quality is difficult to execute well.

3. Prepare

We turn the agreed direction into work the team can start. This is where we clarify the scope, identify dependencies and gaps, and decide how the different disciplines will work together. We prepare enough detail to make the next decisions well, then refine it as the project moves forward.

• Blueprint brings together the initial design, technical, and data approaches. It may include an information architecture, solution architecture, design direction, or measurement plan, depending on the product.
• Planning describes the main work, timing, and dependencies. Assumptions and exclusions are made explicit so that everyone understands what the plan covers.
• Framework sets out how the team and client will collaborate: responsibilities, decision making, reviews, quality criteria, and how changes will be handled.

Preparation should reduce avoidable surprises. It should still leave room to change course when testing or delivery reveals something new.

Execution: make, release, and improve

4. Create

We build in short cycles so there is working material to discuss, test, and improve. Each cycle starts with a clear goal and work the team understands. Design, development, and quality stay involved as the work takes shape; testing and review happen throughout.

• Build produces a working increment. The team plans the work, makes decisions together, and checks the result against the agreed expectations.
• Update makes progress visible. We demonstrate what works, collect feedback, and identify gaps or issues while there is still time to act on them.
• Delivery closes the cycle and prepares the next one. We review what was delivered, reflect on how we worked, and decide what to prioritize next.

Feedback can reveal a missing requirement, a better approach, or a change in priority. See User story, Ensuring quality, and Retrospective and continuous learning for more on these practices.

5. Ship

Shipping is a team decision. It includes three connected activities:

• Green light confirms that the agreed features and acceptance criteria have been met, the right people have reviewed the work, and any issues that would prevent launch have been addressed. For some releases, this includes user acceptance testing with the client or intended audience.
• Release coordinates when and how the change goes live, how we communicate it, and how we will respond if it does not behave as expected.
• Monitoring keeps the team close to the product after launch so we can spot unexpected effects and respond quickly.

A successful deployment starts a period of observing real use.

6. Support

After launch, we look at both product outcomes and system health. Feedback, usage data, errors, and performance help us understand whether the work is doing what we intended.

• Tracking brings together the signals that show how people use the product and how reliably it runs.
• Maintenance resolves issues and keeps the product working as needs and conditions change. When something breaks, we also learn from the cause.
• Reporting shares what we have learned and what we recommend doing next. It connects evidence to a clear decision.

These findings may lead to a small fix, a new cycle of work, or a fresh look at the original assumptions. The process loops back to Research and Align whenever the evidence calls for it.

The Stack

Alongside the steps, we maintain a set of tools and techniques we trust to help produce the work. The choice depends on the problem, the team, and what we can support over time. See Technologies & tools for an overview of our technical choices.

For the handovers, decisions, and release coordination around an engagement, see Running a project.