The Rocketeer Blog Subscribe via RSS

Archive for September 2012

Using Prototypes to Communicate Concepts Faster and More Awesomely

Prototyping is used as a quick and dirty way to flesh out an idea or test out an issue that you don't know the answer to. There are numerous different ways to use prototypes, ranging from stop motion animations using paper to flash animations to actual prototyping software.

I first started with paper prototyping on a new project with my co-worker & UX Strategist, Alli Dryer. We wanted to find a good layout for existing content for an iPad app. We used a mix of paper, crayons and a few printed out mockups and placed them in an iPad sized paper frame. This allowed us to quickly play with different layout options and get a feel for how each section could move. This helped us rule out the layouts that didn't feel right in the device pretty quick and hone in on a few that we could play with further. It was a major time saver for the developer and us.

It is important to keep in mind that this is a proptype and not to spend your precious time making it perfect. Your inner OCD will appear as you begin to cut out pieces of paper and realize they don't equally match. Don't worry about this! Remind yourself that this is not a final product but merely a helpful tool to get the idea out there. Once the idea is established, it will be thrown away as new ideas branch off of this one.

The next iteration was testing out various interactions - basically just playing around to see how things work. It’s fast paced and helps you get a quick confirm (this totally works!) or deny (oh no, don’t ever do this again!). We really didn’t want to involve the developers in the testing phase of this cause it would really be wasting their time. It was best for us to just figure out what we could on our own, and then talk to them to test out our findings.

For this we used the app iStopMotion, it uses a combination of both the iPhone and iPad. I set up a tripod and positioned the iPhone to be used as a camera. The iPad was used as a base station, allowing us to play with the exposure, focus and taking the actual shots. The result was a quick stop motion video that mimics actual interaction enough to tell if it was something we wanted to move forward with or try something else.

Once the app was in the design phase, we started putting the comps in Field Test. This tool allows you to upload comps and apply tappable hotspots that animate with touches and gestures. You can share this project via a mobile friendly link and present the prototype on an actual device. This gave the client a sense of the look and feel of the app, so they weren’t just looking at flat paper comps. Although there were some limitations to animations, this became our living spec document.

Sometimes simply explaining animations verbally, adding various swooshing noises and crazy hand gestures, receives an audience of blank stares. Animation software, like flash, is also really handy when you are trying to explain how screens should transition between one another. This is also something that needs to be done right or the experience will lack polish. With this knowledge on my shoulders, I had to get the animation right (or pretty dang close) to show the developer. You can see below one of these animations:

Prototyping is great for design iterations, but it also a great tool to help others understand your idea concretely. Prototyping allowed us to brainstorm many options before plunging ourselves into the app building process. It also allowed us to fail without going in too deep and wasting time. Prototyping gave us something to show the client so they could see how things were going to function in the app, before the app was built. It was also helpful for the client to have something to show their team internally, making approvals to go by a little smoother on both sides.


Why Bottle Rocket Apps Has Gone (Back To) "Lean"

Upon our launch in 2008, Bottle Rocket Apps pioneered a “low-fi to high-fi” approach to developing apps. We started with an app mission statement and explored various user experience concepts through pencil sketches. We then designed and built the app based on those sketches and constant discussions with the client as the app evolved.

As we grew beyond just a handful of people, and added Rocketeers who specialized in app strategy, user experience design, quality assurance, and other areas, we adopted a more formal approach. We would devote a considerable amount of time up front to establishing a defined scope for the project, developing in-depth requirements, and creating a detailed, written specification for the app. All this happened—usually over numerous revisions—before we ever placed a pixel in Photoshop or wrote a line of code. This spec became the bible for the entire project and only after the client approved it in its entirety would work begin. And even then, much time was spent constantly trying to keep the spec updated throughout the implementation and testing of the project.

After a while, we began to realize that this rigid “waterfall” process was beginning to buckle under its own weight. For starters, it was incredibly wasteful. We wasted valuable time in the sales process, trying to pre-define a project scope, when our talented strategists had not yet engaged with our client. Then we wasted more time and effort—both the clients and our own—in the design phase, trying to think through and solve every possible problem on paper. The spec began to get in its own way—instead of focusing on shipping an app, we were concentrating on an interim deliverables that really had very little value to anyone.

Then there was a second, less obvious problem. We always emphasized user-centered design, but no actual users ever saw the app until it was released to the market. Instead, we built the app based on our client’s and our own unconfirmed assumptions. Fortunately, we are quite good at what we do, and our clients generally know their users fairly well, so major misses were rare. However, when fundamental failures in the solution (like unneeded or missing features, or usability problems) did occur, they were much more costly to correct late in the development cycle, or when the app had already been released.

So earlier this year, we decided to return to our roots, in a sense, by adopting a new and simpler approach. This approach was informed by the teachings of Lean Manufacturing, Lean Startup, Lean UX, Agile software development, and our own years of experience in the industry. We did away with our waterfall process—and in fact, with any type of standard process at all—and chose instead to approach each project from a set of core principles.

Those principles include:

  • Eliminate waste: use short cycle iterations (typically a week long) and frequent informal testing with real users to ensure we are building apps they want, and avoid spending time creating interim deliverables unless they produce obvious value for our client or our users.
  • Achieve quality through iteration: build the core experience of the app first, and then expand and polish the feature set from there, based on internal and external user feedback.
  • Work as a team: literally breaking down the silos between our disciplines, each of our project teams now works together cross-functionally in a collaborative workspace. The team owns and solves all project problems together, and each member of the team is accountable to the others for their work.
  • Collaborate with our client: we talk with our clients at least two to three times a week (or sometimes multiple times a day), sharing and seeking feedback and critique on designs and strategies that don’t yet feel finished. Our clients enjoy more visibility into our work, and we benefit by avoiding going down the wrong path for too long.
  • Build a shared understanding: working together and communicating proactively between specialists on a team creates a common understanding of the users’ needs and how the app will meet them, reducing the need for formal documentation.
  • Embrace change: by definition, this means that there is agreement that the real scope of the project isn’t knowable when we start it. By accepting this fact, we allow for the learnings and changes in priorities to occur naturally during the evolution of an app ultimately mold the final product.

As I said, Lean is a philosophy, not a process. Each team works hard to understand the particular needs of their client and their users, and then applies these principles to an approach that best fits the need of their particular project. Moving away from a rigid process has allowed us to complete deep, complex apps faster, on time and on budget, and with even higher quality than ever before.



Recent News

One of Bottle Rocket Apps' latest applications has given a fast-food bird some new wings.

Chick-fil-A's latest version of its mobile app, released last week for iOS, allows customers to order and pay via their smartphone. The app allows customers to use the new features at more than 130 locations, with more expected to roll out in 2015.

Read More