Building better testable prototypes

At Obvious, we spend considerable time doing user research in all forms and sizes. Here, I want to talk about how I optimized my workflow for usability tests to build realistic prototypes faster. I don’t want to get into the importance of user research and why is it essential to validate our assumptions. There are many great articles and books about this. I want to share my learnings while building prototypes under time pressure. I assume in this post that the readers have a basic understanding of Sketch and Invision.

Photo by Tara Shypka

Why build a prototype?

We run a lot of usability tests in our work, whether it is for a Design Sprint or our own research and conceptualization cycle that we call Relay. These user interviews are often an hour long and we test our product design with real users. In most cases, the product hasn’t been developed as yet, and we have to show them a simulated prototype, a very rough version that can be built and stitched together in a day or two, maximum. If this prototype mimics a real product closely, the findings from the users are richer.

Building a realistic prototype in one or two days is crazy, there is no better word to describe it. I want to share my key learning on how I try to make it happen.

Plan well

The ability to plan well is an underrated skill. If we do a good job, everything is smooth sailing. Only when trouble arises do we look over what went wrong in planning.

In order to plan ahead, we need to know all the constraints that we are working with.

• How well is the prototype I am going to build fleshed out?
• How much time do I need to spend on design details?
• How many existing resources and guidelines can I use so that I don’t waste time creating assets?
• How familiar am I with Sketch?

Pro tip: For our prototypes, I try to use as many existing resources as possible: Screenshots, Libraries, anything that saves time for asset creation in Sketch.

In my experience, it is always better to take smaller portions of work, something that I know can be finished on time. There will always be some unforeseen situation blocking you here and there, so it’s a great idea to have a sizeable buffer time. Since we want the best and clearest results, it is always better to present a smaller, better-crafted prototype to your users rather than a huge apparatus that tends to fall apart every other click. All small details matter, like naming consistencies, real data, spellings and so on.

This is what I consider a reasonable amount of clarity and planning for a prototype for one of our projects. This is, of course, after 3 days of a Design Sprint so we already had a lot of clarity and context (which is hard to see here) on the goals and ideas to achieve them at this point.

Do whatever is possible in Sketch

Building all the screens is probably the chunk of the work. Unfortunately, not much speeds up this process other than using screenshots and existing libraries. Once I have finished building all screens and assets, I start stitching the prototype together in Sketch. This helps me save a lot of time. Linking Screens online in the InVision page can be tedious, so doing as much as possible offline speeds things up. Here is a great Tutorial on what all can be done and how.

With the craft plugin installed, you can link any layer to an artboard. Select a layer (i.e. your CTA), press ‘c’ and click on any artboard to establish a connection.

Pro tip: If you have a long scroll, you can create a link to any place on the same page and InVision transitions the screen quite nicely.

This way, I connect all screens that can be connected offline until my entire prototype is stitched together. This process can slow your computer down a tiny bit but is much faster than doing it online. In this approach, I don’t have to create hotspots and can use the actual layers in my sketch file. If I decide to move a button later, the link moves with it.

100+ Artboards and multiples of that in connections linked together in Sketch from one of the prototypes that I used in a user study

Sync with Craft

There isn’t much left of the glory that the Craft plugin used to bring into Sketch, but syncing your artboards still works and that is all that I am using it for at the moment. It’s still quite useful as long as you don’t change the names of your artboards: you can change them and update them online, hassle-free.

A small confession: while building a prototype under time pressure, I don’t care about naming artboards at all, so you might find 50 artboards in InVision called ‘something copy 56’. But as I said, as long as the names are consistent, it doesn’t matter. And since you don’t have to link, and hence, find artboards online, it doesn’t matter. But this is only because it is a one-time effort and we throw the prototypes out after we’re done.

Pro tip:If I have to add some special event online that I cannot create in Sketch, I actually leave a bright note on the artboard that I can find it easily in the InVision preview.

Leaving notes on an artboard that I know what to do online.

Once I made the change online, I can remove the note in Sketch and sync the artboard again. It’s a truly quick and dirty style of building, but my prototypes need to survive only for a day, and so in that case I don’t care about scalability or maintainability.

Be careful with overlays

Having a popover or a menu expanding somewhere is often a part of an interactive prototype. The InVision overlay functionality promises more control over how something appears on top of a screen, like fading and transparent backgrounds. Having said which, I don’t think they work very well in InVision. They tend to break the prototype and are often the opposite of a smooth transition. I’d rather use a new screen and de-prioritise a fading transition to get a stable prototype. I would advise caution when using overlays.

InVision auto-events

Sometimes, I need to bring up an onboarding screen — Coach Marks or some sort of helper — if the user is unable to proceed on her own. For example, a pop-up should ideally appear after the user is unable to proceed for more than 15 seconds. Auto-events are great for creating that illusion. The interface for InVision is easy and straightforward. It’s pretty easy to set duration and a destination in Invision since you browse through your screens.

At the cost of being laughed at, I just want to mention what ms (milliseconds) are to avoid the confusion I had for some time. 1 second has 1000ms. If I want a screen to come up after 9 seconds, I have to set the duration to 9000ms.

a very crude loader created using simple auto events

You can also use auto-events to create very crude animations. I once used it to create a loader that had only three states (30, 65, and 100 % full). The three states are three screens with auto-events happening on them after ca. 300ms (for animation, see the following paragraph). It gave the illusion of something happening at the background of the prototype and made it more real for the user. Overall, auto-events are great and I recommend them highly.

The power of Gifs

Enter: Gimock Plugin.

Whether it is a loader or a small animation, moving objects make the prototype better and these little details go a long way. This plugin costs 14 USD and is definitely worth the money. Making loaders is incredibly easy and even complex animations can be made in minutes. You can use Gifmock’s built-in features or turn artboards into frames and export them as a GIF. InVision supports GIFs without any problem. The only downside is that you have to manually upload the GIFs outside your Sketch file. The same overrides work if you update your source file but keep the same name.

This is the main reason I continue to use InVision and not the prototyping tools in Sketch and Figma; as animations like these can make quite a difference!

This animation in the form of a GIF was made in just 10 minutes, but I believe it really made a difference to the user who had to learn and understand a new functionality

Real, real data

Using ‘Lorem Ipsum’ or other random data in a prototype is never a good idea. It makes the prototype appear less real. It appears even less real in prototypes that contain user profiles or other personalised information. We need a prototype to be as real as possible in every aspect. On the evening before an interview, it should be clear which user is attending and the names of users should be accessible for the person organising and scheduling the testing sessions. While there might not be a lot of time, it should be possible to make use of this information. It can make a big difference to find your own name in an app or website and it helps to establish a connection to the product and provide better insights during the testing session. Using real data shifts the session from a hypothetical scenario to a real scenario and that is the expectation that a prototype should fulfil.

In this screen recording, a user is looking for public acknowledgement of the contribution she made to a story. She is positively surprised to find her actual name on that very page and starts explaining why public acknowledgement is important for contributors. This gave me valuable insight into developing the feature which wouldn’t have been the same if I hadn’t used her actual name.

Record it

I don’t like taking notes. Especially when I am the one conducting the interview. So, I use Silverback to capture all that matters: what happens on the screen, the mouse movement, the sound and the user’s expression. This way, I can listen and see what happened at a later point when I want to summarise my findings. Silverback has a free version, too, if you don’t mind the watermark on your export. These recordings then become my validation and proof for the client as well. In any case, it is a good idea to record user testing sessions

(Hint: Always ask for consent to record. I remind myself of this by making this the first point on the notes I prepare for the interview).

Silverback makes it very easy to record different users in a session and export them all at once. It captures a picture of the user as a thumbnail for the video. In my opinion, it is a great piece of software and incredible value for money.

Pro tip: Listen to your recording at a higher speed, you still get all the information. For me, the maximum that works well is 1.6x.

I am quite excited to see other prototyping tools develop and improve the process, and I love to learn how other designers or prototypers deal with these challenges. I hope this article is of use to people with profiles similar to mine.

This post was originally posted on the obvious website