Typable comes from the idea that every good project starts by making things clear enough to put into words.
Before design, before code, before execution, there is a brief. Not necessarily a document, and not necessarily something complete. More often, it is a process of turning vague ideas, needs, assumptions and constraints into something that can be written, discussed and understood.
Something typable.
That idea sits at the beginning of how we work. Projects rarely arrive as clearly defined problems; they usually arrive as solutions: we need a new website, we need to rebrand, we need an app, we should use AI, we need to make this easier to use. Maybe.
Those requests might eventually become the right answer, but they are still only a starting point. Our first job is to understand what needs to change, and why.
Before deciding what to make, we try to understand the situation around it. Who is this for? What already exists? What is working? What is not? Why does the project matter now? What does the business need from it? What constraints are already part of the picture?
We are not trying to remove every uncertainty. We are trying to identify which uncertainties actually matter.
Sometimes that process confirms the original brief. Sometimes it changes it completely. Both are useful outcomes. The brief, for us, is not something that gets handed over and then frozen. It is something we shape together.
A good brief does not need to contain the answer. It needs to make the problem clear enough that useful decisions can begin.
If we cannot explain what we are trying to solve, we are probably not ready to solve it.
Understanding does not happen only through research, meetings and documents. At some point, we need to make something: a sketch, a prototype, a content structure, a visual direction, a piece of code, a rough interaction, sometimes just a few lines of copy.
Making an idea tangible changes the conversation. Things that sounded convincing in a meeting can suddenly feel wrong on a screen. A content model can reveal a problem in the information architecture. A prototype can expose an assumption nobody had noticed. Working code can make a technical constraint real.
So we move continuously between thinking and making.
Research → make → observe → adjust.
Not because every project follows the same process, but because some questions can only be answered once an idea becomes real.
For us, making is not what happens after thinking. Making is part of thinking.
Strategy, brand, design, content and technology influence one another too much to be treated as separate production stages. A technical constraint can change an interaction, a design decision can affect the content model, a business objective can reshape the product, and a conversation about language can reveal that the real problem is not the interface at all.
When disciplines work in isolation, those connections tend to surface late. Then they become compromises. We would rather discover them early.
That does not mean everyone does everything. It means everyone understands enough of the problem to make better decisions within their own discipline.
A designer should understand how something will be built. A developer should understand why an interaction behaves the way it does. The people working on the brand should understand where that brand actually has to live.
Different skills, same conversation.
We like ambitious projects, new technology and experimenting with things we have not done before. But complexity needs to earn its place.
Sometimes the right answer is a sophisticated digital experience involving motion, data, APIs and custom technology. Sometimes it is a very simple page with good typography and clear information. Neither one is inherently more interesting.
What matters is whether the solution fits the problem.
When we are deciding whether to add something, we tend to ask:
If the last answer is the strongest one, we probably do not need it.
Technology is part of our work, but it is not the reason the work exists. New tools constantly change what can be built, and that is exciting, but novelty is not a strategy.
The same is true for AI.
The interesting question is not:
Can we add AI to this?
It is:
What becomes meaningfully better if we do?
Sometimes AI creates a genuinely new interaction, removes repetitive work or makes information easier to access. Sometimes the better solution is a search field, a well-designed form or simply clearer content.
We are interested in technology when it expands the solution space, not when it simply expands the feature list.
Tools change quickly. Good judgement lasts longer.
Every project has constraints: budget, time, technology, existing systems, available content, internal processes, regulations and team capabilities.
We do not treat those things as obstacles that sit outside the creative process. They are design material.
A constraint forces a decision. It makes us choose what is essential, what can wait and where effort will have the greatest effect. That can be uncomfortable, but it is often useful.
Unlimited possibility rarely creates clarity. A well-understood constraint often does.
A project becomes harder when a limitation appears after months of work. So we try to bring the uncomfortable questions forward:
The sooner those answers become part of the work, the more useful the work becomes.
There is a natural temptation to present work only once it looks finished. We try to resist it.
The more polished something becomes, the more difficult it is to question its foundations. People start commenting on details instead of asking whether the idea itself is right. We prefer important conversations to happen earlier, while there is still room to change direction.
Sometimes what we show is an answer. Sometimes it is a hypothesis. Sometimes it is simply a way of making a question visible. The important thing is that everyone understands what we are trying to learn.
Feedback becomes useful when the question is clear.
We explain the reasoning behind the work, not only what appears on the screen. And if new information gives us a better answer, we change direction.
The goal is not to defend the work. The goal is to improve it.
We care about craft, but craft does not mean spending the same amount of energy on every detail.
Some details fundamentally affect how something feels or works. A sentence can make an interface understandable. A loading state can make a product feel faster. A transition can explain where something came from. The structure of a component can determine whether a website remains maintainable two years later.
Other details simply do not matter as much. Part of the job is knowing the difference.
We often ask ourselves:
Will someone notice this because we got it right, or only because we got it wrong?
Both can be good reasons to care.
The objective is not perfection. It is intention.
Most of the things we make are not finished when they launch. Websites change, brands evolve, products acquire new features, teams change, content grows and technology moves on.
We cannot predict every future requirement, and we do not try to. Instead, we try to create clear foundations.
That might mean:
We want the people who inherit our work to understand it and, ideally, to feel confident changing it.
A system that only its original creators can maintain is not really a system.
A project leaves much more behind than its final output. There are design files, codebases, CMS structures, documentation, decisions, workflows and knowledge.
Those things are part of the work too.
If a decision will matter later, we try to explain it. If something can be simpler, we simplify it. If we notice a problem that falls slightly outside the formal scope but could affect the result, we raise it. If something went wrong, we want to understand why.
Good work should reduce confusion, not move it somewhere else.
This is one of the simplest ways we think about responsibility. After working with us, the next person should have a clearer starting point than we did.
There is always more that could be done: another feature, another iteration, another interaction to refine, another possibility to explore.
At some point, continuing to work creates less value than putting the thing in front of people.
That is when we ship.
Not because the work has become perfect, but because it has become coherent enough to meet reality.
Once that happens, the project starts producing information we could never completely create ourselves. People use it, or do not. They understand things differently than we expected. They find shortcuts, encounter friction, use features we thought were secondary and ignore things we considered important.
That evidence matters.
Analytics, feedback and observation do not replace judgement, but they give us something better to judge.
Shipping is not the end of the thinking process. Often, it is the first time the thinking gets tested properly.
Different problems require different ways of working. We do not believe every engagement needs the same workshop, the same phases, the same deliverables or the same number of sticky notes.
Sometimes we need to research deeply before making anything. Sometimes the fastest way to understand the problem is to build something immediately. Sometimes brand comes first; sometimes technology does. Sometimes we spend weeks on strategy, and sometimes the strategy becomes obvious in a conversation.
The process should serve the problem. The problem should not be forced to fit the process.
There are, however, a few things we keep coming back to:
Everything else is negotiable.
When a project becomes complicated, it is easy to generate more process: more documents, more meetings, more features, more layers.
We prefer to go back to the questions.
What are we actually trying to change?
What do we know, and what are we assuming?
What is the smallest thing we could make to learn something useful?
What matters here, and what only looks important?
Are we making this clearer or more complicated?
Will someone understand why we made this decision six months from now?
Those questions rarely give us the complete answer, but they usually tell us what to do next.
The Typable process is not really a sequence of phases. It is a way of moving from ambiguity to understanding, from understanding to decisions, and from decisions to something real.
We ask questions until the problem becomes clear enough to work with. We make things early enough to learn from them. We keep disciplines close enough to influence one another. We use technology when it earns its place. We care about the details that change the experience and try not to overcomplicate the ones that do not.
And we leave enough clarity behind for someone else to continue.
That is what Typable means to us.
Not having every answer at the beginning, but making the problem clear enough to find better ones.