Working With Founders Who Communicate In Screens

A founder I worked with brought me into the office on a Tuesday and unfolded six sheets of printer paper across the kitchen counter. Each sheet had a different sketch of the same screen, drawn in three different marker colours, with arrows looping between sketches and short notes scrawled in the margins. He started talking about the company. He did not talk about the screens.

For the first ten minutes the conversation looked like it was about strategy. Markets, customer segments, competitor pressure, the next round. The screens stayed on the counter. After the strategic part of the conversation finished, he tapped one of the sketches and said, “This is what it looks like.” Then he watched my face for the reaction.

The sketch was the conclusion. Everything before it was the work the sketch was doing.

What the sketch is actually for

A founder who sketches an interface to explain a company is doing something specific. The interface is the densest artefact the company produces. It encodes the answer to dozens of questions the founder has been thinking about for weeks. Who the user is. What the user wants. What the product does first, second, and never. How the company makes money. What competitors get wrong. The sketch carries all of these answers compressed into a single picture, and the picture is the test of whether the answers fit together.

If the sketch holds up, the strategy holds up. If the sketch reveals a contradiction, the strategy contains a contradiction the founder had not noticed. The sketch is the strategic argument made visible. The founder is not asking the designer to redraw it. The founder is asking the designer to read it.

This is the part most designers miss in the first encounter. The instinct, especially the instinct of a designer trained in process rigour, is to push back on the sketch as a premature artefact. “We should do research before we design the interface.” “We should map the journey first.” “We should sketch alternatives.” All of those instincts are correct in a different context. In this context they read as missing the point, because the sketch was never an interface in the first place.

The sketch is the strategy compressed into the only artefact the founder trusts the team to read carefully.

How to translate the sketch back

A useful skill for designers working with founders is the ability to look at a sketch and reconstruct the strategic argument it encodes. The reconstruction is usually a sequence of statements like the following. The user this product is for is someone who. The thing the user wants most is. The thing this product does that competitors do not is. The first interaction the user has is. The interaction the user pays for is. Each of these statements can be inferred, with reasonable confidence, from a sketch of the primary screen.

The translation matters because the founder’s stated strategy and the strategy embedded in the sketch are sometimes different. The founder will say the product is for product managers, while the sketch is clearly designed for engineering leads. The founder will say the company makes money on usage, while the sketch shows a flow that monetises on storage. The translation surfaces the disconnect. The conversation that follows is one of the most valuable conversations a designer can have with a founder, because it forces the strategic decisions to become explicit.

A useful question to bring to the conversation is what would have to be true for the sketch to be wrong. The founder’s answer to this question reveals which assumptions are load-bearing and which are decorative. The load-bearing assumptions deserve research. The decorative ones can be revised quickly without breaking anything. The designer who can identify the load-bearing assumptions becomes the most useful person in the room, because the founder has been carrying those assumptions silently and is usually relieved to see them named.

When sketching becomes a way to avoid the work

There is a wrinkle. Founders who sketch productively use the sketch as a thinking tool. Founders who sketch unproductively use the sketch as a substitute for thinking. The two cases look identical at first glance, and the difference becomes apparent only after several weeks of working together.

The productive sketcher revises the sketch as new information arrives. A user interview surfaces a gap. The sketch changes. A competitor ships a feature. The sketch changes. The team builds a prototype and learns something. The sketch changes again. Each revision incorporates the new information into the strategic argument the sketch is making.

The unproductive sketcher treats the sketch as the answer that the world has not yet validated. New information arrives that contradicts the sketch. The sketcher dismisses the information. Another user interview. Same dismissal. The sketch becomes a fortress the founder defends against contradictory evidence, and the team learns to bring news the sketch will accept rather than news the company needs.

The designer working with the unproductive sketcher cannot fix this directly. The pattern is structural and personal, not a craft issue. What the designer can do is make the load-bearing assumptions explicit early, ideally in writing the team can reference. When the sketch starts to fortress against new information, the designer has a record of what the sketch was supposed to be doing and can ask whether the sketch is still doing it. Sometimes this question is enough. Sometimes it is not, and the designer learns something about the company that informs the next decision.

The founder, the designer, and the screen

The most productive working relationships I have observed between designers and sketching founders share a particular dynamic. The founder sketches. The designer translates. The founder revises in response to the translation. The designer designs the interface that serves the revised strategy. The interface is rarely a literal version of the founder’s sketch, and the founder is rarely surprised by this, because the translation has already done the work of separating the strategy from the artefact.

The founder who comes from this kind of relationship usually says something like, “The sketches were a way of thinking out loud. The actual interface needed to be different, but the sketches were how we got there.” This is the right read. The sketches were strategy work. The interface is the result of the strategy work being done.

The designers who struggle with this dynamic tend to fall into one of two failure modes. The first is to take the sketch literally and ship the interface the sketch describes, which usually fails because the sketch was an argument, not a spec. The second is to dismiss the sketch as amateur and rebuild from scratch without engaging with the strategic argument the sketch was making, which leaves the founder feeling unheard and the interface feeling disconnected from the company.

The middle path, which is also the harder path, is to engage with the sketch as the strategic artefact it is. Read it. Translate it. Test the translation with the founder. Revise both the strategy and the interface in response to the test. Repeat until the interface and the strategy fit together, and the founder no longer needs to sketch the strategy because the interface is the strategy made visible.

The founders who hire designers and let them do this work tend to build companies whose products feel coherent. The founders who do not, do not.

The sketch was always a stand-in for a conversation. The conversation is the work.