
Dylan Field: The Browser Bet That Changed How Teams Design Together
Dylan Field and Evan Wallace spent years building Figma around a browser-first idea. Their founder story reveals why collaboration was a product decision.
The file is called final. Then someone changes it, sends another copy and calls that one final too. A designer sees one version, an engineer sees another, and a decision that should take minutes becomes a conversation about which document everyone is discussing. It is an ordinary workplace problem, but ordinary problems can conceal large opportunities. Dylan Field and Evan Wallace built Figma around a different assumption: design should happen in a shared place, accessible through the browser. Their story is interesting because the ambition demanded more than a new interface. It required people to change how they worked together.
Two students and an unfashionable constraint
Field and Wallace met at Brown University and started Figma in 2012. Their early work explored whether design software could run in the browser with the performance people expected from desktop applications. WebGL, a technology that allows browser software to use graphics processing capabilities, was part of that foundation.
The technical choice served a broader product idea. A browser could make work easier to access and share. Instead of treating collaboration as something that happened after a designer finished, the product could make it part of the environment in which the work developed.
That sounds natural now because shared web documents are familiar. It was not a trivial extension of an existing habit. Design software had demanding performance requirements, and professional users had established expectations about the tools they relied on.
For a founder, a constraint like this can be productive when it forces clarity. The question becomes which benefit is important enough to justify the difficulty. Building in a browser merely because it is fashionable would be weak reasoning. Building there because access and shared participation are central to the customer promise is a more substantial bet.
Three years before the announcement
Figma entered closed beta in 2015 after several years of development. Field’s later account describes a long period of building before the public could see the result. The company’s filing similarly describes testing and iteration with users before launch.
This stretch is easy to compress into a sentence and difficult to live through as an organisation. A technical possibility is not yet a product. The software must become responsive, understandable and dependable enough for people to use on work that matters to them.
The useful lesson is not that founders should spend years in silence. Long development periods can conceal weak demand as easily as they can protect important engineering work. What matters is the relationship between the work being done and the uncertainty it resolves.
Does a prototype demonstrate the promised interaction? Do users understand why it is different? Can the team identify what prevents someone from making it part of a real workflow? Those questions are more informative than counting the months before a launch. Field and Wallace’s journey makes room for a less cinematic truth: sometimes the difficult part is patiently making an ambitious experience function.
The browser changed who could enter the room
Field has written that the browser represented collaboration, transparency and access to the founding team. He also recalled resistance from people who saw the approach as a challenge to established design practices. That tension is central to understanding the Figma founder story.
A tool can alter the social structure around work. When a design is easier to open, more people can observe it. When feedback happens near the work, the designer may have fewer explanations to repeat. But greater visibility can also create anxiety about unfinished ideas being judged too soon.
That is why collaboration is not simply a feature checklist. A team needs shared expectations about when to comment, who decides and what an early draft means. Software can lower barriers to participation without automatically making participation constructive.
For entrepreneurs building collaborative products, this is a valuable distinction. The product must make a new behaviour possible and help people feel confident performing it. An invitation, a permission setting or a clear distinction between viewing and editing can shape adoption as strongly as a visually impressive demonstration. The promise is shared progress; the risk is shared confusion.
A product decision became a distribution advantage
There is an important business implication in putting work behind a link. If someone needs a colleague to review a design, sharing the work can introduce that colleague to the product. The act of using the tool may therefore expose other potential users to it.
This is an interpretation of the product structure, not a claim that every shared link becomes a paying customer. Distribution still depends on usefulness, organisational purchasing decisions and the quality of the experience. A product can spread widely and still struggle to support a sustainable business.
Yet the relationship is worth studying. Many founders treat acquisition and product design as separate departments. Collaborative tools show how closely they can interact. The customer’s normal workflow can create a reason for another person to enter the same environment.
The discipline is to avoid turning that interaction into a burden. If every invitation feels like an advertisement, the product damages the collaboration it promises. The strongest introduction is often a useful piece of work that someone already needs to see. Growth becomes more credible when participation delivers value before asking for commitment.
The co-founder story belongs in the headline too
Field is Figma’s highly visible co-founder, but the company began with Wallace as well. Remembering that partnership prevents a common distortion in entrepreneurial storytelling: attributing an organisation’s technical and commercial development to the personality most often interviewed about it.
The broader lesson concerns complementary strengths. A difficult software product needs people who can recognise a meaningful problem, explore technical approaches, judge the experience and keep the company moving through uncertainty. Those contributions do not always come from the same person.
For an early team, a shared direction is more useful than identical skills. The founders must be able to make trade-offs together, especially when the attractive product story conflicts with the engineering reality. A decision that looks small from outside may determine whether the system can deliver its central promise.
Readers studying Field’s career should therefore examine the partnership as part of the business model’s origins. The ability to build the product was not a detail added after the idea. It was part of what made the idea commercially meaningful. Vision without execution would have remained an interesting argument about the future of design.
Going public did not finish the product argument
Figma went public on July 31, 2025. In his founder letter, Field returned to the ambition of helping people turn ideas into reality and discussed the importance of design as AI changes software. That was a dated milestone in the company’s development, not the conclusion of its work.
The distinction matters when writing about businesses that began as startups and later became public companies. Their origins can illuminate entrepreneurial decisions without implying that they remain early-stage ventures. The pressures of a larger organisation are different from those facing two founders with a prototype.
A broader product range creates new questions about coherence. Can users still understand where to begin? Does each addition strengthen a meaningful workflow? Can the company preserve the quality of its central experience while serving more roles?
AI makes those questions sharper rather than less relevant. Generating an output is not the same as knowing what should be built, whether it meets a need or how it fits into an existing system. Field’s public discussion of design points toward a continuing problem: as production becomes easier, judgement about the result still matters.
The same principle applies to leadership. As more people participate in building a product, the founder cannot be the only source of context. Teams need to understand why a decision matters, what trade-off it accepts and how success will be judged. Otherwise, a company can reproduce internally the very fragmentation its product removes for customers. A shared canvas is useful because it connects work; a shared purpose is useful because it connects decisions. Neither means that everyone must agree on every detail. Both require enough clarity for people to make progress without constantly reconstructing the conversation. That organisational problem belongs alongside the technical achievements in any serious account of scaling.
What a founder can borrow from the Figma journey
The most transferable part of this story is the connection between a technological choice and a human problem. Field and Wallace did not merely put an existing category online. Their browser-first approach changed how people could encounter, discuss and contribute to the work.
For another founder, the corresponding question is where a workflow is divided for historical reasons. Which handoff exists because the tools cannot share context? Where are customers repeatedly exporting, explaining or recreating something? An opportunity may lie in removing that separation, provided the result is genuinely better for the people involved.
There is also a caution about patience. Commitment to an idea does not remove the need for evidence. The right response to a difficult build is to make the uncertainty smaller, not to treat difficulty itself as proof of importance. Progress becomes easier to judge when the team can name the assumption a piece of work is testing.
Explore the product through Figma’s official website. For another creative infrastructure story, see our coverage of Fal. Our Brian Chesky founder story looks at another company whose product depended on changing human behaviour.
Field’s journey began with the possibility that people could design in the same place. Its lasting challenge is making that shared place useful enough that they want to return.
Leave a comment
Your email address will not be published. Required fields are marked *
Add a newsletter to your widget area.








