Chicago Web Conf 2012

Chicago Web Conf 2012
Chicago Web Conf 2012

I presenting a talk yesterday at Chicago Web Conf 2012 on A/B Testing Your Designs With Real Users, focusing on the role of A/B in digital product development.

I showed at a high level how we use the A/B testing solution Optimizely where I work at Cars.com to test our designs in ways that are quantitatively measurable. Like other A/B test solutions, Optimizely allows you to quickly create and implement tests and start collecting data immediately.

In addition to showing some examples of our tests and results, I also tried to show how A/B testing can fit into a company’s larger user experience testing strategy. My goal was to leave attendees with five key takeaways regarding A/B testing:

  • It’s not a replacement for testing with individuals.
  • Small changes can lead to big improvements.
  • It takes little effort to test those changes once a solution is in place.
  • This kind of testing can take some of the team friction out of the design process.
  • It can help you get better solutions to market faster.

My slides are available (PDF format).

Jared Spool’s Prototype Camp Chicago 2012 Keynote

Jared Spool gave the keynote talk on the power of prototyping at yesterday’s Prototype Camp Chicago 2012. Here are my notes:

  • Prototyping is not just about designing products, it’s really about exploring the problems you are trying to solve.
  • When you are making products you have to focus first on the problems you are trying to solve, not on what you are building.
  • Prototypes are key elements in creating a shared understanding of what problems you are trying to solve and what you can build to solve them.
  • Prototypes are a great way to expose the differences between the vision of the perfect product that is in the designer’s head and what your team can actually build.
  • The best architects, the ones who can walk into a building and say “This is exactly as I envisioned it”, are the ones who were involved with the project throughout the journey and making changes to their designs along the way.
  • The trick to planning iterative prototyping is knowing what you are going to measure. You have to start there and then design the prototype to ensure you get those measurements.
  • The key to iterative prototyping is moving fast. Design, test, learn, change, repeat.
  • With paper prototyping you get to change the design between every test as you learn about pitfalls in the design.
  • Sketching is prototyping. It allows you to explore designs before building anything.
  • You may never make the products you prototype, but in testing them you will learn things that will influence and improve other products you build.

Prototype Camp Chicago 2012

Prototype Camp Chicago 2012
Prototype Camp Chicago 2012

I’ll be presenting a session today at Prototype Camp Chicago 2012 on mobile prototyping with Axure RP. It will be my first conference presentation and a great opportunity to share what I’ve learned about mobile prototyping with the local UX community. I also hope to learn a lot from the many smart folks who will be there sharing their knowledge.

My demonstration Axure file for the presentation is available. It was created with Axure 6.5. Consider it yours and use it as you see fit. I hope it helps you in your growth as a mobile prototyper and Axure user.

For more information on mobile prototyping with Axure, see my recent article on Smashing Magazine, in which I walk through building this demo step by step. There are links to free and paid interface widget libraries, training resources, and some great books on prototyping you should read.

I plan to demo my prototype using the Xcode iPhone Simulator on my MacBook Pro. You can save yourself some time when first building your prototype by using the simulator so you don’t have to keep reaching for your iPhone. Just download Xcode from the Mac App Store (it’s free). To run the simulator as a standalone app without ever launching Xcode, just enter the command in this file in Terminal and it will create a shortcut to the simulator in your Applications folder. You will need to test on the device as you get further along in building more complex Axure functions into your prototype, but this is a nice way to get started when creating the basic framework and navigation for your project.

Happy prototyping!

The Value of Flexible Prototyping

I recently experienced firsthand the power of flexible prototyping — and it is powerful.

I was doing in-lab, moderated usability testing of a mobile website experience and had reached that point where after a few participants you know you have a problem and the team wants to test a new solution. Our team’s visual designer — also a rock star front-end coder — offered to cook up a new prototype mixing the UI elements from the current site that tested well with participants with some design elements from our prototype that also seemed to be testing well.

The prototype in question was coded in HTML5 and jQuery, running on iPhones and Androids off Dropbox. After about 30 minutes, he came back to the observation room to say the new prototype was ready to go.

Because we were at the last test session of the day, we could only test the new design with one participant, so we certainly couldn’t say it was a design success. But it did eliminate the stumbling block we kept running into.

Perhaps more importantly, the experience reminded the team of the power of lightweight flexible prototypes that can be changed and deployed very quickly. Our approach to future test planning will be focusing on how we can change the prototype mid-test, which should open the door to a more adaptive approach to user research.

Cars.com Agile Transformation Webinar Notes

I participated in my first webinar recently, sharing some learnings from the Cars.com agile transformation. The webinar was sponsored by consulting firm ThrivingOrg and focused on what we learned during a 10-week series of pilot projects undertaken by several product teams. Here are some notes I prepared:

  • Transition from waterfall to agile was difficult at first for user experience team members because most of the techniques used by classically trained user experience people came from the waterfall world. Things like wireframes, a fully designed user experience and flow, and pixel perfect Photoshop comps don’t work well within the context of two-week working sprints.
  • Our profession needs to get better at using Lean UX approaches and shifting our work product to sketches, prototypes that can be used for documentation and user testing, and more lightweight guerrilla usability testing.
  • Interactions between agile product team members are very different than in waterfall project teams. Developers and UX people are working much more closely and more often now (and that’s a good thing).
  • Dedicated team co-location is essential. Having the product manager, UX and visual designers, and developers and testers near each other fosters frequent informal collaboration and reduces the number of structured meetings you need.
  • Daily standup meetings and co-location should drive greater appreciation of the other roles on the team and the constraints they are working under.
  • Failing is good. It shows you your limits and helps teach that an agile product team rises or falls together.
  • When first transitioning to agile, start with easier to implement features or even a backlog of defects. This allows the team to learn the process first without also having to worry about designing and developing complex functionality.

If you are new to agile software development and Lean UX, these resources can get you started:

Cars.com Agile Transformation Webinar Series

Cars.com product development team members recently took part in a series of three webinars sponsored by ThrivingOrg in which we discussed the different phases of our on-going transformation from waterfall to agile software development methodologies. The three webinars focused on three different phases of our journey, which is still under way.

I took part in the Phase II webinar, in which we discussed how we implemented a set of pilot projects to help us define an agile framework that would work for Cars.com. The pilots lasted several months and helped inform how we approached the later transition of all software development to the first iteration of our agile framework. An audio recording of the webinar is available through the ThrivingOrg website.

Jared Spool’s UX Immersion 2012 Keynote

This week I attended the UX Immersion 2012 conference. Jared Spool’s keynote addressed why it’s a great time to be a designer. Here are my notes:

It’s a Great Time for Extraordinary Design

  • More than ever companies are realizing that a well-designed product or user experience is essential to business success.
  • Experience design is more mission critical than ever before.
  • Products like Apple’s iPhone and iPad have raised consumers’ expectations for what makes a great product.

Stages on the Road to a Great Product

  • When something first comes out it is often clunky, but people will buy it because it is new.
  • Then features are added and it’s a race to see who can have the most features.
  • Then a concern for the user experience comes along and you strip away a lot of features.

Bad Products Create More Frustration

  • Lost sales and revenue.
  • Increased support costs.
  • You waste time building things no one uses. No designer wants to do that.

To Sell Great Design You Need to Know How to Talk to Executives

  • Executive have their own language.
  • Five things executives care about: sell more stuff, decrease costs, increase market share, increase business from exist customers, and increase shareholder value.
  • If you want to sell an executive on the need for great design, you have to speak their language.

Examples of Great Design

  • Walgreens scan-to-refill pharmacy app.
  • Zipcar — User friendly solution to a vexing problem for city dwellers.
  • Cirque du Soleil uses beautiful design and is better than anything else out there.
  • Umbrella Today. It answers one simple question: Do I need to take an umbrella with me today?

Disney vs. Six Flags

  • The map at a Six Flags park shows how you get from ride, to ride, to ride.
  • The map at Disney World creates a sense of adventure. It shows almost no rides. Imagine being a kid stepping into that.
  • At Disney World you don’t stay in a hotel room, you stay in a resort. And when you come back the housekeeper has folded your towels into origami animals.
  • Disney pays more per housekeeper for one who can fold origami animals. And they clean fewer rooms. Can you imagine being the person to pitch that idea?
  • Six Flags = Activities, Disney = Experience. Experience is the activities plus the gaps in between.
  • The origami animal towels were started by one housekeeper on one cruise ship. No one asked them to do it. That’s often where the best design ideas come from.

How Mobile and Agile Can Help Us Redesign the UX Process

  • Agile is opportunity to redesign how we create and think about user experiences.
  • The restricted nature of a mobile device’s screen forces us to focus on the experience.
  • Mobile is an incredibly powerful wedge we can force into the business to focus them on creating great user experience.

The Making of an Extraordinary Designer

  • At every step ask yourself “are we getting closer to a better user experience?”.
  • Ask yourself “is this what a customer will pay for?”.
  • Great designers know they have to get something out quick and learn from it.
  • The extraordinary designer knows how to deliver great experiences. You strip the product down to only those features people will really use.
  • Example: In 2007 Nokia had 140 phones with lots of features. Apple had one. We all know how that worked out.
  • Great designers know that more features + more complexity = feature rot. And the user experience rots.

On Great Design Teams

  • Good judgement comes from experience, and experience comes from bad judgement. You have to give great design teams the time to fail and learn.
  • Everyone on the team needs to share the vision. Get great design embedded in your culture.

Jared Spool is the founder of User Interface Engineering. You can follow him on Twitter at @jmspool

Jeff Gothelf on Lean UX

This week I attended the UX Immersion 2012 conference. Jeff Gothelf’s featured talk looked at Lean UX and how he used it at The Ladders. Here are my notes:

On Lean UX

  • When converting from Waterfall Development to Lean UX, a great place to start is to look for stories of failure. You learn what didn’t work.
  • Lean UX doesn’t seek to answer the question “can we build this?”, but instead asks “should we build this?”.
  • Usability testing with three users helps you find the boulders, not every little flaw. Subsequent iterations can find problems in the smaller details.
  • Style guides and pattern libraries let you work faster. You have all the tools you need to solve problems. If it has pixels, it goes in the library.
  • Live style guides is a concept in which the HTML markup and CSS is attached to the product in a way that a change to the style guide changes the product.

Learnings From the Agile Transformation at The Ladders

  • UX as a shared services didn’t work because it divided people’s focus.
  • You have to put UX designers on a dedicated team to build camaraderie, focus, and trust.
  • If a UX designer must be split across two teams, make sure they have a primary team so they can prioritize work appropriately.
  • Putting a UX designer on more than two teams is a recipe for failure.
  • Solve the problem together, not in silos. Co-creation builds understanding.
  • Sketch together as a team, then everyone “owns” the solution.
  • The Ladders had many iterations on what was the right way to manage the task wall. We learned that if you cram your entire functional spec onto a board, it’s not agile.

What Lean UX Means for Designers

  • No one gets into user experience to create documents. They want to make things.
  • In fast-paced agile environments the traditional UX approach becomes a bottle neck. We need to use new tools to achieve our goals.
  • Create the lowest fidelity document possible to explain and validate whether the concept in your head is the right thing to do.
  • Don’t be afraid to sketch. All you need is a circle, a rectangle, and a triangle. This covers every interface out there.
  • Get the experience out there, not the design document. Get it in the wild to validate the concept.
  • You’ll never solve a problem with a design document, you solve them with software.
  • Unless you are building the product for yourself, your design is just a hypothesis.
  • Work in a tight integration with the rest of your product team. Designers can’t hide behind their monitors any more.
  • Pair up — Put designers together with developers when problem solving and brainstorming.
  • Pairing up also helps you build an understanding of each other’s work and limitations.

Jeff Gothelf is the author of a forthcoming book on Lean UX. You can follow him on Twitter at @jboogie

Luke Wroblewski on Mobile Inputs

This week I attended Luke Wroblewski’s day-long workshop on Mobile Inputs at the UX Immersion 2012 conference. Here are my notes:

Mobile Input Controls

  • New mobile inputs are not just disruptive — They introduce completely new ways of doing things and totally new things to do.
  • Some designers will tell you not to use text inputs because people won’t type on a smartphone, but people send 4 billion SMS messages every day.
  • When people have something they want or need to do on their smartphone they will use text inputs if they have no other choice.
  • That said, avoid having people type any time you can, but don’t avoid text inputs when you can’t. Always encourage input, don’t limit it.
  • Think of people as one eyeball and one thumb when you design. Their partial attention requires a very focused design.
  • Think of a smartphone as a content creation device, not just a media consumption device. The most popular apps are content creation apps — Facebook, Twitter, Instagram, Draw Something.
  • Try to use the standard input types for mobile websites because they have been optimized for the operating system.
  • When you use standard input types, good things happen, because people already know how to use them. But don’t be afraid to go beyond the standard ones.
  • Try not to use select menus in Android if contents are longer than the screen because people may think their choice is limited to what is on the screen.
  • Try non-standard input types when there are too many taps, like the four required to use the select menu picker in iOS.
  • A stepper is easier than a picker if you have a small range (3 to 5) of numeric choices.
  • Only present input controls when people actually need them. Use progressive disclosure. Don’t hit them with everything up front in a long form.

Touch Target Size

  • Design for a physical size, not a pixel size, due to differences in screen resolution and pixel density. Apple, Android, and Microsoft have extensive documentation and recommendations.
  • Use a minimum spacing between tappable objects as recommended by the operating system developer.
  • Studies show that 80% to 90% of people are right handed, and that about 50% of left-handed people use their right hand to for their phone. Most apps can get away with being designed for right-handed users.

How to Make Input Less Error Prone

  • Use the correct keyboard version for email addresses, URLs, and numeric values like zip codes and credit card numbers. For mobile web this is supported by HTML5 input types.
  • Turn off auto-capitalize and auto-correct for login screens.
  • Use input masks to change people’s input to the correct format. For email addresses, use an input mask that puts @yourdomain.com at the end of whatever the user types and show the person this is what is happening.
  • Use smart defaults (for example, the no tax checkbox is selected by default on eBay mobile).
  • Top align field labels because of field zoom.
  • Don’t remove critical features, like password recovery, from a login screen.
  • Consider just showing the password instead of masking it as asterisks, or show it by default and give the user the option to hide it.
  • Apply the concept of “touch first” and only go to the keyboard when there is no other way to collect the information.

Mobile Web vs. Native Apps

  • It’s not about which is better, it’s about what’s right for the use context and business goals.
  • A mobile website has near universal reach; a native app is a much more richer experience (although HTML5 and jQuery Mobile are changing that rapidly).
  • Designers working on the mobile web should look at apps for examples of controls you could try on mobile websites. The creators of Android and iOS built new operating systems from the ground up so they have had to think about making controls better.
  • Many device features like geolocation and access to a device’s compass are now available to web browsers through APIs. Even greater access to a device’s hardware features is coming in the future.
  • Facebook and Twitter get half of their content from mobile devices, and half of Facebook’s mobile content is from the mobile web.
  • The more app usage occurs, the more mobile web use occurs, and vice versa. They both drive each other.
  • The more people engage with a brand through the mobile web or apps, the more they engage with the desktop experience. Recognize they are all part of a holistic experience.

Mobile Web Advantages

  • Cross-platform reach and near universal access with one code case.
  • Faster development time because well-known web technologies like HTML, JavaScript, and CSS are used.
  • Larger developer pool available.
  • You can update your app at any time and don’t have to wait for Apple App Store review or for people to download the app to get the latest features.

Native App Advantages

  • Deeper hardware access.
  • Multi-tasking.
  • App sales and in app sales.
  • Integrated access with other locations like stores is easier (at least today).
  • Faster performance because much of the UI is already on the device.

Design From a Mobile Mindset

  • If you approach a checkout flow from a desktop perspective you’ll just get a shorter form.
  • If you approach it from a mobile mindset you’ll think about whether or not this person is in a physical store with a device that has a camera and can scan barcodes. Mobile devices can streamline the in-store checkout process.

Voice/Audio Input and Proximity Sensors

  • Android allows voice input to any form that allows text input.
  • Apple has Siri, and it is rumored Apple may open Siri APIs to programmers at the Worldwide Developers Conference in June.
  • Shazam and IntoNow use ambient sounds around a person as audio input.
  • If you put an iPhone next to your face during a call the proximity sensor hides the keypad so you don’t “cheek dial”.
  • With proximity sensors “every object in the world is now an input”.

Device Sensors for Input

  • Instapaper speeds up or slows down scrolling speed when you change the pitch of the device, allowing people read at their own pace without swiping.
  • Nearest Tube uses device motion, GPS, and the compass to show nearest London Underground station.
  • Google Goggles and FitBit are also examples of using hardware features as inputs.
  • The Android Galaxy Nexus, the first phone to come with Android 4.0 installed, uses facial recognition for its Face Unlock feature.
  • A proposed addition to the GetMediaUser API would open this to web browsers.
  • While Windows 8 is a desktop operating system, it allows people to create logins by logging custom gestures on lock screen images, for example drawing a line from a child to a pet on the picture. This is a very human solution to login problems. It’s like telling the computer “Hello, it’s me, let me in.”

Gestures for Input

  • Multiple finger gestures: two-finger drag moves an object, three-finger drag moves an entire pane in an app, four-finger drag moves the user between apps, and five-finger drag invokes operating system functions. However, these are emerging pattern, not universal rules.
  • Teach in context to help people learn how the app works when they need to know it, not in some large upfront tutorial (the Clear app does both).
  • Use content as navigation to remove as much chrome as possible.

Luke Wroblewski is the author of Mobile First. You can follow him on Twitter at @lukew

Mobile UX Design With Rachel Hinman

This week I attended Rachel Hinman’s day-long workshop on The Mobile Frontier at the UX Immersion 2012 conference. The conference, a new gathering arranged by User Interface Enginnering, featured deep dives on mobile and agile development. Here are my notes:

There are Many Similarities Between Mobile and Desktop UX Design

  • Many of the tools and techniques we use are the same.
  • We sketch.
  • We prototype.
  • We need to learn what our users need and want.

But There are Also Differences

  • A phone is not a computer.
  • There is no sense of having windows or UI depth.
  • There is a smaller screen for user input and new inputs based on context and device sensors.

How a UX Designer Transitions to the Mobile Mindset

  • Buy a device and integrate it into your life.
  • Know the medium and become mindful.
  • Participate in the experience.
  • Brace yourself for a fast and crazy ride.
  • This is an emergent area of user experience so nothing we do will be constant for long.
  • Embrace ambiguity, it’s fun and exciting.

Context is complex but is essential to great mobile experiences

  • The mobile context is about understanding the relations between people, places, and things.
  • Relationships between people, places, and things are spatial, temporal, social, and semantic.

Designing for Contexts

  • Design for inattention and interruption.
  • The mobile use experience is snorkling, the desktop user experience is scuba diving.
  • Reduce cognitive load at every step in the experience.
  • Ideate in the wild — you can’t innovate in mobile from behind your monitor.
  • Ruthlessly edit content and features down to what’s essential.

Sketching

  • It’s a good way to develop ruthless editing skills.
  • You can change a design quickly at little cost.
  • No expert skills needed.

Prototyping

  • The exercise helps designers new to mobile who do not yet know the heuristics and constraints of the medium.
  • It’s essential for mobile UX because the medium is so new.
  • If you are prototyping for a desktop app and a mobile app, allocate to mobile triple the amount of time you devout to the desktop.
  • Prototyping helps you fail early and fast.
  • Because a mobile experience is so contextual and personal, explore techniques like body storming and storyboarding.
  • Prototyping is a great way to fail when it matters (and costs) the least.
  • Desktop prototyping is a luxury, mobile prototyping is essential.

Graphical User Interface vs. Natural User Interface

  • We are at a pivotal moment in the design of user experiences — the NUI/GUI chasm.
  • A GUI features heavy chrome, icons, buttons, affordances; what you see is what you get.
  • A NUI features a little chrome as possible and is fluid so content can be the star.
  • As UX designers we need to work to eliminate chrome, not make the chrome beautiful.

Motion as a Design Element

  • Animations and transitions can teach users how the information unfolds (see Flipboard).
  • Motion brings fun to the party, and who doesn’t want to have fun.

Rachel Hinman is the author of the forthcoming The Mobile Frontier. You can follow her on Twitter at @hinman