A team reaches the middle of a project and discovers that a simple interface change needs a new permission model. It looks like an engineering delay. But the costly question was there before anyone started building.
Shaping is the work between deciding an opportunity matters and committing a team to build. It turns a rough idea into a coherent, buildable solution path without creating the finished design or code.
Begin with a frame: where people struggle, what they do today, what happens as a result, and what they want to be different. Then set an appetite: the amount of team time the opportunity is worth, often two to six weeks. The appetite is a budget to design within, not a prediction of how long an unlimited solution will take.
Bring together people who understand the user, the design, and the system. A shaping session is not a status meeting, a brainstorming exercise, or a spec review. It is a few hours of working on the same problem, making and discarding provisional ideas, and deciding what belongs together.
-
Lay out the parts. Put the important screens, states, actions, rules, and constraints on a shared board. Some will not have a place yet.
-
Find different paths. Connect those parts into two or three plausible ways the product could work. Use an interaction schematic to show the screens or states, the actions people can take, and what changes when they act. This exposes the whole interaction before anyone worries about pixels.
-
Bring the system into view. Under the visible actions, name the permissions, data, functions, and services they depend on. A button labeled “Share” might require a new access rule, an invitation record, and a notification. This is where engineering knowledge reveals what an innocent-looking interface conceals.
-
Sketch and investigate selectively. If the arrangement of elements matters, draw a rough focal sketch of that part—not a finished mockup of every screen. If a technical, design, legal, or performance question could change the path, run a small spike and return with what you learned.
-
Check the fit. Compare the paths against the original struggle, desired outcome, appetite, cost, complexity, risks, and existing system. Identify what fits, what is weak, and what blocks a path. Move between the whole design and its troublesome details until the trade-offs are clear.
The point is not to remove every unknown. It is to find a way the parts can work together, expose the expensive surprises before implementation, and leave capable builders room to make the remaining decisions.
Stop when the team can explain the path, what is in and out, why it fits the appetite, which risks have been resolved, and where implementation still has latitude.
Then package the result in an Input Design Document so people who were not in the room can understand the same concept and build it without constant direction.
Put the method to work in the Shaping Board, or use the Figma playing field template for a collaborative shaping session.
The document records the shaping. It does not do the shaping.