The Canvas Kept Expanding

In 2019, I sent an email to members of my family with two Sketch files attached.

They were not app designs. They were family trees.

The files contained names, marriages, children and generations rather than buttons, dashboards or mobile screens. I had used interface-design software to organise memory.

I still like this small detail because it captures how I relate to tools. Their intended purpose is usually narrower than what becomes possible when different worlds are connected.

A website can become a film project. A map can become a way for a community to see itself. A family tree can become an interface. A sustainability prototype can connect shopping, personal finance and environmental responsibility.

The tool gives an idea a temporary shape. The interesting part is often the relationship it reveals.

My path through digital design has followed the history of the tools quite closely. I started building websites in Estonia in 2002. Later came Sketch, InVision, Flinto, Principle, Framer and Figma. Then interaction-design research, accessibility, design systems, production code and AI.

Each generation promised to shorten the distance between an idea and a working product.

The distance became shorter.

The responsibility did not.

My earliest websites were made before I knew what to call the work.

There was no clear professional boundary between visual design, content and implementation. You edited an image, changed some HTML, uploaded the files, refreshed the browser and discovered what had broken.

The browser was an honest critic.

A visual idea still had to survive slow connections, missing fonts, different devices and actual use. A beautiful page that took too long to load was still a bad experience. A layout that worked only on my own screen was not finished.

Design could not remain an abstract presentation of what a website might become. Eventually it had to become the website.

This early experience still shapes how I work. Implementation is not the mechanical stage after design. It is where many of the real design questions finally become visible.

What happens while the data is loading?

Can someone use the page without a mouse?

What does the interface do when the connection fails?

Does the layout survive when the content becomes longer, stranger or incomplete?

Who maintains the system after the original team has moved on?

A prototype can hide these realities. A working product eventually reveals them.

Around 2014, Sketch began changing how many digital designers worked.

It felt fast, focused and much closer to the emerging language of interface design than the large Adobe applications we had inherited from graphic design. Screens became easier to duplicate, rearrange and revise.

One of the earliest traces I can still find from that period is an email connected to a project in São Tomé and Príncipe.

A designer had sent a mockup. I asked for the editable PSD or Sketch file because I wanted to change the text myself.

That small request contains another habit that has stayed with me.

I rarely want to remain outside the work, giving feedback from a distance. I want to enter the file, understand its structure, rewrite the sentence, move the image and see how the idea responds.

Sometimes this produces an unreasonable number of browser tabs and an increasingly overgrown website. But it also gives the original intention a better chance of surviving.

An editable file is more than a convenient deliverable. It is an invitation to continue thinking.

Perhaps that is why, five years later, Sketch also became the place where I arranged my own family history. Once information becomes spatial, relationships become visible. You can see where something belongs, what is missing and how one change affects the whole structure.

That is already a form of interaction design, even when there is no button to press.

Static interface design soon created another problem.

A collection of screens could show where someone started and where they ended, but it could not properly explain what happened in between.

This is where tools such as Flinto and Principle became exciting.

I followed Flinto from its earlier screen-linking form into Flinto for Mac. I took a course about interface animation using Sketch, Principle and Flinto. At one point, I asked the instructor a question that remained active in the course discussion for months:

Flinto and Principle seem to be used for the same thing. What is the real difference?

On the surface, this was a software question.

Underneath it was a question about time.

How should an interface move from one state to another?

Should the designer think through timelines, transitions, layer relationships or systems of values?

What should remain still so that the moving element makes sense?

When should motion attract attention, and when should it quietly preserve continuity?

My background in audiovisual media made this feel familiar. Film editing is also concerned with the space between states. A cut can preserve direction, create a collision, hide information, reveal a relationship or make two separate moments feel emotionally inseparable.

The images matter, but meaning is often created between them.

Interfaces have their own rhythm.

A panel sliding in from the side tells us it belongs beside the current space. An object expanding into a detail view helps us understand that it is still the same object. A pause can create anticipation. A confirmation can reassure someone that the system noticed their action.

Movement can also destroy clarity.

A badly timed animation can make a fast product feel slow. Decorative motion can make a serious product feel like it is performing for attention.

The smallest scenes often carry the most trust: loading, waiting, confirming, failing and recovering.

They tell the person whether the system noticed them, whether the action worked and whether they remain in control.

For a while, digital product design required a small procession of specialised applications.

The screens lived in Sketch.

Comments and clickable flows lived in InVision.

Motion lived in Flinto or Principle.

Measurements and assets lived in Zeplin.

Project decisions lived somewhere else.

Developers then reconstructed the intended product from these scattered representations.

It was a strange workflow when viewed from a distance. The same idea travelled through several applications, several people and several levels of fidelity before reaching the user.

Every handoff created the possibility of translation. Every translation created the possibility of loss.

A transition disappeared because it was difficult to implement.

The content was replaced with placeholder language.

An accessible interaction did not survive the visual redesign.

A component looked correct in isolation but failed when connected to real data.

The final interface could remain visually faithful while behaving like a different product.

InVision became the meeting place for much of this fragmented world. It gave teams a way to click through screens, leave comments and create the feeling of a product before the product existed.

That feeling was valuable. It also showed how easily a convincing prototype could create premature certainty.

A set of linked screens could look finished while avoiding the difficult questions of data, accessibility, performance, maintenance and responsibility.

The prototype showed the happy path.

Reality contained everything else.

Figma made sense because it reduced much of this fragmentation.

The file became collaborative. Components could become shared systems. Designers, writers, developers and stakeholders could gather around the same object instead of exchanging static exports.

This was a real improvement.

The shared canvas reduced coordination costs and made design systems more practical. It became easier to see how an interface was constructed, how components related to each other and where inconsistency had entered.

But consolidation also changed the culture of interaction design.

When a general tool becomes good enough at many activities, deeper specialist practices can start to look unnecessary. A default transition can replace a considered transition. A component library can produce consistency without explaining whether the underlying journey makes sense. A polished prototype can create the emotional certainty of a finished product before the important questions have been resolved.

A shared file solves coordination.

It does not create shared understanding on its own.

A perfectly organised Figma library cannot decide whether the product solves a meaningful problem.

A polished prototype cannot tell us whether people trust it.

A component cannot determine whether a workflow makes sense in Tallinn, Taipei or São Tomé.

Consistency cannot replace judgment.

Framer pointed toward another direction.

It began as a more technical tool for interaction design and gradually moved closer to React, production websites and the language of real software.

This resonated with me because it reduced the distance between imagined behaviour and actual behaviour.

In the older workflow, designers often constructed an illusion of the product, then handed it to someone else to rebuild. The more detailed the illusion became, the easier it was to forget that the real product still did not exist.

Framer suggested that the prototype and the product could move closer together.

The transition mattered because it reflected a larger change in my own work. I was no longer satisfied with designing the surface and hoping that the intention survived implementation.

I wanted to remain close enough to protect the important details.

Real products have loading states, incomplete data, broken connections, accessibility requirements, privacy implications, content problems and maintenance costs.

A design tool can postpone these realities.

Code cannot.

My formal studies in interaction design expanded the canvas again.

The interface was no longer only the visible screen. It became one point inside a larger system of people, institutions, incentives, rules, language, infrastructure and power.

Research, participatory design and service design pushed the questions outward.

Who defined the problem?

Whose knowledge entered the system?

Who could participate?

Who was excluded by the language, device, location or cost?

What happened before someone reached the interface?

What happened after they left it?

Living in Taiwan made these questions less theoretical.

A technically correct translation may still feel socially wrong.

A payment flow that feels obvious in Estonia may require completely different signals in Taiwan.

Formality, identity, privacy, QR codes, customer service, social proof and even the rhythm of written language influence whether a product feels credible.

Culture lives inside ordinary interactions.

It appears in the order of a form, the amount of explanation expected, the way trust is signalled and the moment when a system asks someone to commit.

Localization changes more than words. It changes the conditions under which someone feels safe enough to continue.

The same expansion happened in my sustainability research.

Green Filter began with the broad ambition of helping young adults connect consumption, saving, investing and environmental responsibility.

The research then brought the problem back to ordinary moments: comparing products, looking at price, questioning a claim and deciding whether a better alternative was realistic.

People did not need another layer of abstract moral instruction. They needed relevant evidence before the decision, in language they could understand, without being slowed down or shamed.

The design object was no longer the screen.

It was the person’s ability to act on what they already cared about.

This changed how I understood interaction design.

A good interface does more than present information. It affects whether someone feels informed enough, safe enough and capable enough to act.

The question becomes less about what the product can display and more about what the person becomes able to do.

Before interaction design, I spent years thinking about film, documentary, transmedia and storyworlds.

For a long time, these appeared separate from software. One belonged to culture and emotion. The other belonged to systems and utility.

I no longer see that separation.

Stories are one of the ways people enter systems.

They tell us what kind of world we are in, what matters inside it, whose perspective we are following and which actions are possible.

A product also creates a small world with characters, rules, expectations, consequences and forms of participation.

The user is asked to trust someone.

The system reveals some information and hides other information.

Certain actions are easy, while others are made difficult.

There are moments of tension, failure, recovery and resolution.

Every interface communicates how the organisation sees the person using it.

Is the person treated as capable?

Can they correct the system?

Do they understand why a recommendation appeared?

Can they recover from a mistake without shame?

Can they leave?

Storytelling is therefore not copy added after the product has been designed. It shapes structure, sequence, attention and meaning.

A screen shows someone what is present.

A story helps them understand why it matters and what they can do next.

AI has compressed the distance between an idea and a working product more dramatically than any previous design tool.

A person can describe a product and receive screens, copy, images and working code. A small team can explore in days what once required weeks of specialised labour. A founder can test an idea before feeling fully qualified to build it.

There is something magical about this.

There is also something dangerous.

The cost of producing plausible material has fallen. The cost of deciding what deserves to exist has not.

AI can generate ten directions before lunch. It cannot carry responsibility for choosing the direction that respects the user, the culture, the evidence and the long-term consequences.

It can produce an interface that looks complete while leaving permissions, failure states and governance unresolved.

It can accelerate a process while quietly accelerating its mistakes.

The older disciplines therefore become more important.

Interaction design asks how the system behaves through time.

Accessibility asks who can participate.

Research asks whether the problem is real.

Storytelling asks what the experience means.

Engineering asks whether the promise survives reality.

Governance asks who remains responsible.

The prompt is only the first scene.

The product is the larger system that defines permissions, reveals uncertainty, allows correction and turns generated material into dependable work.

HAAM grew from this movement between tools, disciplines and places.

The practice stays close to the work because I want the person discussing the problem to remain connected to the person researching, designing and building the solution.

Research, content, interaction, accessibility, components, analytics and production code should not become separate worlds too early. Each describes a different part of the same product.

This does not mean one person should pretend to possess every possible expertise. It means responsibility should remain visible.

Specialists can enter the work where needed without turning the project into an anonymous chain of handoffs.

The aim is continuity.

The original human intention should survive the journey from conversation to structure, from structure to interface, from interface to code, and from code to the reality of someone trying to use it.

The tool matters when it helps preserve that continuity.

It matters less when it becomes the identity of the designer.

I began by building web pages.

Then I learned to design screens.

Then transitions.

Then journeys, services and systems.

Film taught me to think about rhythm, attention and emotional continuity.

São Tomé taught me that storytelling also involves permission, representation and local ownership.

Taiwan taught me to see how culture lives inside apparently ordinary interactions.

Sustainability research taught me that values become meaningful only when people can act on them.

Code keeps teaching me that every promise eventually meets reality.

The canvas kept expanding.

Today it includes interfaces, stories, organisations, cultures, models, data, infrastructure and the people who inherit the consequences.

No single design tool contains all of that.

Perhaps it should not.

A tool should help us see, test, communicate and build. It should make an important relationship visible or allow an uncertain idea to meet the world sooner.

Then judgment has to enter.

What matters?

Who is this for?

What should be removed?

What must remain under human control?

What happens when the system is wrong?

Who will stand behind the result?

I still enjoy opening a blank canvas. I still enjoy moving elements until the structure begins to make sense. I still care, perhaps too much, about what happens in the tiny scene between one screen and the next.

But the work is larger now.

The goal is to build the clearest thing that still feels alive, and to stay close enough to make sure the original intention survives contact with reality.