L o a d i n g

User pain points

While conducting user research to best understand GIF use cases, the product team discovered that trimming is an essential part of GIF export flows. The product team launched a study via the UserTesting platform. Out of 50 participants, 32% of users record GIF videos from scratch and perform light GIF export adjustments, such as trimming and tweaking parameters impacting video quality. By bringing trimming and video import into playback mode, Snipping Tool can better optimize user flows for GIF creation. Supporting an in-app trimming feature would improve existing screen recorder flows and give users more control over their video content.

The framing and research.

Additionally, adding trimming to Screen Recorder's playback mode also supports generic trimming use cases. In early Screen Recorder feedback, users requested trimming to cut out extra cursor movement at the end of a recording where they are clicking on the "Stop recording" button. There have also been UlFs requesting the feature: "love the screen record function. Needs keyboard shortcut, ability to trim length, ability to start immediately."

Design explorations.

Design explorations were mostly from the end-to-end flow point of view; competitive analysis were observed for this explorations. Variations text inputs and other controls were explored to fulfill the technical requirements. Intenal design team reviews were used solicit high level end-to-end flow feedback and as well as specific controls. An Design LT review were needed to gather LT feedback on the UX flow and the company visibility.

The competitive analysis.

Competitive analysis gave us an overview of some of the most common controls and behavior while interaction with the components itself.

The control explorations.

The micro-interaction when the users interact with the trimming control was the key in this step. We conducted A/B testing of the PoC with the internal folks and subsequently the real clients. Feedbacks were gathered to makes an informed decision. And after the final direction was chosen, another user testing was conducted for validation.

The delivery

After feedbacks from the rounds of internal and LT reviews were analyzed and iterated, it's time for me to start s design spec documentation and attaching hi-fidelity mockups and prototypes to the full-spec document. There were external leads (outside the key stakeholder) needed to sign off on the design documentation. Accessibility, Content Design, and Icon Design cross-functioned with us in making sure the specs fulfill all their respective requirements.

The redlines.

The redlines were needed custom components and optional for established components from the UI library. As you can see in the next picture, it's used to make sure the coded components match the design mockups as close as possible. There is a variation of this where we attach a guideline on how to translate design redlines to the WinUI XAML APIs for the dev to understand it better. In other words, whatever makes sense for the dev team.

The accessibility documentations.

The accessibility documentation were needed to signed off by the accessibility before we handed off the Engg. It includes the detailed behaviors of the controls when screenreader and keyboarding assistive devices are interacting with the UI. Once the feature are shipped, the accessibility would occasionally test the feature and file accessbility bugs as needed; and they also give an accessibility score to bring it into our attention.

The full-spec document.

The full-spec document were written and iterated by the PM and his/her peers; I attached the high fidelity mockups in the feature details section. The document were included in the 'package' that the design and product team hand-off to engineering team.

The implementation

The implementation ran smoothly for the this feature.

The customer insights

This feature is being worked on. We'll tell you when it's shipped. Keep an eye out!