Improve Microsoft Teams

First, I’d outline my understanding of Teams and narrow down the experience we want to improve. Then I’d identify a user group, understand their difficulties during meetings, and compare potential solutions.

1. Understand the product and clarify the goal

Microsoft Teams supports workplace communication and collaboration through meetings, chat, file sharing, and integrations with other tools.

Before suggesting improvements, I’d ask:

• Are we focusing on meetings, messaging, scheduling, file sharing, or integrations?

• Is the objective engagement, productivity, or retention?

• Are we targeting a particular type of user or organisation?

• Are there timeline, budget, geography, or device constraints?

For this case, I’ll focus on improving engagement during enterprise meetings over 12 months, with no fixed budget constraint.

I’d interpret engagement as people being able to contribute and have their questions acknowledged. I’d track call duration, but I wouldn’t aim to increase it. A longer meeting could mean a useful discussion or difficulty reaching a decision.

2. Identify the users to focus on

I’d segment employees by the way they collaborate:

These groups overlap, but they help identify different needs. Occupation and work activities are more useful here than age alone. I’d also consider experience with Teams, device setup, and accessibility needs.

I’d choose a product manager who regularly presents documents or designs and meets internal or external stakeholders at least four times a week. The frequency is a working persona assumption.

This user repeatedly switches between presenting and facilitating a discussion, which makes them a good starting point for improving the in-call experience.

3. Understand the meeting journey

Imagine a product manager reviewing a feature with a designer, developers, and a QA engineer. They open a design tool, share the wireframes, switch to a PRD, collect questions, and agree on next steps.

I see four possible difficulties:

• Moving between the meeting and the design tool interrupts the discussion.

• Switching between a PRD, browser tabs, and other materials makes presenting harder.

• While sharing, the presenter may miss chat messages or raised hands.

• Questions and feedback can be difficult to capture and organise for follow-up.

I’d validate these through observed usability sessions and presenter interviews, especially with people using a single screen. I’d also check existing Teams controls across desktop, web, and different sharing modes. The problem may be discoverability or visibility in a particular setup rather than a missing feature.

4. Prioritise the problem

I’d separate the needs into basic requirements, satisfiers, and delighters.

Being able to notice someone who wants to speak is a basic requirement for an interactive meeting. Easier access to chat and feedback capture can improve that experience further. More advanced automatic meeting layouts could be a delighter once the basic interaction works reliably.

I’d prioritise presenters missing raised hands while sharing their screen.

For example, a QA engineer might need to clarify an edge case before the group moves on. If the presenter misses the signal, the discussion can continue with an unresolved assumption.

5. Explore solutions

I’d consider three options:

• Presenter-only raised-hand panel: A small floating panel showing who has raised their hand, ordered by when they raised it.

• Presenter-only comment viewer: An optional chat panel that stays accessible while presenting.

• Enhanced meeting view: A layout that makes active speakers and people with raised hands more prominent.

The raised-hand panel is my preferred starting point because it addresses a specific signal without requiring the presenter to monitor a full conversation.

I’d use RICE: Reach × Impact × Confidence ÷ Effort to compare the options. Here is an illustrative assessment for a pilot:

These are hypothetical estimates. I’d validate reach through usage data, impact through testing, and effort with engineering.

The panel ranks first under these assumptions. It keeps participation requests visible while adding relatively little information to the presenter’s screen.

6. Define the experience and trade-offs

I’d make the panel movable, collapsible, and accessible through keyboard controls and screen readers. It would show a few names, their waiting order, and the total number of people waiting.

For larger meetings, I’d avoid displaying ten or twenty names at once. A compact queue could show the next few people and expand when needed.

The main trade-off is visibility versus distraction. A panel that covers the content or constantly animates could make presenting harder. I’d use a subtle visual change for new requests and let the presenter control its placement.

“Presenter-only” also needs technical validation. I’d test whether the panel is excluded from the shared output in each supported sharing mode. If exclusion cannot be guaranteed, the interface should make that clear.

I’d also distinguish acknowledging a request from answering a question. Clicking “Seen” can reassure a participant, but it doesn’t prove their concern was resolved.

Within the 12-month window, I’d start with research and a prototype, pilot it in frequent screen-sharing meetings, and expand after validating usefulness and reliability.

7. Measure success

My primary metric would be the percentage of raised-hand requests acknowledged during screen sharing, supported by median and 90th-percentile time to acknowledgement.

I’d also measure:

• Time participants spend waiting with a hand raised.

• Presenter switches back to meeting controls to check participation.

• Percentage of meetings ending with unacknowledged requests.

• Presenter and participant feedback on whether questions were heard and addressed.

A hand being lowered is only a signal. Someone might lower it because they gave up, so I wouldn’t count that automatically as success.

I’d track average call duration as context, alongside meeting size and purpose. I’d also monitor panel dismissals, distraction complaints, accidental exposure in screen sharing, and meeting performance.

8. Make the recommendation

I’d recommend a compact raised-hand panel for presenters, beginning with frequent screen sharers using a single display.

The goal is to help presenters notice participation requests without repeatedly leaving their content. If it reduces missed requests and improves the discussion, I’d then explore adding optional chat visibility and better feedback capture.