Daily Prototyping

A few months back I had the opportunity to hear Tom Chi of Google X design speak. I was deeply inspired by his idea of doing to learn rather than talking and brainstorming. Feeling uninspired and rather lost in my own process and career I decided to perform an experiment of my own - by implementing a practice of daily prototyping. Could I prototype my way into relearning to prototype - or more to the point - back to creating and physically building to learn?

Complex Visual Storytelling
In 2011 I began creating a series of case study PDFs that allowed me to tell a story of my work with an individual client. After prototyping for many months - I'd finally created 3 solid stories that showed my work across a broad generalist skillset and most importantly to me - showed that I worked in physical products, software and cross platform implementations.

Now I was ready to start telling more stories of process and ways that I want to work across my skills and beyond. To do that - I needed a stronger design - visually and informationally.

With that in mind, and to avoid the "planning as doing" habit I've been reinforcing in my daily life the past few years, I dove into a project to prototype the presentation of my portfolio in static form.

I had some basic guidelines:

1. Present a wide variety of information - photos, outlines, wireframes
2. Create a visual language (color, style and organizational graphic elements) that lets me communicate process and complexity
3. Keep evolving my quietAction branding and also bring my name higher up into the communication structure

Since I don't do visual design day-to-day an additional quest was to wake up my skills and explore some different styles of design. This required some time looking at different inspirations I'd been collecting over the past year. I quickly realized that the first part of this prototyping push was to prep materials for my prototyping. So I collected links from portfolios, sites and apps that had visual, information or styles that I found appealing. I also collected text, screenshots and vector art for some basic elements that I could throw into the prototypes.

DAY 1

I began with the brand and visual design from my case study PDFs and attempted to start iterating in new directions.

I was really rusty when I started so I began by trying match some of my inspirational designs. Could I make it dimensional? Could I flatten it out? Could I go for full whitespace design?

What happens when I add increasingly complex information? How can I show the breakout of one part of a product flow so it's clear what is being shown? How about an outline with wireframes? Could my basic architecture and visual hierarchy hold up?

While I was pleased with the informational communication of the day's prototypes, I was left with an overall dissatisfaction with how "stick-ish" it all was. I found the flat, outline quality of all of the elements - text, brand and information - didn't allow any of them to shine. It ended up looking just as complex as it was.

DAY 2

The next day I took this underlying dissatisfaction into the process and continued to attempt to organize the information and iterate on layout and adding more whitespace.

Discriminate and reset
Eventually, it was clear I was rearranging deck chairs (i.e. on the Titanic) and I stopped to chat with my brilliant design friend, Cliff Jew. Over the years I've come to value Cliff's ability to talk through design issues with me and to help me see what I'm missing so I can keep iterating in a new direction. This process of "discriminating" is critical in a prototyping process. You have to know when you've stopped heading in a direction that is fruitful - reset - and then be able to move nimbly in a different direction.

When I explained my irritation with so many flat elements on the page hindering my ability to distinguish between levels of information or even visual flow around a page - Cliff immediately jumped to the idea of "traveling through" the information rather than simply laying it out to be read. Traveling and storytelling both have a time component. What could I add to the visual design that allowed us to make the information special and also allow us to move through it in an organized way. Cliff remembered an old project he designed that used 2.5d graphics to lead a person through a setup of a physical product. By adding a spatial component he was able to separate out textual and design elements from the most important data.

Taking a one of my designs he quickly overlaid a couple of examples of dimensional objects into the page to see if they would fight. Rather than fighting, the additional of a spatial quality to the data made it into a "secret garden" that a person could engage with separately from the text and brand container.

After I got off the phone with Cliff, several things started to happen. I let go of my original brand container and moved toward a stronger whitespace design that focused on my name and that this is my experience exploration (portfolio). I learned how to orient my vectors spatially in Illustrator (be very, very frightened :D). I suddenly got much braver. You can even see the happy accident moment - "Look what happens when I go FULL whitespace" in my Evernote documentation.

DAY 3

2 days later I finally got back to this project and was very pleased with where I had landed. I decided to try laying in some of the material that I had from my case studies to see how things held together when I added even more complexity. I think it turned out pretty well with a lot of room for improvement and continued prototyping. And it's a huge leap from where I started. Definitely well worth the time and effort.

THE REAL LEARNING

So, in this 3-day sprint I learned quite a few things.

1. It's good to have some prep time to gather some base materials to prototype with. While it's cool to have placeholders, it's tough to keep a flow going if you don't have any raw materials handy.
2. Discriminate. Know when you've run into a wall. Phone a friend or simply leave that direction alone and try and jump to something completely different.
3. Keep yourself moving and be brave.

Self-documenting storytelling
One of the principles of Lean UX is that you want to engage in process that is self-documenting. In this case, I quickly created screenshots, threw them into Evernote and added some discussion of how the day went. Because I did this each time I took a break - the result was that I had a living document that helped me tell a story far more powerfully than any single static document could ever achieve. I consider this one more portfolio prototype in these days because it - more than the static elements - will become my FUTURE story.

I can't encourage you enough to begin incorporate this hands-on style of moving through so many of your life challenges. For me there is very little that you can't apply this to in my life. Stay tuned as I'll share some other prototyping I'm doing as I get further along in the process.

Inspired: D3 Talk - Tom Chi

A little more than 2 weeks have passed and I'm still reflecting on and playing out Tom Chi's D3 Rapid Prototyping X talk. It was a really wonderful way to start this year's D3 conference.

When he started speaking, Tom seemed a tad distracted. It seems that he was still thinking about what Jennifer and Jody had talked about in their opening remarks. "Local - social - mobile aren't fads. Things have always been that way, we're just getting technology that allows us to explore that." And then he was back to telling about rapid prototyping - Google X style. As the experience lead of Google X, the R&D team at Google that has brought us intriguing prototypes such as the self-driving car and Google Goggles, Tom showed us how his team works.

RAPID PROTOTYPING X

"How long do you think it would take to create a physical prototype for Google Goggles?" The crowd guessed a few days, weeks, months. Throwing an image up on the screen - he comments, "1 hour." Then he showed how his prototype, created from a Netbook, Pico projector, coat hanger, and screen from a sheet projector actually does provide the EXPERIENCE of seeing additions to reality through a layover lens. This is not about the final form and version. This is about creating an experience that can then be tested and tweaked - as quickly as possible. The rest of the day was used for multiple experiments in software and input to the system. Could they create a finger mouse? Could they use any surface to control the interface?

Then he moved to an image of Tom Cruise in front of the gestural interface from Minority Report. Throwing a slide up on-screen which shows a coat hanger above a whiteboard, with an input he created out of chopsticks, a binder clip, pen and presentation clicker. Using this 45-minute prototype he was off and experimenting with gestures and software that changes its response to how you move your hands - pointing to select, grabbing an email. By fast prototyping in this way you're learning things that you can't learn any other way. As the creator of the prototype you experiment and use it in the ways that make sense to you. You create new rules and gestures.

Then when you invite others in to play, you learn even more as you watch them interacting. See how they do a small flick when you thought a grand gesture was a better way to move through pictures. Watch them as they begin to slow down and rub their shoulders. Ask them what's going on - their shoulders are sore. Eventually the team figured out that if you keep gestures below the heart and in the "batting box" that you can use them all day. Above the heart creates soreness and fatigue to the muscles. All this from a 45-minute prototype and tons of experiments with it over a single day.

The main point of this - get to as real an experience as you can as soon as possible. You're going to learn the lesson at some point anyway, so why not learn it now?

Moving back to Google Goggles he showed pictures of some of the multitude of different forms that others had created for this type of device. As they began looking at the final form of the product the team followed the same process and created a single line of modeling wire that would hold the experiments to the face. Then they carefully cut and measured pieces of clay to match the exact weight of some of the components they were thinking of using for the device. This allowed them to wrap the pieces around the wire in as many ways and combinations as they could come up with. They discovered when testing weight, balance and comfort of wear that putting the heaviest weight behind the ear allowed the highest comfort because it used the ear as a fulcrum rather than the bridge of the nose.

"And we were already aware of how strong the ears are...<small grin> but that was a different experiment."

"Don't get dazzled by technological frameworks. Ask yourself what is the most basic question we're trying to answer. What are you trying to learn? How can I get to something to test that in an hour or less?"

RATE-BASED GOALS

Moving on to the theory behind the practice he showed how bringing down the time to create your prototypes maximizes the rate of learning. He points out that increasing the total number of experiments you do, increases your overall chance at success. Since we tend to fill the time we expect a task to take - think it'll take 4 months, takes 4 months - we can work toward high-speed prototypes by unhooking ourselves from fit and finish expectations. His team uses rate-based goals to maximize and constrain this process.

Don't guess. Learn.

He points out that while we're really good at the actual development of our products, we really aren't very practiced at the entry to the process - the research phase. So often we jump to the end point - the possible outcomes of "what our product could be" - talking and guessing as to what it could be. Then the most senior person in the room chooses what they think the best option will be and we go and start prototyping.

We're physical beings. So work in that medium.

This is backwards. Outcome-based goals assume that you already know what you're making. Don't spend time talking, sketching or creating words to describe the possibilities. It's about building - and learning from that. With fast prototyping research phase at the front of your process you can explore a much larger range of possibility, much more quickly, with a more accurate read of the market that the product will launch into or disrupt. It's important to note that this is not about what it looks like, it really is about getting the correct FEEL as quickly as we can.

On Google Goggles, rate-based goal was to produce 15 hardware prototypes a week for 10 weeks.

Don't fail. Learn.

He feels that the idea of "failing faster" isn't the point. You can fail without learning and learn without failing. Rather than shaming each other for supposed failures, tell the team about the tiny percentage that did work so that we can learn together and move forward with that knowledge. Know what directions that you aren't going to pursue but keep doing variants on the prototypes that are heading in good directions. This is not a free-for-all. It's important to discriminate and determine which of the experiments are answering your questions and providing the learning you need.

On the Google X team, each Friday they show what worked and what didn't from the 15 experiments. Magical or "that has to be in the product" moments were starred. Then they planned for what experiments would be continued or new directions they wanted to try. Some weeks this would produce 40 or more stars. At the end of the 10 weeks there were hundreds of stars or important learnings from the process. The team then begins "constellating" by creating groupings or constellations of features and experiences that would make for a coherent, desirable product. Stepping back to look at the constellations, a decision is made on which to pursue and the development phase begins.

Benefits of Rate-based goals

1. Simple way to measure progress
2. Immediately actionable - no more waiting
3. Allows you evaluate experiments faster
4. When you can evaluate faster, you can experiment faster

Try ludicrous things. Don't need to spending time arguing about what "shouldn't" do. Since we've lowered the cost in terms of time, let's do it and experience it together. Can lead to happy accidents and new directions, or at least a few more possible outcomes that won't be used.

Definitely need to set a limit on when you will stop this process because of the nature of this type of creativity. Each pass only increases the creativity and speed of the team. At some point you need to stop and get to the next phase - getting your product produced and out into the world.

A question from the audience was about what he was looking for in the people on his team when he was working to accomplish things like 15 prototypes a week. He said he likes to look for Pi shaped people who have good generalist tendencies but also have a deeper knowledge of at least one right-brain and one left-brain skillset. This way they could pull on both sides to do some of the work needed in balancing creativity with real-world editing of their efforts. Nice to have people that can do that internally rather than needing to get that kind of validation from outside via committee. He's also seen partnerships of people to form this kind of a type of loop work really well.

Another question was about documentation. He felt that you needed to stay with communicating the "feel" of the feature and product rather than the specs of what it should be. Just as a composer creates, putting notes on the page to help recall the path that was traveled, so a prototype is the communication of what needs to be built. If there is guessing as to the intention in that process then it becomes something else. There's a disconnect in learning from one stage to the next. Better to let the person listen to the composer playing the piece - communicating via experience "this is what I want." We want to do the same. "This works, do it like this."

Personal shifts

This was a timely talk for me. As I struggle to find work that fits, there's an obvious "problem" that requires experimentation and doing in my life. Tom was quick to point out that this type of process works across everything in our lives. i agree. Currently, I'm in the midst of a 3 week design portfolio research process. I plan on using my learning from creating 5 or more prototypes a week to create a class that allows others to prototype their own portfolios. This is perfect for a hybrid Skillshare class and I look forward to learning together. Did you notice the amazing amount of energy and focus in that little waterfall of doing? So powerful.

Already this process is shaking out tons of bad habits. I've become a thinker rather than a doer in the past few years. It feels amazing to simply move back into trying things and seeing what happens. I promise to report back on my learning in a future post.

Rapid Prototyping X by Tom Chi from Kicker Studio on Vimeo.

ux toolbox: interaction animations

As I mentioned in my previous post, if you set up your interaction storyboards correctly, it's a very short road from your static version to an animated one.

Typically my static work goes into some sort of an interaction script format that provides annotation and detail to the stories I'm trying to tell with those graphics. Then it's pretty simple to figure out what I need to animate. If I'm scenario planning, I tend to winnow down to one or two options before I move from static to animated content - saves time and makes decisions simpler with far less changeback as you prevent decision overwhelm. Good way to stay out of that lizard brain while keeping interest high in your feature stories.

My current workflow is using Illustrator to set up my wireframes, mockups and static interaction storyboards and then transferring into Flash or Fireworks to add animation. I may give Keynote a try one of these days as I see a lot of folks finding that an easy transition for presenting and design research. You can see @lukew's interesting write up about how that is becoming his favorite workflow. Personally, I'd miss creating my own graphics on the fly at the same time I'm animating.

Regardless of method, there's nothing like getting objects moving and increasing complexity in your data to shake out interaction questions and details.

Early and often
In touch-based design, prototyping early and often is critical. When your team is deep in coding it's helpful for someone on your team to be able to do quick animated prototypes to speed decision making with stakeholders and check-ins with users.

Using animation it takes far fewer annotations and arrows to communicate most gestures and interactions - particularly if they have complex outcomes. And, in products where it takes a long time to code and physically prototype your interactions, it can save months of programming iteration by allowing early testing of the gestures and actions that are critical to your user experience.

In a few projects I've even done away with complex static documentation - instead storing these animations in a directory for engineering to reference as they build. We even deconstructed a few of them to see how we might improve them when we got to the code environment. That's the first time I've gotten to pore over my animations on a code level in a long time and we all found it to be powerful way to collaborate. Being able to work over your algorithms via animation prototyping - priceless.

I remember a complex mobile project in which I ended up having to add a series of very elaborate video and audio inputs to simulate the complex functionality of the app. The behaviors we were testing were very new to users so it was critical to get into some detail so that the engineers and users understood the problem we were trying to solve - attracting attention for the most critical next action when interrupted mid-flow. A couple of quick design tests later - and the winning solution was immediately evident. Usually, to find this kind of data, you have to wait until you're far enough along to have some fairly complex features up and working. This saved us several weeks of Agile feature iterations. Yea!

Moving from static to animated

Below you can see 3 scenarios from the Nokia mobile product. We began with the static versions to quickly check viability with engineers, asking, "Is that possible" in our scenario planning workshops. Then when we had good directions (met our business goals and were technically feasible) we animated them quickly and threw them on the phone to see how they performed. If they provided good user and stakeholder feedback - the feature was added into an Agile cycle.

Open menu

Navigation carousel (scenario 1)

Close menu