M-Files × Microsoft Teams

Bringing governed document management into the tools people already use

My role: Senior Product Designer · End-to-end UX ownership
Team: Product · Architecture · Engineering · QA
Scope: Teams Files · M-Files workspace · AI metadata · Filing · Governance

I designed a governed document-filing experience from scratch inside Microsoft Teams, balancing Microsoft platform constraints, M-Files governance requirements, customer expectations, and AI-assisted metadata—while keeping users in control of consequential decisions.

01 — The Problem

Teams made collaboration easy. Governance was the missing piece.

Enterprise customers were already using Microsoft Teams to collaborate on documents.

But when those documents needed to be managed within M-Files, users were forced to move between systems.

This created a fundamental question:

How do we bring M-Files governance into Teams without making Teams feel like another document-management application?

The experience also had to operate within Microsoft's ecosystem and technical constraints.

What is M-Files?

M-Files is an intelligent information management platform that helps organizations manage business information based on what it is, rather than where it is stored.

Instead of relying primarily on folders, information in M-Files is organized using metadata such as document type, customer, project, or status. This makes information easier to find, connect, govern, and manage throughout its lifecycle.

M-Files brings together documents and business information from different sources while applying organizational rules around access, versioning, and governance.

02 — There was no existing UX to inherit.

I owned the UX decisions end-to-end, with no other designer involved.

My working process was:

PRD → User flow → Wireframe → Architecture review → Iteration → Detailed design → Engineering

AI was also used during the early wireframing stage to accelerate exploration.

But technical feasibility was considered during design rather than after handoff.

Because the product lived inside Microsoft Teams, seemingly simple interactions could depend on:

• Microsoft platform capabilities

• Teams behavior and permissions

• M-Files governance

• Document/version behavior

• Architectural limitations

• Enterprise requirements

• Legal/compliance terminology

I therefore worked closely with the architect throughout the design process.

Architecture wasn't a handoff gate at the end of design. It was part of the design process.

03 — The Biggest UX Problem

What happens when one document becomes two?

One of the biggest issues appeared when moving a document from Teams Files → M-Files.

The document could exist in both systems.

That created a potentially dangerous scenario:

User A edits the Teams version.
User B edits the M-Files version.

Now there are two potentially different versions of the same document.

Exploring synchronization

My first direction was to consider automatic synchronization between Teams and M-Files.

But synchronization could itself introduce conflicts.

I then explored manual synchronization, giving users more control over when versions were reconciled.

After discussing the architecture, we identified a fundamental limitation:

We didn't have sufficient control over synchronization between the two environments to make this approach reliable.

That changed the design direction.

04 — Making M-Files the Governed Version

Instead of trying to synchronize two active copies, the experience established a clear governed version in M-Files.

When the user chooses to remove the Teams copy:

Teams document → M-Files → Teams copy removed from active experience

The document isn't permanently destroyed. It remains recoverable through the SharePoint recycle bin.

This gave us a clearer governance model:

Once the document is filed and the Teams copy is removed, M-Files becomes the governed working version.

But removing a user's document from Teams is consequential.

The UI therefore needed to explain:

• What is happening

• Why it is happening

• Where the removed document goes

• How it can be restored

05 — Designing the Confirmation

Making the consequence explicit

When the user saves a document to M-Files and chooses to remove the Teams copy, we show a first-time confirmation.

The dialog explains that:

• The selected files will be saved to M-Files

• The Teams copies will be removed

• The files can later be restored

• Restoration happens through the channel's SharePoint recycle bin

The user can also choose:

Don't show this message again.

A deliberate trade-off

There was an interesting edge case with Save All.

The user could encounter:

1. Metadata confirmation

2. Save/delete confirmation

That meant two dialogs could appear during the first-time experience.

We considered the friction, but decided to accept the trade-off because the governance confirmation is primarily a one-time explanation.

Rather than redesigning the entire flow to eliminate an edge case that occurs only during first use, we accepted the additional confirmation.

06 — Don't Force the Governance Decision

Make the risk visible. Give users control.

The user can choose whether the Teams copy should be removed.

If they choose not to remove it:

Both versions remain.

The product doesn't pretend there is no risk.

Instead, the user is informed about the consequence and can make the decision appropriate for their workflow.

We also introduced a global setting so users could control whether Teams copies should be removed when files are saved to M-Files.

Make the risk visible. Give users control. Don't hide the complexity.

07 — The Second Problem

Filing is metadata-heavy

Once we solved the document-governance problem, another challenge emerged.

Saving a document isn't enough.

For M-Files to properly manage it, users need to provide metadata such as:

• Class

• Reference

• Customer

• Project

• Keywords

• Additional properties

Doing this manually for every document creates another source of friction.

That's where Aino comes in.

08 — AI Should Accelerate Filing, Not Make the Decision

The design question

How can AI reduce the effort of metadata entry without taking control away from the person responsible for the document?

Aino analyzes the document and generates metadata suggestions.

For example:

Class
Documentation

Customer
Brewster boats

Project
Chico plants

Keywords
ID2567

But the AI never silently overwrites the user's decision.

The user can:

• Accept the suggestion

• Replace the current value

• Reject it

• Edit the metadata manually

• Provide a value when AI can't determine one

The AI accelerates the work. The user owns the final decision.

09 — Showing Where the Metadata Came From

The visual language creates a clear distinction between user-entered values and AI suggestions.

Grey

User-entered value

Filled purple

Primary AI suggestion

Purple outline

Secondary AI suggestion

Replace icon

Communicates that selecting the action will replace the current value.

The interaction is designed to communicate:

This is what you entered.
This is what AI recommends.
This is an alternative.
This is what will happen if you choose it.

The user doesn't need to interpret an abstract AI indicator.

10 — Explain the Reasoning

Don't make AI a black box

Aino doesn't just provide a recommendation.

The user can inspect why the recommendation was made.

For example, the reasoning can explain that a particular organization is repeatedly mentioned in the document and is therefore likely to be the customer/project.

Why this matters

Metadata can affect classification and governance.

So a black-box recommendation isn't enough.

The design principle became:

If AI influences a governance decision, users should be able to understand where that recommendation came from.

The user can then:

• Accept the suggestion

• Replace the current value

• Reject it

• Edit the metadata manually

• Provide a value when AI can't determine one

11 — Designing for Uncertainty

AI isn't always able to determine a value.

Instead of pretending it knows everything, the experience allows the user to complete the metadata manually.

The model is:

AI suggestion → User evaluation → User decision

rather than:

AI decision → Automatic filing

That distinction is particularly important in an enterprise governance product.

12 — Designing Within Microsoft's Ecosystem

The UI was only the visible part of the problem.

Every feature had to be designed against the reality of the Microsoft environment.

My process was:

01 — Understand the requirement

I received the PRD and understood the intended user/business outcome.

02 — Explore the experience

I used AI-assisted exploration and created the initial user flow and wireframes.

03 — Validate feasibility

I worked with the architect to understand what Microsoft and our architecture would allow.

04 — Iterate

Where technical constraints affected the experience, I adjusted the flow.

05 — Detail the interaction

Once the direction was technically viable, I moved into detailed UX/UI.

06 — Engineering collaboration

Engineering then became involved for implementation, with design and architecture already aligned.

Architecture wasn't a handoff gate at the end of design. It was part of the design process.

13 — Customer Validation

Designed with enterprise customers, not just for them

We interviewed users/stakeholders from Customers

One important example directly affected the design.

Default delete behavior

My initial recommendation was to have the delete option off by default.

However, feedback from multiple customer reviews indicated that customers expected the option to be enabled by default.

So the design changed based on customer evidence.

Start with a design hypothesis → validate with customers → change the design when evidence contradicts the hypothesis.

We also received positive feedback on the AI experience, with customers viewing it as a significant improvement and aligning it with the Fluent design system.

14 — Working Within Fluent and Evolving Requirements

The product follows the relevant terminology and requirements provided by applicable laws/regulations, with terminology updated as those requirements evolve.

The design therefore had to work within:

Microsoft patterns + Fluent design + M-Files governance + customer requirements + evolving regulatory requirements + technical constraints

This meant the design wasn't static. It evolved alongside the requirements surrounding the product.

15 — Key Design Decisions

16 — My Role

Senior Product Designer — End-to-end UX ownership

I owned the UX decisions across the Teams experience, including:

• Teams Files experience

• M-Files workspace

• Filing flows

• Save / Save All

• Metadata experience

• AI-generated metadata

• AI reasoning and suggestion states

• Governance confirmation

• Teams/M-Files document lifecycle

• Error and edge cases

• User flows and wireframes

• Detailed UI

• Design collaboration with architecture, PM and QA

• Customer feedback and iteration

I was the sole designer on the initiative.