InVision Case Study: Inspect Mode

Case Study: Inspect Mode

Task: Design a mode that helps close the gap between the end of the design process and the beginning of development.

Role: Product Design lead for Inspect Mode

invision inspect mode

Why - Understanding the Goal

Why is this feature important?

This feature helps complete the design process and workflow. Currently in the app there is no way for a designer to easily pass along design specs and assets to developers.

What problem are we trying to solve?

During the design handoff there is often a disconnect. Design documents get updated after the fact, developers don’t have the needed design software so they are stuck looking at static screenshots, discussions that helped shape the design are lost. Because of these problems developers are having to constantly ping designers for CSS values, hex codes, icons, image assets, etc. This is inefficient for both parties.

How does this feature benefit customers?

This feature would save time for the designer as well as bring efficiency to the development process. Having a single source of truth for the designs means the developer always has the latest designs and specs.

Who - Define the Audience

Who will be using this?

The interesting part of this new feature is that it will not only be used by our normal designer user type, but it will potentially be bringing on a new audience - developers.

What are their needs?

Designers: This new feature needs to facilitate the efficient transfer of design details and specifications to the developer. Developers: They need design assets and specs. If they can get this from the new feature instead of working directly with the designer it removes a bottleneck. Another advantage is that this can be done whenever the developer needs.

When & Where?

The designers and developers using this will be at their desks; most likely in an office or their work space. Design for large monitors and high speed internet. Designing for mobile is unneeded.

What & How - Taking a Step Back

Before diving into designing a new mode I decided to take stock of what we already had and really question if a new mode was completely necessary. There is a possibility that we could expand upon what we already had.

Do we really need another mode?

There are currently four modes: Preview, Build, Comment, and History. Could these new features live within Comment mode? Comment mode currently has comments, Dev Notes (a comment sub-type), and sketches/annotations. It feels like there would be a lot of potential overlap of features if we created a new mode. If designers and developers are already inside Comment mode, maybe we can keep all their conversations and interactions there.

Cons on redesigning Comment mode

New developer tools would have to be introduced into this mode so there might be real concerns with screen real-estate and overcrowding. Redesigning a current mode alongside adding new features is adding a significant amount of scope to the project as well.

Benefits on redesigning Comment mode

Sketches and annotations could use a redesign. They are underutilized and viewed inside of an awkward modal view which pulls them out of context with conversations.

Explore & Define Current Modes

Working from the bottom up I’m trying to distill each mode into its functions and goals. Comment mode is essentially about communication, which is what the designer is trying to accomplish with the developer in our new scenario.

In this light, having developer inspect tools in comment mode makes sense. Renaming the mode to something more relevant would need to happen however.

explore modes

Audit current state of sketches and annotations

Here I am auditing the current state of the sketch and annotation tool. How can we improve this feature and better utilize it with the new document inspection tools?

explore modes

How would a redesigned Comment Mode flow?

Now, how do we bring redesigned sketches and annotations into context with conversations?

Let’s see how how sketches and annotations are viewed within context of a specific comment thread. Viewing all sketches and annotations of a screen at once would be incomprehensible, so we can limit the scope of them. We can also list comment threads on the left side of the screen for easier navigation (instead of relying on just the comment dots all across the screen).

Where will the new document inspection tools fit?

Inspection tools could be accessed from a toggle in the top right of the screen. This allows a developer to use them whenever they need and in whatever context. We could have a panel for the inspection tools as well as one for the layers of the design document. This allows for the new tools to be the least interruptive within the mode. They can be there when you need them, and be hidden if not.

Storyboarding

These series of storyboards are early versions of tying comments together with their associated sketches and annotations. They are shown in context with the conversation instead of separate modal window.

The storyboards are also displaying the first passes at how an Inspect and Layers panel could work within the mode.

storyboarding

Redesigning Comment Mode

A Stand Alone Inspect Mode

Why redesigning Comment Mode wasn’t the move.

The team didn’t have enough time or resources to handle the extra work needed to redesign Comment Mode in addition to the new features. The decision was to leave comment mode alone and go forward with creating an entirely new mode.

We did, however, learn a few things from this exploration

We know we liked the Inspect and Layers panel to be their own unique elements. We also liked viewing the list of conversations in their own panel, instead of the current system - which was clicking on dots on the screen. Another decision that was made was that we were only going to display Dev Notes, not every conversation type.

How was this new mode going to be laid out?

Let’s explore a few options…

Thumbnail Wireframing Layout Options

How do we want this new mode to be laid out? We knew a few panels that we wanted to include and a general idea of the tools we wanted to include. It was still early and the mode itself was still being fleshed out.

Here are a few quick wireframes I did to get a feel for how we wanted the new mode to be structured.

wireframing

Inspect Toolset

Inspect tab?

The Inspect tab is where we are going to place the most needed tools a developer will need. Things such as CSS code, colors, layer properties, and asset export options.

Toolbar?

The floating toolbar would be tools that the developer would use to interact with the document. These include zoom, panning, text tool, drawing/annotating, and a select tool.

Select tool would be the default and most used toolbar tool

By default the Select tool would be chosen. Selecting a layer updates the contextual Inspect tab which will then display the selection’s CSS properties, dimensions, coordinates, etc. Selecting a layer gives the user the ability to hover over a different layer and get distance measurements. If a designer wanted to highlight a specific distance or measurement for a developer, they could “pin” that to the artboard. Pinned distances or dimensions would remain on screen as callouts for developers.

Inspection Tools

These series of screens are simple wireframes designed to try and understand the user interactions with the tools and how the tools themselves interact with the design.

inspection tools

Designs

Iteration, Iteration, Iteration

With a strong idea of the elements and tools we needed for the design and how those tools would work, it was time to start more polished designs and prototypes.

Each design was thoroughly prototyped, tested, and discussed with the team. There were also features being designed concurrently in other part of the InVision app that would affect my designs. Keeping shared elements consistent was top priority (layers tab, document zooming, document header, rulers).

inspect iteration
inspect iteration
inspect iteration
inspect iteration

Final Design

It all comes together

The previous screens are just an overall glimpse into the amount of testing, prototyping, and iteration that went into designing the new Inspect Mode. Nearly every day for a couple months I sat down with the team and solicited feedback, worked through interactions, and presented new flows and ideas. As mentioned earlier, there were separate concurrent designs happening elsewhere in the app, so keeping these continually evolving designs in sync was a challenge in itself.

Through the iterations you can see work on where the toolbars were to be kept. We also added a contextual layer popup when you selected a layer, document rulers, and guides.

The addition of the contextual layer popup freed up a lot of real estate in the Inspect panel. It was enough room that we were then able to consolidate the Inspect panel and the Dev Notes panel. Instead of two tabs they now became one scrolling column.

invision inspect mode

Thanks for reading!

If you’d like to read more about my thoughts on design or my approach and process check out my other case studies.

Portfolio Home

Unified Customer Experience Platform

Project: Creating design guidelines and new patterns and components while updating, maintaining, and governing our design system called Hyperspace.

Sprinklr Design System
sprinklr screenshots

Simplifying Vision Care for Contact Lens Wearers

Case Study: Design a process to automate the renewal of memberships.

Sightbox Case Study
sightbox app screenshot