inspect motion hero image
Motion Inspector showing the timeline, React Native code, and list data.

Designing a Motion Inspector

With the advent of InVision Studio, designers and other creatives were given the ability to create complex UI animations with granular control over every property. They can even customize duration, delay, and easing for any property as well. The result was some of the most beautiful and thoughtful animated prototypes our industry had seen—one’s that you could actually click or tap through on any device (not just watch a movie of something created in After Effects).


Working with the Inspect team, we were challenged with creating a tool that allowed developers to collaborate with designers on these animated prototypes; developers needed to inspect each and every motion detail so they could bring it to life in code. This was the beginning of Inspect Motion. Create a Studio prototype, and give it a try =)

Studio was built as an electron app and shipped as a desktop experience, so there wasn’t much of complimentary web experience; just a presentation mode and the ability to leave comments. At the time, I was working as the Design DRI across three squads responsible for Craft & Web Protototyping, the web Studio Document Viewer, and Inspect for both Sketch and Studio. It was nice to be able to touch such a breadth of the product surface area in my first few months.

When we hired two more designers, my sole focus turned to the Inspect developer experience for this project. Along with the other teams I worked with, particularly the Inspect team, we saw a large opportunity to build the beginnings of Studio in the Browser. We collectively decided to start with showcasing a highlight of Studio as a design tool—advanced UI animation capabilities.

A fairly common UI interaction and animation (with some embellishments to showcase the wide range of granular control) that I made in Studio. I ended up making quite a few of these mock apps to familiarize myself with all of the available motion data points.

The second opporunity we idetified was that we had a chance to build a developer tool that hadn’t ever existed before. This meant we had a chance to innovate and to do all of the product strategy, generative research, prototyping and sketching ideas, user story maps, product roadmap, refining the design, customer research, build the tool along the way, and eventually release the large feature. This also meant that it was an important strategic project for the company.


Early explorations trying to figure out the best way to present the motion data to developers.

Product and system thinking

When I joined InVision in 2018, I learned that a number of ideas, projects, and time had already been spent on bringing complex motion capabilities to the product offering. One being “Motion”, which they were attempting to build into the web app prototyping experience; another being a pivot all togeher to build a full-blown desktop design tool with unprecidented motion capabilities and granular control. This was Studio.

The Inspect team was challened with deconstructing what we had now, which was for the creator, and figure out how to best deliver all kinds of motion data to the developer—the reader. What should the product be? Where should it fit within InVision’s new v7 platform? What were the pertinent peieces of data that developers needed, and what was just fluff? Could we build it into the presentation mode’s Inspect feature? Would the user’s flow, interactions, and information architecture make sense in that model?

Workig with my trio—EM and PM—and the engineers on our team, we began to solidify a direction for how this new Inspect Motion app could fit within InVision’s new cloud platform.

It was time to do some research and coding.

Make with what we know

We began by looking at the recent history of design tools, other animation and video editing tools, and even tools from the music industry, like Ableton and Pro Tools. Once we felt like we gathered enough information, talked with a handful of InVision customers, and shared our insights with leadership, I began designing iteration after iteration based on what we knew at that point.

Throughout this making process, we were also beginning to program the infrastructure and UI, knowing that we could make tweaks or pivot at any time.

A working prototype of the Inspect Motion product starting to come together; more goodness to come as we finished the project.

We felt good about the the initial coded beta iteration, and began putting animated prototypes and the programmed feature in front of internal software engineers who use Inspect in their daily work. We also repeated the same sharing process with the designers and leadership who have been working on Studio for the past 2.5–3 years. The work and direction were well recieved, and we felt comfortable moving forward with testing it with real users.

Put it in front of customers

Johanna, our amazing researcher helped me put together a research plan, and I set up Calendly links to send to the customers that we identified using our own internal data tools. We scheduled 6–8 customer interviews—1 hour to set context with Studio, show the new v7 platform and how you navigate to a project, and then ran through our script of scenarios and questions.

This was a particularly neat interview because we had built an identical prototype in both Studio and CodePen, with some “errors” in the CodePen animation—things that didn’t look right to the supposed designer (and were indeed incorrect values). The customer we were interviewing would then use our live Inspect Motion product to interact with the designer’s prototype and find the data they needed—in list form or code snippets. They would then fix the code in CodePen, thus concluding the interview.

We asked a series of follow up questions, and then repeated this with more customers. This was generally how we went about this:

Making it real

Now that we were gaining confidence in the Motion Inspector product we built, we quickly made some decisions between out trio—Engineering Manager, Designer, Product Manager—to make the neccessary alterations until it felt just right given everything we now knew (or at least right enough to launch the beta).

After we knew what to build (and had already started roughly building it), we ran a user story mapping session with the whole sqaud. The purpose of this is to two fold:

Then I worked with the Engineering Manager to roughly translate those digital post-it notes to Jira tickets, created Epics to organize the work, and wrote the User Stories in more detail while identifying the ones where we still needed more design decisions to flag them for me to pick up.