Discovery through making

Raw Drafts began with a simple permission: an idea does not need to be finished before it can be made visible. A draft is usually treated as an incomplete version of something else, a temporary stage on the way to an article, a film, a product, or an argument worthy of being shown. The finished work is considered the real work, while the draft is merely tolerated. I am beginning to think that this gets the relationship backwards. The draft is often where the work is actually discovered.

Many of my ideas do not arrive as complete thoughts. They begin as fragments, recurring interests, unexplained attractions, or questions I cannot yet phrase properly. Writing about them does not simply record what I already know. The writing changes the thought. A sentence creates a distinction I had not noticed. A paragraph reveals that the supposed topic is only the surface of another one. An example that initially seemed minor becomes the center of the argument. Sometimes I begin writing about one thing and only halfway through understand what I was actually trying to say.

The same thing happens when I design or build software. A prototype is a raw draft made interactive. It gives an unfinished idea enough structure to resist me. Before something exists, nearly every claim remains hypothetical. I can imagine that a feature is useful, that a workflow is natural, or that a problem is worth solving. Once the thing appears on a screen, even in a crude form, it begins to push back. The interface feels wrong. The data does not fit the categories I created. The supposedly important feature turns out to be boring, while a secondary detail suddenly contains the real idea. Making produces information that thinking alone cannot.

This is why I keep returning to the possibility of building small projects around many of my interests. I am interested in health, architecture, film, cities, accessibility, interaction design, finance, artificial intelligence, public infrastructure, music, maps, personal data, storytelling, and probably several other things that I will remember tomorrow. Conventional advice would tell me to narrow down, choose one field, commit to one identity, and stay focused long enough for the work to compound.

There is truth in this advice. Constantly beginning new projects can become a way of avoiding difficulty. Starting is exciting, while maintenance is repetitive. A new idea always looks cleaner than the project whose problems I now understand too well. At the same time, narrowing down too early can remove the conditions from which interesting work emerges. Some people seem to discover an idea and then build it. I often discover the idea by building around it.

One possible approach would be to list every major interest I have and begin a small project around each one. There could be a health project, an architecture project, a film project, an accessibility project, a project about cities, and another about personal data. Perhaps there would be ten or twelve in total, with an absolute maximum somewhere below twenty.

At first, this sounds chaotic. Twenty products would be impossible to maintain properly. Each would require design, code, infrastructure, content, user acquisition, bug fixes, documentation, and eventually some reason to continue existing. But these projects would not need to begin as products. They could begin as probes.

A probe is something built to make a question more concrete. It might be an interface, a database, a scoring system, a directory, a browser extension, a manual service, or a single workflow held together by scripts and human effort. Its purpose is not necessarily to succeed. Its purpose is to reveal. A film project might begin with a different way of describing films, based on rhythm, atmosphere, visual density, or emotional texture rather than genre. An architecture project might collect recurring spatial patterns rather than famous buildings. A health project might explore how personal data can become understandable without turning everyday life into a medical dashboard.

Each project begins with an interest, but the interest does not determine the final form. The form develops through contact with the material. This is where inspiration tends to appear. Before something exists, every decision is surrounded by imagination. You can imagine that people will care, that the market exists, that the data will be available, and that the technology will behave. Once the project exists, the questions change. Can the information actually be structured? Does the interface make the idea clearer? Would anyone return to it? What kind of labor does it require? Which part feels alive, and which part feels forced?

Projects often contain possibilities that were invisible in the original concept. A tool becomes a marketplace. A marketplace becomes a service. A personal experiment reveals a shared problem. An application produces a valuable dataset, method, community, or standard. The initial idea gives you permission to begin, but the work provides the real direction.

One idea I keep returning to sits somewhere between accessibility, interaction design, artificial intelligence, and product assurance. AI agents are becoming capable of performing more of the initial labor involved in creating digital products. They can generate interfaces, write code, inspect technical rules, check contrast, identify missing labels, test keyboard navigation, and map issues to accessibility standards. This should improve baseline compliance, but it may also create the illusion that accessibility has been solved.

A product can pass automated checks and still be exhausting, confusing, painful, or impossible to use. The missing expertise belongs to people who live with the consequences of design decisions. Someone who uses a screen reader understands problems that cannot be reduced to whether an element has the correct label. A person with limited mobility can identify interactions that are technically possible but practically difficult. Someone with hearing loss, low vision, dyslexia, cognitive disabilities, or another access need brings knowledge formed through repeated contact with systems that were not designed for them.

This suggests a platform where AI handles the first layer of technical analysis and people with accessibility needs provide paid, professional evaluation. The AI could scan the product, identify likely problem areas, generate test tasks, organize evidence, connect findings to standards, and produce an initial report. Human experts could then use the product, attempt real tasks, identify barriers, explain their impact, and evaluate whether the proposed fixes actually improve the experience.

The result would go beyond an accessibility audit. It would become a form of product assurance grounded in lived expertise. The people involved should not be treated as test subjects who appear at the end of the process to confirm whether the technical team did a good job. They are specialists whose knowledge affects what gets tested, how severity is understood, and what usability means.

The idea may eventually become a marketplace, but it may begin more effectively as a managed service. A company submits a website or application. Automated tools perform the technical review. One or more experts complete defined user journeys. The company receives evidence, priorities, recommended fixes, and a follow-up evaluation. The marketplace could emerge later, after the patterns of demand, matching, pricing, quality, trust, and compensation become visible.

I would not have reached this version of the idea by deciding in advance to build an accessibility app. It appears at the intersection of several interests, and it becomes clearer as the workflow is imagined, tested, and built. The larger opportunity may therefore be to treat these projects as parts of one studio rather than as unrelated startups.

Different domains often require similar structures: profiles, submissions, evaluations, evidence, reports, maps, recommendations, scoring, expert matching, payments, and AI-assisted analysis. A project about accessibility may share infrastructure with a project about architecture. A health application may use the same personal data model as a finance tool. A platform for evaluating digital products may use the same reporting system as a service for evaluating physical spaces.

The common structure should not be designed upfront. That would create an abstract platform for imaginary future needs. Shared infrastructure becomes useful only after concrete projects repeatedly demand the same thing. The connections should be discovered through use.

This also creates a practical limit. I may have twenty documented interests, but only a few projects should be active at once. One can be the main commercial project. One can explore an adjacent field. One can remain strange, playful, or culturally driven. The others can wait without disappearing. An idea does not need a full application to remain alive. It can exist as a note, a prototype, a dataset, a domain name, an interface sketch, or a clearly phrased question.

A project can also be archived without becoming a failure. It may have produced a reusable component, a better question, a method, or a connection that becomes important elsewhere. The project does not need to survive for the discovery to matter.

Discovery through making does not remove the need for judgment. It still matters whether a project produces anything: users, revenue, reusable systems, distinctive data, a new capability, creative energy, or a meaningful insight. Some experiments should stop. Some should remain small. A few may deserve years. The difference is that the judgment happens in contact with something real.

Instead of demanding certainty before beginning, I can build structures that make learning cheaper. Instead of choosing one permanent identity, I can search for the recurring questions beneath different interests. Instead of treating unfinished experiments as evidence of failure, I can treat them as instruments that revealed something.

This is also the deeper meaning of Raw Drafts. It is not only a place for unfinished writing. It is a place for work that uses unfinishedness as a method. A draft is not simply something waiting to become complete. It is a way of thinking through form. It allows an idea to become visible before it becomes stable. It makes room for contradiction, revision, surprise, and movement.

The same principle can apply to an article, an interface, a product, a company, or an entire practice. Do not wait until the idea is complete before giving it form. Give it form so that it can become complete.

AI authorship note

This essay grew from Kris Haamer's idea of listing his many interests, building small applications around them, and allowing the act of making to reveal which ideas deserve to continue. AI supported the structuring, drafting, editing, and implementation. Kris is responsible for the original idea, the accessibility marketplace concept, the connection to Raw Drafts, and the decision to publish it.

Connected reading

• Software for One Afternoon
• The Internet Is a Studio Wall
• Digital Product Assurance Is Becoming a Field
• The Further You Go in UX, the Less It Looks Like UX