All Posts in Design

May 19, 2014

Moving to Framer 3.0

Framer 3.0 released last week! Hell yeah. New site, new docs, amazing amazing new examples to play with and learn from. My favorite new feature is the state machine which is going to be a huge improvement in organizing animations and stateful interactions. There are a ton of other updates, from under-the-hood changes to the animation engine to wide-ranging syntactical improvements. The changelog breaks it down better than I could. And everything is pretty much backwards compatible with Framer 2.0 projects.

Well, pretty much. I decided to upgrade a project from 2.0 to 3.0 earlier tonight and ran into a few small issues. Hopefully this’ll help save you a few minutes if you ever need to do the same. More hopefully, you won’t ever need to upgrade; unless you’re actively working on a project and dying to use the new 3.0 features, I can’t see any good reason to mix the old and the new.

Framer Generator puts files in a different place

In Framer 2, when you run Framer Generator all of the sliced images were exported into /images, with a corresponding views..js created in the /framer directory.

Screen Shot 2014-05-18 at 11.19.24 PM

Framer 3 places everything to do with your export from Framer Generator in a separate /imported// directory. The “manifest” file that tells Framer how to arrange those slices is now just called layers.json.js in that same directory. If you’re starting a new project, this probably doesn’t matter, but if you have an old project that looks for that “manifest” file specifically you’ll want to update references. Speaking of…

There’s no more PSD object

Which makes sense, since half of Framer’s user base probably works in Sketch anyway. But if you have a Framer 2.0 project you probably have plenty of references to the PSD object to deal with. Luckily, you can just add this to the top of your app.js:

var PSD = Framer.Importer.load("imported/yourprojectname”)

As long as you’ve used the newest version of Framer Generator to re-create your assets in the locations above, this is all you need.

draggable is now a real thing

I learned how to make things draggable from this article from Cemre Gungor. Dragging was undocumented and kind of weird and somehow he figured it out.

Now Framer 3.0 makes it easy to enable dragging on any layer, but the 2.0 workaround also throws errors once you upgrade.

// this doesn't work anymore
someLayer.dragger = new ui.Draggable(someLayer);
// replace it with this
someLayer.draggable.enabled = true;

// and you don't have to do this
someLayer.dragger.on(Events.DragStart, function() ...
// because now these events are standardized 
someLayer.on(Events.DragStart, function() ...

Spring animations are, um, different

There’s an innocuous little line in the changelog: “Animation spring initial velocity behaves a bit different.” I previously wrote about my love for the spring method and whilst that love has not waned, like any relationship I’m having to adapt to change. AND IT ISN’T EASY.

As far as I can tell, the velocity value is now much more sensitive, and larger values have a tremendous impact to the point that any animation where I used velocity values over, say, 100 is pretty much unusable. For example, spring(400,30,500') used to be a nice dampened bit of subtlety and now springs forth like a coiled king cobra. I got somewhat close to it by turning velocity way down and dialing back everything else a bit to 'spring(300,25,10)'. While I haven’t quite figured out a rule of thumb, I’m going to play around with animations more this week.

May 12, 2014

Animating with Framer.js

Well, shit. Framer 3.0 released on May 13, and with that, this post became much less useful. It had maybe a good 12 hours of relevance, which I guess is better than nothing. If you want to learn more about animating with Framer, check out the revamped example library on the Framer.js site.

Making things move

You can animate almost any property of a Framer view—position (x/y coordinates), opacity, scale, width, height—and you can animate multiple properties at once. Every view has an animate() shortcut, which is the easiest way to get things moving.

See the Pen The Most Basic Framer.js Animation by Jay Stakelon (@stakes) on CodePen.

A default Framer.js animation

At minimum, you’ll need to declare the properties you want to animate. Even though it’s optional, you’ll also want to specify an animation curve (more on that in a second) and you also might want to specify the time the animation lasts in milliseconds.

  properties: {
    x: 400,
    y: 500
  curve: 'ease-in',
  time: 500

You can also create animation objects explicitly with new Animation() which allows you to trigger callbacks when they start and end. Check out the Framer docs if you’re interested in seeing how this works.

Basic easing curves

Framer.js gives us a couple ways to dial in animations using curves. An animation curve is an equation that defines how fast or slow an object animates over time. With curves, you can make animations feel natural or exaggerated. Take another look at the default animation above: there’s nothing in real life that actually moves like that. Objects slow down and objects bounce. Easing curves help our animations and interactions start to feel “real” to the user.

Framer gives us a couple of super-easy ways to tweak our animations with four built-in easing curves.

"linear" is the default curve where the object moves at a steady speed throughout the animation. "ease-in" starts slower at the beginning of the animation and speeds the object up gradually. "ease-out" starts at a higher rate and slows down at the end of the animation. And "ease-in-out" slows down at both the beginning and the end of the animation.

See the Pen Framer.js Easing by Jay Stakelon (@stakes) on CodePen.

Bezier curves

So, for real, there is absolutely nothing I can write here that will do a better job of explaining how cubic bezier curves work than already does. If you’re interested in understanding how bezier animation curves work, just take two minutes and play around with it.

Bezier curves are infinitely flexible, but personally I’ve only used these in two situations. You can create an exaggerated version of a standard easing function—for example, a really aggro version of "ease-in-out" looks like "bezier-curve(.9,0,.1,1)". I’ve also used "bezier-curve(.5,-0.5,.5,1.5)" when I want an object to overshoot its target a bit on both ends of the animation (old Flash heads who remember “easeInOutBack”: this is it).

See the Pen Framer.js Bezier Curves by Jay Stakelon (@stakes) on CodePen.


This is my shit. I love Framer’s spring method for expressive and fine-tuned animations. It’s a little abstract but once you have a general idea of what the parameters do it’s a lot of fun to tweak and play with. This demo shows a pretty awesome range of what you can do with springs (found on Designer News).

Start by imagining that the object you’re animating is attached to an actual spring. The method takes three arguments, which I’ve always understood best to stand in for physical properties:

  • tension – how tightly that spring is coiled
  • friction – how much effort it takes to move the object
  • velocity – the initial speed that launches the object

One important thing about timing: using the spring() curve type overrides any time value that you specify for the animation. You’ll see in the below examples how different combinations of values end up creating animations of different lengths.


The Framer docs describe this as “the stiffness of the spring”. As you increase the tension value, you get more speed and more bounce. Lower values accelerate more gradually and have a looser bounce at the end. Higher values accelerate rapidly and bounce quicker and faster at the end.

See the Pen Framer.js Springs – Tension by Jay Stakelon (@stakes) on CodePen.


I think of friction like the brake on a bicycle. The higher the value, the tighter the brake and the more resistance that’s continually applied to the object. Dial up the friction to see things slow down a little and the spring itself dampen a lot.

See the Pen Framer.js Springs – Friction by Jay Stakelon (@stakes) on CodePen.


Out of the three spring parameters, this one has been the toughest for me to wrap my head around. It’s the initial velocity of the object, which I think of as giving the object a little extra push. It makes sense that higher values tend to exaggerate the distance that the object bounces at the end of its trajectory.

See the Pen Framer.js Springs – Velocity by Jay Stakelon (@stakes) on CodePen.

Bringing it all together

Let’s revisit the example prototype from my Getting Started With Framer tutorial. We were building a Tinder knockoff called The Hollerator, and we had gotten far enough to animate a slide-out “hamburger” menu. Here are an updated set of example files if you want to follow along with this quick animation polish session.

We had started by just animating the x property of the Main view, to slide it over to the side and expose the menu:

  properties: {x: 540}

That looked like this, which is way too basic for an app of The Hollerator’s caliber.


Since the easiest way to start dialing in an animation is to experiment with a built-in easing curve, I might try "ease-out" which’ll slow the animation down at the end.

  properties: {x: 540},
  curve: 'ease-out',
  time: 300

But to give the navigation animation a little more snap and bounce, let’s use a spring. Since springs override the time property, we can just remove it.

  properties: {x: 540},
  curve: 'spring(400,30,500)'


Much better, but if you look closely at the navigation closing you’ll see that it bounces a little too hard in that direction, revealing a bit of empty space on the right. So let’s adjust the parameters a bit on the animation that hides the nav, increasing the friction value just enough to dampen that bounce.

// show navigation
curve: 'spring(400,30,500)'
// hide navigation
curve: 'spring(400,38,500)'



Obviously the Framer docs are the place to start, and specifically the source from the Animation lesson (which I very liberally borrowed for all of the examples on this page).

If you’re interested in learning more about animation curves in general, this page from the docs of an animation library called Tweener has a great visualization of different animation curves. Take that over to for an interactive crash course in animation curves.

April 28, 2014

Hello Framer: Getting started with Framer.js

Welp, this tutorial is (already) outdated since Framer’s 3.0 release on May 13, 2014. I might revise it someday, but for now, the Framer.js website just got a great facelift and a ton of brand-new examples that practically teach themselves.

Why Framer?

Framer is a balanced prototyping framework, created by Koen Bok. It’s Javascript-based but accessible to designers who want to create minimally real prototypes with real-feeling interactions. It’s awesome, and fun, to experiment with and dial in animations using Framer. It’s invaluable when sharing interaction designs with a team. If you’re stringing together static screens into clickable paths use Keynote or InVision, but if you want finer control over gestural interactions and motion, Framer is the way to go.

If you know Javascript, you know Framer. So, nice work there.

If you don’t know Javascript: admittedly you’ll have to ramp up and spend a little time on CodeAcademy or something. You need a grasp of basic syntax and principles. But Javascript isn’t specific to Framer, and you’re learning the language of the modern web. The ROI of that time’s going to be greater than investing in a deprecated motion graphics tool or one of many proprietary prototyping GUIs.

This tutorial will teach the basics of how Framer.js works with Photoshop, how to set up a mobile prototype and build a super basic slide-out navigation. It assumes some super super super basic Javascript knowledge but is targeted at beginners. It is also pretty damn long. By the end you’ll have wired up a slide-out menu interaction and with any luck will feel empowered to get real dirty with Framer on your own.

Follow along by downloading the sample files, in which we’ll be prototyping an iOS Tinder clone that we shall call The Hollerator.

Screen Shot 2014-04-26 at 6.07.09 PM

Let me holler atcha

What Framer does

My Framer workflow looks kinda like this:

  1. Build mockup in Photoshop
  2. Export from the .psd to Framer views using
  3. Work in app.js to create interactions and manipulate views
  4. Iterate as necessary, bouncing between Photoshop, re-exporting, and tweaking code

First things first: download the app from the Framer website. It integrates with Photoshop out of the box (and Sketch with a plugin if that’s more your thing).

Screen Shot 2014-04-27 at 1.34.41 PM

Open up and you’ll see a single modal window with a “Run” button. When you click that “Run” button Framer chugs through the currently-open Photoshop file and generates .png files from each layer set. If it’s your first time running it, a directory will be created with the same name as your Photoshop file. All of the generated images will end up in the /images directory contained within.

Screen Shot 2014-04-27 at 1.39.34 PM

You’ll notice that if you re-run Framer as you continue building out your Photoshop file, it’s smart enough to overwrite any existing images, and add new ones. It won’t remove unused images, but won’t create views from them either.

Framer project files

Framer generates a bunch of other files, too, all of which are necessary to create and view your prototype.

/framer is a directory that contains the framer.js core Javascript along with the information that turns your exported images into Framer views and positions them. There’s seriously no reason to touch anything in this directory.

index.html is the file that you’ll open in a browser to view and eventually interact with your prototype. Framer will generate this once and won’t overwrite it, so any changes you make will persist.

app.js is where you’ll put the Javascript that manipulates views and adds interactivity to the prototype. This also won’t be overwritten.


If you downloaded the sample files, you’ll notice a few extras: I find that they help my workflow and I copy them into new Framer projects right away.

/desktop was jacked from the Google Now example on Framer’s own site (the version with this is no longer linked, so I’m glad I did this). The contents within will shrink the prototype down and view it in an iPhone frame if you’re running it on a desktop browser. I find this helpful when I’m prototyping a mobile app. You might not, which I respect but won’t pretend to understand.

Screen Shot 2014-04-26 at 6.35.28 PM

style.css contains a few CSS rules required for the mobile preview mode. Again, if you aren’t into that, you can get rid of these.

framer-toolbelt.js contains a bunch of convenience and helper methods to work with Framer. This post from Cemre Gungor is where pretty much everything in this file came from.

The Guardfile is necessary because I use guard-livereload to refresh the browser automatically whenever I update code. I use Guard out of habit but if you prefer something with a GUI either CodeKit or Cactus (also created by Koen Bok!) both look great.

Getting started with Photoshop

Key premise: for every layer set in your Photoshop file, Framer will create a “view” that you can manipulate. That means it’s really really really important to keep your game tight when it comes to organizing and naming layer sets.

Framer allows us to manipulate these views using Javascript using the name of the layer set. I use initial caps and camel case for layer sets I want to export, which helps me identify these as view objects in the code as well as in the Photoshop file.

Take a look at the .psd from the example files. There are two layer sets on the base level: Main contains content for app views, and Menu is the content for the navigation. Organizing them like this will let you slide the Main view aside and reveal the navigation with some simple Javascript in the next step.

Screen Shot 2014-04-27 at 10.57.26 PM

Inside the Main layer set is the Topbar and the prototype’s single view, Match. If you want to build a more complex prototype, this setup allows you to add multiple views for different screens at the same depth as the Match layer set and turn their visibility on and off with code. Within the Topbar there’s a child layer set, BtnMenu, for the hamburger button in the upper left.

The last thing to note is that within the Match view I’ve separated the Content from the Background, and within the Content view created named layer sets for each of three cards as well as the add and dismiss buttons.

Protip: if a layer set’s visibility is off in Photoshop, it won’t export. This is both helpful in only exporting what you really want, and painful when you forget to make a layer set visible and then spend 15 minutes wondering why in the actual fuck you don’t see it in the prototype.

Another protip: if you have multiple layer sets with the same name, Framer will append “-2″, “-3″ and so on to them when it exports them to views. And it won’t make an exception if it was an accident, so, remember, keep that organization game tight. TIGHT.

It’s business time

Once I’ve got things reasonably well-set-up in Photoshop, I run the first of many exports. Since running isn’t destructive, but additive, have no fear of iterating on not just the prototype’s code but the Photoshop file itself.

The first thing I’ll do is add all of the extra stuff (desktop previewing and the framer-toolbelt.js) I mentioned above to the project directory.

Screen Shot 2014-04-27 at 9.44.58 PM

The next thing to do is open index.html and augment the defaults that Framer gives us. I’ll add in a link to style.css:

<link rel="stylesheet" href="style.css" />

And also replace the default <body>

  <script src="framer/views.framer-tutorial.js"></script>
  <script src="framer/framer.js"></script>
  <script src="framer/framerps.js"></script>
  <script src="app.js"></script>


  <script src="framer/views.framer-tutorial.js"></script>
  <script src="framer/framer.js"></script>
    utils.domLoadScript("framer/framerps.js", function() {
      utils.domLoadScript("framer-toolbelt.js", function() {
        if (!navigator.userAgent.match(/iPad/i) && !navigator.userAgent.match(/iPhone/i)) {
        document.body.addEventListener('touchmove', function(e) { e.preventDefault(); });

This loads the Framer core normally and then sequentially loads other files that have dependencies. It also checks if you’re viewing the prototype on an iOS device, and if not loads up the desktop preview. Finally, it blocks the touchmove event on the body so in mobile browsers the prototype itself doesn’t slide around in the viewport.

Now let’s open app.js. You’ll replace the autogenerated contents of this file with your actual prototype’s Javascript. Just delete everything in here and start fresh.

I add these two lines of Javascript first:

FramerToolbelt.attachToDemoScreen(Menu, Main);

The first line calls a method from framer-toolbelt.js that creates a global variable for each view exported from your .psd file. (Again, credit to Cemre Gungor for this.) Normally, you’d refer to views as properties of the global PSD object that Framer provides, like PSD['Main']. This method just makes them available as global variables that you can reference directly: PSD['Main'] is now just Main, PSD['Menu'] is Menu, and on and on.

The second line calls a method that sets up the desktop preview mode. Pass in references to all of your top-level views (remember, in the .psd file we’ve just got two layer sets, Main and Menu, at the root).

Now open up index.html in a browser window and feast your eyes on something that should resemble this:

Screen Shot 2014-04-27 at 10.06.28 PM

Ok, but it doesn’t actually do anything yet. Let’s change that by adding an interaction to show and hide our slide-out menu.

We want the user to tap the hamburger button in the upper left, which should then slide the app content over to reveal the menu “behind” it. So let’s write a function to do just that, and call it when you click or tap the hamburger button, which is the view called BtnMenu.

var toggleMenu = function() {
    properties: {x: 540}
BtnMenu.on('click', toggleMenu);

You can manipulate the position, rotation, opacity, scale—anything documented here—of every Framer view with the animate() method. Framer gives us the ability to listen for events on any view as well. So what we’re doing with the above is first declaring a function that will move the Main view to the right, and calling that function when we click (or tap) the BtnMenu view.

So that’s cool, but Framer uses a default time of 1 second for animations which is way too slow for this. Generally, I find that animations triggered by a user action feel most responsive somewhere between 200 and 300 milliseconds. Just add a time property to the animate() method to speed it up.

  properties: {x: 540},
  time: 300

Now you’ll probably want to close that menu after opening it. That means reversing that animation if the nav is already open. We’ll need to keep track of whether the menu is open or closed and we’ll use a global variable called isNavOpen for this:

var APP = APP || {};
APP.isNavOpen = false;

Declaring the APP object first creates a namespace for this and any other global variables you need for your prototype. And now that you have it, use it in the toggleMenu function:

var toggleMenu = function() {
  if (APP.isNavOpen === false) {
      properties: {x: 540},
      time: 300
  } else {
      properties: {x: 0},
      time: 300
  APP.isNavOpen = !APP.isNavOpen;
BtnMenu.on('click', toggleMenu);
Menu.on('click', toggleMenu);

Now this function’s smart enough to know whether the nav is open or not, trigger the right animation, and then update the state of the navigation. You can also bind it to the Menu view itself so if you tap anywhere on the menu once it’s visible, it’ll close.

More resources

I’m planning on writing up some ongoing Framer tips and building on this beginning tutorial with deep dives into animating and gestural interactions with Framer. This’ll hopefully just add to a great library of documentation, samples and other tutorials released as Framer’s steadily gained popularity. Here are but a few:

The Framer docs themselves are the best place to start, of course, and there are some solid examples of working prototypes on the Framer.js site to dissect and learn from.

Robb Schiller wrote a concise introduction to Framer that helped me ramp up quickly. I also found another introduction to Framer which goes a little more in-depth.

And the Framer.js Hackdesign lesson gathers a lot of resources on Framer into one place. The introductory video is definitely worth watching.

April 21, 2014

UXPA LA Presentation + Updates

A couple weeks ago I snuck my way onto a panel of seasoned UX leaders talking about the peculiarities of UX in our different orgs: startup, agency and enterprise. I talked about how we do UX at Fullscreen; here’s the deck.

In other news I’m unsurprisingly falling off on blog frequency but will soon be dropping a tutorial that shows how to prototype a mobile app using Framer. So, yeah, that’s exciting.

March 08, 2014

You Don’t Have To Speak To Critique

This UX and design critique technique uses silence and post-its to make traditional design reviews more efficient and honest. By not speaking at all, everyone gets heard. So it’s basically like magic.

The inspiration for this critique method came from Leah Buley’s book The User Experience Team of One. She describes a “Black Hat Session” when a designer gets a bunch of stakeholders together, sets aside niceties for a moment and has them write down everything they feel is wrong with a set of designs or flows. Since everything they do is pretty much pure gold, Google Ventures also uses a version of this technique in their design sprints.

Our product design team at Fullscreen has a variant of these exercises that adds a little bit of positivity to the “Black Hat” approach, timeboxes everything and leaves us with a visual record of what’s working and what isn’t with a set of designs. It’s a super-efficient way to distill feedback from a range of different voices into simple, actionable next steps.

2014-01-14 14.40.41

Such silent. Much contemplative. So honesty.


  1. Round up your team: designers and product folks, engineers, any other interested parties. And start by hanging work up on a wall. Sketches, printed mockups, whatever you’ve got. The more the better, especially if you’re working on distilling a bunch of concepts into one or two directions.

  2. The first ten minutes is a silent critique, so no one should be asking questions and designers shouldn’t be trying to explain their work (yet). Give everyone some post-its or colored stickers. One color for positive feedback, and another for critical feedback.

  3. Take five minutes for everyone to mark elements of the designs that they think work well. You might ask participants to write a little note about what they like on a post-it, or you might just have participants stick the positive color to elements without a note. (Just using stickers is quicker and gets more feedback, but writing a quick note gets a little more depth and also ensures that everyone’s thoughts get brought up.)

  4. Then take the next five minutes and have the participants mark up everything they don’t like about the designs.

  5. Now that you’ve got a visual record of what resonates and what doesn’t, it’s time to get the team talking. Start with each designer giving a quick overview and some context for each sketch or comp, and then go through the feedback. Every participant should have a chance to speak about what they marked up, both positive and critical.

2013-10-10 17.53.30

The session’s done, but you can still see what worked and what didn’t.


  1. Starting out with a silent critique evens out the levels. Not having participants speak at all until the final step normalizes the differences between loud and quiet voices so everyone gets heard.

  2. Giving participants a non-verbal means of identifying weak spots helps overcome tendencies to just be too damn nice in critiques. It’s just easier to be honest when you’re writing a critical thought down or just using a sticker to represent that critical thought.

  3. It’s a very economical way to get feedback from a group. Timeboxing the negative and positive feedback rounds keeps things efficient and you end up with a punch list of points to review in the final step which keeps everyone on track.

  4. The final outcome visually surfaces the things that work and the things that don’t. Once everyone’s marked up the work with stickers and post-its, you’ve got a heat map of the aspects of each design that resonated with the group.

February 12, 2014

Two Hours With Quartz Composer + Origami

Yeah, I’m jumping on the QC bandwagon while it’s hot. Last week like so many others like me I read the Fast Company article celebrating Facebook’s release of Origami, a plugin to Apple’s Quartz Composer graphics tool that aims to make it easier to use for interaction design and interactive prototyping. I had opened QC once or twice and found it pretty unapproachable, but this time committed to spending a couple of hours figuring it out. I’m eventually going to write a lil’ tutorial of my own about how to get started prototyping a simple app, but for now wanted to share a few useful starting points and tutorials, and a few less-useful personal reactions and observations.

QC is clearly a very powerful tool with generative graphics and animation capabilities that go well beyond what I’d need for even complex UI prototyping. There are some full-on epic examples of what’s possible woven into this discussion thread on For example, check out this prototype of Facebook Home’s navigation complete with “gravity” effects. It’s evident that mastery of this tool gives an interaction designer a ton of knobs to tweak when prototyping and demonstrating rich animations and interactions.

QC, even with Origami, is definitely not a “photoshop for interaction design”. The Fast Company piece calls it that in the title, so it’s not my fault for expecting it. Origami makes it promising, but it’s nowhere near a one-stop shop. You’ll need to use Photoshop (or Illustrator, or Sketch) upstream from QC in your workflow to design, create and cut graphic assets—just like you would when designing an app—to import into QC and bring to life. The size-cut-import workflow actually reminded me of the good old days of building Flash apps, just without any ability to create vector shapes or type.

I’m pretty sure that knowing how to prototype using CSS and Javascript makes it harder for me to grasp QC. It’s taking me a lot more time than I want to admit to get used to the “visual programming” interface that QC presents. I actually think that experience thinking in code puts me at a disadvantage; for example, my CSS-bred mental model views things like X/Y coordinates as intrinsic properties of an object. A div containing an image has set of CSS rules like position:absolute;top:10px; applied to it directly. In QC, if I want to apply that same 10 pixel offset to an image, I need to take the image and manipulate it indirectly using what QC calls a Transform patch. That, and there’s the typical beginner’s frustration of knowing that I could build a tab bar in 10 minutes MY WAY but instead I’m sitting here connecting those fucking tiny little wires to boxes repeatedly and seriously, can’t I just $('.tab').on('click') or something and make it work already?

There really aren’t that many QC tutorials that focus specifically on interaction design and prototyping. It seems like there’s a community of VFX artists and, specifically, VJs who use the tool to great effect and have made both tutorials and tons of sample files available on and It’s a bit harder to hunt down what applies specifically to an interaction designer’s use case.

QC and Origami Resources

Dave O’Brien created an epic set of video walkthroughs where he recreates Facebook Home using Quartz Composer. Confession: I didn’t really watch past the second one. I bet that if I did, I’d like QC more.

And whoever these Prabrothers are, they appear to be on track to write a super-comprehensive guide to using QC for prototyping. The first chapter alone as well as the glossary are the two best introductions I found.

This Hackdesign lesson on QC has links to those two and more.

Finally, the example compositions from Origami’s own documentation were perhaps the most enlightening of all. They have these helpful little hints nestled within the different editors, not to mention very explicit descriptions of what each of the Origami patches do.

February 03, 2014

Building A User Testing Lab, Part 3

I wrote a couple of posts about preparing our discount usability testing and user research lab at Fullscreen with software, hardware and a physical space. In this third and final post, we get to put it through the paces for the first time.

Faking It (since we don’t want to make it yet)

The team used Keynote to prototype two different takes on a feature we’re building into the Creator Platform. Keynote is basically awesome for early-stage interactive prototypes because not only is it super-quick to learn and use (especially if you start with something like Keynotopia’s UI stencils) but also it’s relatively simplistic design features force a lower-fidelity approach than using Photoshop to create screens for a prototype. Bonus: it’s free!

It has limitations, though: for example, you can’t scroll within a screen. Since one of the concepts we wanted to test was heavily reliant on vertical scrolling, we had to (really inelegantly) fake it. This particular concept tested unanimously worse than the other one, which didn’t happen to require such overt trickery. And while I don’t attribute that to the scrolling fakery alone, I’m sure they didn’t help make the experience any easier to understand.


Using big blue arrows to “scroll” up and down a page: not even minimally real.

More faking: we used a static screenshot of browser chrome to frame the content of each prototype and make them seem minimally real. Which worked so well that it only took a couple minutes for someone to try the static browser “back” button when clicking through prototypes. It just took a quick adjustment to build a fake back button by placing a transparent hyperlink over it leading to the “previous slide” and it was a reminder that anything we present users with during testing is fair game and the more we can anticipate, the more realistic interactions we’ll be able to observe.

Capturing It

Since we were testing prototypes of a web app, there was no need for much of the laundry list of equipment that we’ll need to properly capture mobile user testing. Just a Macbook running Silverback to record a screencast and the user’s reactions. It worked pretty well to capture the 45-minute sessions, although sometimes we had a tough time making out what the subjects were saying when we played them back. Next time I’ll definitely try using an external mic which should take care of that.

Once the sessions were wrapped up, we got the team together to watch them and talk through the results. This almost didn’t happen because I didn’t realize that you actually need to export recordings from Silverback, which can take a good amount of time for these 45-minute sessions. Watching low-res previews within Silverback worked in a pinch, but next time I’ll make sure to allow for a little bit of time to get those exports done before getting everyone in a room.

All in all, testing web app prototypes was pretty seamless. I’m looking forward to getting some users in to do some mobile testing next time.

January 17, 2014

Building A User Testing Lab, Part 2

In this follow-up to my first post about building a discount usability testing and user research lab at Fullscreen, I’ll talk about setting up a space for testing and getting the right equipment on a budget.

The Space

Though it’d be nice, a permanent room for our user lab just isn’t in the cards so I needed to find a space to set up shop in and conduct interviews and sessions for a few hours at a time. It was easy to narrow down the candidate pool since there are really only two private and distraction-free rooms in our building that aren’t also occupied by people who, you know, need to work in them.

We’ve used our conference room for user testing sessions in the past. It’s worked out fine, but it also feels a bit overwhelmingly large when you’ve only got two or three people in it. And we also have a little loungey game room with a couch and two comfy chairs—which is what we’re going to use. Since the room itself is more like a place where people would actually use the products we’ll be testing, on some level it’ll be easier for them to engage in authentic behaviors under admittedly artificial circumstances.


Even if you don’t have an Arduino-controlled keggerator at your house, it’s a pretty easy guess which room you’d feel more at home in

The Equipment

OK, that was easy. I’ve basically got a living room to work with the users in, and the Silverback and Reflector apps installed on my laptop. Now it’s time to go shopping, keeping in mind a budget of $1000 max including devices.

Webcam: Silverback uses the built-in iSight by default, but to test mobile prototypes I’ll need a webcam to capture the user’s reactions. We had a 1080p Logitech C615 ($49) sitting around, but if I had to buy one I’d just go for this Microsoft LifeCam ($19) which is still 720p and still more than adequate.

Mouse: Good to have one handy for users who aren’t used to trackpads. Since non-Mac users won’t be familiar with the $70 Magic Mouse anyway, a standard-issue Logitech USB mouse ($17) should do it.

Microphone: I’ve had a Blue Snowball ($59) for a couple of years. Could probably get away with using the laptop’s built-in microphone, but I don’t want to miss a thing.

Mobile devices: Here’s where things get a little expensive. I went for an entry-level iPod Touch ($229) to test iOS apps and demo mobile prototypes (using Invision, an app that makes it simple to string together screens into passably-real prototypes and get them onto devices). Way cheaper than a $600 unlocked iPhone, and no need to pay another $10 for a blank SIM card just so you can open mobile Safari.

The total cost for all this equipment, as well as the software to record sessions and stream from devices, would be just $410. Way under budget, I also took a protip to heart from Pocket’s experience setting up a mobile testing lab. They note that the iPad mini is a perfect size for demoing iPhone prototypes built in Keynote, which is another amazingly quick and effective way to get early validation of rough concepts. So I got hold of one of those as well. All in, the total cost for this multi-device testing setup including software, camera, microphone, mouse, iPod Touch and iPad Mini is $659.

I’m excited to put it all to use (tomorrow!) and report back on what went wrong and hopefully a lot of what went right.

January 10, 2014

Building A User Testing Lab, Part 1

This is the first of three posts about my experience building a discount usability testing and user research lab with the team at Fullscreen. I’ll talk about why we’re doing this and touch on the software that we’ll use to capture sessions.

Google Ventures-style product design sprints seem to be popping up all over the place these days. Design sprints have become an important piece of our process toolkit at Fullscreen, not just because I love me a good trendy methodology but really because they’ve helped us us immensely with quick parallel concept development and rapid validation.

In a product design sprint, you bring ideas from concept to low-fi prototype in less than a week and then get them in front of people—preferably, real users of your product—to see how they hold up. So you need a place to work with the users during these sessions as well as a way to capture the sessions so the whole team can review and “score” them.

Now our relatively new office, despite its many lovely features including a human-size terrarium, doesn’t have one of those fancy interview chambers with a one-way mirror and HD simulcast capabilities to the adjacent observation room’s three flatscreen displays. What we do have, though, is our first design sprint of 2014 starting next week. And we need a way to conduct and capture those user sessions by Friday.

So we’re building a user testing lab that makes use of our flexible space and can be set up and taken down with extremely minimal effort, that can handle both desktop and mobile prototypes, and that costs less than $1000 including devices. I’m going to document this exercise for posterity starting with the software we’ve chosen to capture the sessions, then the hardware and the space itself and finally what will hopefully be a triumphant recounting of the first user sessions we run in it.

The Software

Our discount usability lab needs to record two things: the interaction with the prototypes onscreen and the user’s face while they’re interacting with it. We want this captured in a single video file so it’s easy to review and discuss later.

A few years back I used an app called Silverback to record some user testing done while building a group messaging app called Volly. Silverback doesn’t seem to have changed altogether too much, but that’s a good thing. It’s designed for doing exactly what we need, which is recording two streams of video—a screencast and the user’s face so we can get the full brunt of their reactions and thought process. It’ll use your laptop’s built-in iSight by default but getting it to recognize a USB webcam is as easy as plugging it in. It even records hotspots whenever the user clicks so you can tell exactly what’s going on.


Note the awesome little hotspot where I clicked. Also the depth of that v-neck

I’ve also heard that ScreenFlow gets the job done despite having an old-timey website, and it also has built-in editing features which could be handy if you also wanted to use it for something else, like recording product demos or tutorials. ScreenFlow’s extra features have a $99 price tag, though; since Silverback is only $70, that’s what I went with.

We’re sorted for capturing desktop user sessions. But what about testing mobile apps and prototypes? My first thought was to try awkwardly clamping a USB document camera to the mobile device. But this post by one of the creators of Silverback points out how ridiculously simple it is to mirror any iOS device using the $13 Reflector app.


Silverback x Reflector. Since you’re wondering, the app is called Tuxedo Kittie

With Reflector, you can mirror whatever’s happening on any iOS device that supports AirPlay mirroring (devices with just plain old AirPlay need not apply; my old iPhone 4 was a no-go). Open Reflector, and your computer will appear as an AirPlay receiver to your phone. From there, it literally just works.

That is, for iOS. Looming large is the day when we find ourselves wanting to capture user testing using Android devices. There’s no doubt in my mind that this will in no way be as painless as Reflector makes it for iOS devices. But as someone wiser than myself once said, any testing is better than no testing at all.