Archives

While a mobile app may do a lot of things, it’s essential to design the app so it feels simple to the user at any moment during its use. But how do you generate ideas that will make an app simple?

Try the following approach. List the top ten features you want in your app. These should be the most important things that characterize your app. If you have more than ten that’s OK, but try to come up with at least ten.

Once you have ten (or more) features listed, pick the top three. Now from the top three, pick the top one. Next, set a timer for 15 minutes. Draw some concepts of your app so it only does the top one feature. You may want to use index cards or pre-printed storyboard sheets to capture your ideas. After 15 minutes is up, reset the clock for another 15 minutes and create a new design that contains the top three features.

Obviously, you may do many variations on this exercise. Despite the details, the idea at work here is the same. By introducing constraints (number of features and time), the mind tends to be more focused and often more creative when generating ideas. When one feature is viewed as most important above all others, the design will favor that feature. By trying another feature as the top one, you will likely get different ideas.

Try this exercise on your own or challenge your team to come up with designs. Your time investment will be small but the outcome can be quite effective.

I gave a talk at the Chicago Product Management Association together with Pathfinder Software’s Amy Willis and Reid MacTavish on the lessons we’ve learned in integrating Lean Startup, User Experience Design and Agile Development. Here are the slides from the talk – a video recording will follow soon.

Read more »

Your desire is to make a great product. Or take an existing product to the next level. It’s great to have the intention, but how do you put that intention into motion?

Here is a simple exercise that you can try. Instead of thinking of the details of what might improve your product, simply consider your product as an “environment” or a place people go to get some kind of value. Try filling in the following sentences:

This is where people like to come to do ______________.
It’s way better than ______________ because of _______________.
Simply put, it’s the only place to go where you can ______________.

We can dissect these sentences and realize they are about thinking through differentiators, what makes the product competitive, etc. In narrative form, however, you are not just thinking of these items, you are also putting them in context of how they would sound to someone else. By using this “narrative” or mini elevator speech approach, you will likely find you are better able to come up with ideas that have an emotional tug.

Try emailing the sentences to your team and have everyone return a response. You can also use the exercise to kick off the beginning of a meeting or a brainstorming session.

Lean UX can work very effectively when designing complex products, including products that demand a heavy amount of science, complex workflows or handshaking between components. In this article, we’ll explore why Lean UX methods are effective.

What is Lean UX?

Three things come to mind when describing Lean UX. First, using very rapid (and usually low fidelity) iterations to get the user experience focused on the most critical and core features of the product. Second, using quick (and once again low fidelity) user tests to see if the product is resonating with the target audience. Third, engaging the product team to participate in these activities as opposed to the designer working solo.

Why Rapid Iterations Work

For complex products, rapid iterations are very effective even though they go against the grain of common sense. It seems logical that to problem-solve and design something complex, you inherently need a lot of time. However, by using rapid iterations, especially “time-boxed” workshops of an hour or two, you are requiring the team to focus and deliver the task at hand whether it be a task analysis, workflow design, visualization or a small prototype. People literally think differently when they have less time to wander and must focus on the task at hand. The workshop environment also makes it easier to get a variety of experts contributing to a single solution. One piece of advice, though, keep your workshops focused on a specific design goal. For the next goal, schedule another workshop.

Another reason rapid iterations work is you can do more of them. Think of a plane flying from LA to Hawaii. Say you allowed the plane to make three course corrections on the journey as opposed to thirty or three hundred. Being able to make more small adjustments is simply a better way way to reach a goal, especially when you are trying to isolate and design the critical and core aspects of a complex product. This can’t be accomplished with a few “big” iterations. With big iterations, you have no margin for error, which contradicts the nature of discovery processes that require experiencing what works as well as what doesn’t.

Why Testing Doesn’t Have to Be Formal

Sometimes the best test is the free and immediate one. Just showing a design to whoever is nearby can lead to valuable feedback. As with iterations, doing more informal tests is preferable to doing a few big ones. When you test quickly, there is less invested in the design and therefore more resources for refinement. With remote meeting and screen sharing capabilities, it is easy to set up informal tests with real users even if you can not be in the same room.

Why Design by Team is Not Design by Committee

Complex products demand critical and creative thinking from a variety of experts. When designing workflows, product visualizations and core concepts, it’s essential to get the team involved. Sometimes people react to this with the concern “Isn’t this design by committee?” It definitely is not. Design by committee is what happens when individual objectives and feature desires derail the user experience. Team design is about engaging a variety of experts around a specific and agreed upon set of objectives with the sole purpose of creating the best user experience possible for the user.

Teamwork is essential because it enables essential critical thinking to take place early in the design process. This mitigates two common problems. First, the problem that an expert isn’t talked to until it is too late to act on the new information. Second, the problem of discovering late in the process something that absorbed a lot of time is not very important.

Give Lean UX a Try

Lean UX can work for complex product design. With rapid iterations and increased teamwork, you will likely find your design process moves more quickly than you thought possible and your team is more engaged. You have nothing to lose and everything to gain by trying Lean UX methods.

February has been a busy month for Pathfinder around Chicago!

There was a feature in Technori on Pathfinder Founder and CEO Bernhard Kappe last week.

There was an interview with Pathfinder VP of Product Development at midVentures.

On Tuesday, Bernhard and Todd Wyder, Pathfinder’s Chief Product Office, spoke at Morningstar on Turbocharging Your Mobile App Sales.

And this evening, Michael Walkden will be talking about Incorporating UXD into an Agile Project Inception as part of the midVentures monthly: DESIGN+DEVELOP series.

Mobile apps need to be designed and tested to scale to avoid surprises when actual human hands start operating the app. Designs crafted or presented on large monitors can be deceiving, because it’s hard to think in terms of two scales at the same time. Better to work at scale, and if possible even view key screens and simple prototypes on the device itself.

Following are some simple techniques for designing and testing with scale prototypes.

Index Card Prototypes
For a mobile smart phone app, a stack of 3×5 index cards will roughly approximate the size of the device. Screen concepts can be sketched on the cards and a walk though demo can quickly be assembled. While this kind of demo is rough, the time to create it is minimal and the resulting card stack can be used for informal usability tests.

When sketching a prototype, try several ways of organizing the content to keep the screens simple. Finding the right organizing approach should make the design of the supporting parts easier, so it pays to try as many ideas as you can think of to get an optimal one. Spend minutes, not hours, on your initial concepts.

To-Scale Storyboards
Another effective and simple prototyping technique is to make to-scale blank storyboard screens that represent the footprint of your device. Be sure you represent physical size correctly, so when you print the blank storyboard pages your screens are true to your device size. Storyboards are particularly useful for illustrating ideas of how an app can flow, or what a key usage scenario might look like.

On-device Sample Screens
Sample screen mock-ups and even sketches can often be best reviewed if you display them on the actual device. This doesn’t require a lot of code or even any code. Graphics images produced to-scale could be loaded onto the device in an application or prototyping program with minimal functionality that just displays the images.

On-Device Prototypes
The most reliable way to test a touch prototype is to get some actual functionality running on the target device. Of course, this is also the most expensive way to test but it can be worth the effort. This is especially true for testing the feel of the app, because the feel will depend on several things working together, including how the device is held (or positioned), the ease of seeing where things are at on the screen, the ease of locating interactive elements, the expected behavior of the app vs. the actual behavior and the responsiveness of the device to actual gestures.

To reach a compromise between the cost and value of such a test, it is usually best to focus on one or two key aspects of the feel and plan to do a few iterations of the test. The ability to re-iterate a test after doing some refinements can lead to much more valuable findings than a simple one-shot test.

It is amazing how much one company has influenced our digital lives. You can not seem to look at any “smartphone” today without seeing Apple’s influential design sprinkled in. Need proof? Take a look at the Android prototype before the iPhone came out. Now look at Android today.

Does Apple get everything right? Heck no, but they have been setting the interaction trends for the last several years. This can especially be noticed when you are developing for iOS. If you have ever released an app to the iTunes store and not followed the standard interactions Apple places in its apps, then you know what it is like to get negative reviews from users on seemingly trivial interactions that ultimately still get the job done.

As a designer, interaction patterns matter because subconsciously they matter to users. Users like to understand things instantly without relearning how the same task is done. A user who has learned how to delete an email in one app does not want to have to learn a new set  of gestures or buttons to delete a video in an editing app.

Sometimes even interaction patterns that can be improved on, but are consistently implemented across other apps, are considered right just because so many users understand them from repetition. Apple thought of this and is kind enough to provide a designer/developer with a set of iOS Human Interface Guidelines (HIG). But when you are designing and developing the next killer app, how do you know when to follow the guidelines or not?

There can be many reasons to design an interface differently than the HIG but the “good” reasons are limited.

1. It is an interaction or app that is innovative and thus is not covered by the HIG’s limited set of interactions, controllers, and controls.

You are really not breaking the HIG in this situation, so there is no question its your opportunity to innovate. Have fun, young Jeff Raskin.

2. You are designing to differentiate your application from the rest in the App Store.

This is a bit tricker, as the interaction had better be very powerful and memorable to break the mental model users have learned from all the other apps. In this case its often better to just stylize your design but keep the controls and interactions in line with the HIG. This way users understand how your app works but remember your design as being different and/or fun.

3. You have a limited budget and you can build your non-standard design quicker than what is in the HIG.

This is a dangerous path that many fall into, but rarely does it work out well (although there are exceptions). If you are a bigger company with a hot established brand you may find you can get away with this allot more often than the little guys. More often than not, user reviews, Gruber, and general market confusion often force this designer to go back and rework the app to match the HIG and thus it ends up costing more in the long run.

In general, remember the HIG is your friend and can save you design effort and research, giving you time to focus on what makes your app unique and insanely great. I look forward to paying you $0.99 for making my life easier. Now if Apple would just give me a way to add another 200 app screens to my iPhone…

Feel Can Make or Break a Product
Imagine you are shopping for a new car. You found a model that looks great and has all the features you want. It’s even in your price range. So you go to the dealer and take a test drive. After about five minutes of driving, you find you are mildly dissatisfied with the car. Perhaps it’s the way it takes the bumps. Perhaps it’s difficult to check your blind spot. Perhaps the pedals and buttons are not responsive. Do you buy the car anyway? After all, you like the look, it’s a good buy and it’s got the features you want.  Odds are though you are not going to buy it. Why? Because you don’t like the feel of it, and the majority of your experience with a car is tied to the feel.

Feel Plays a Key role in Mobile App Satisfaction
Since mobile devices are held in our hands and operated with touch, the feel of the experience becomes a key determinant of user satisfaction. Also, since the screens are small, more interaction is generally required than on desktop devices. So we experience the nuances of the feel again and again as we use an app. Mild annoyances can add up, let alone major ones. Conversely, a good feel will create an ongoing sense of ease and comfort. This makes it more likely the app will be used repeatedly, bubble up on users’ favorites list, be talked about and recommended to others.

Seven Questions to Ask When Designing the Feel of Your App
So are you ready to optimize the feel of your mobile app? To help, here is a list of questions worth asking when designing a mobile app to make sure you have addressed the feel:

1. Have you anticipated how the user will hold the device?
2. Have you designed for operation using fingers, thumbs or a combination of the two?
3. Have you eliminated undesirable “eclipsing” effects, that is, uncomfortable blind spots where the finger obscures what is being touched in such a way that the interaction is awkward
4. On screens with a dense amount of content, have you kept the structure of the layout and interactions simple?
5. Have you used an intuitive sequence of gestures to perform core tasks?
6. Have you minimized user effort to see, locate and interact with elements on the screen?
7. Have you asked someone (or several people) to try a prototype of your app on an actual device?

Check your design against the above items, and you will find the improvements you make to the feel of your app to be well worth the effort.

photo credit: Robert Bejil Photography

Those who are out there designing and building mobile apps know there are certain tenants that are uniquely mobile. Successful mobile apps need to be user task centered, make allowances for users who are distracted and they need to be engaging. This requires considerable skill and effort from a designer. In addition, you will need a team of developers who can make the design real. The problem is that most mobile app development budgets are lean or unrealistic. This isn’t likely to change soon.  Here is a list of things we do that help us work within these constraints:

• Focus on communication as well as lean documentation - Even better, have everybody sit at the same table

• Before you start each feature, scrutinize: Does the user really want to do this task on a mobile app? Does everyone fully understand the feature they are being asked to build? Is there a simpler way to do it? – If you can cut the size, you get to launch sooner
• Make sure everybody on the team knows the User Interface Guidelines/Human Interface Guidelines/User Experience Interaction Guidelines for the platform they are building on – Its like having a second designer helping out
• Track your progress.  Is your expected launch date still realistic? If not, adjust expectations – Working 16 hour days doesn’t build creative, productive teams
• Doubly focus on communication – When you are moving fast its really easy to sprint off in opposite directions
• Ask: Does everybody like the app? - Periodically step back and look at the big picture
• Do you have the right team?  - A small group of highly motivated people often get better results than a cast of hundreds
• Is it clearly, unambiguously, defined when each feature (and the overall app) is done and ready for launch? – I’ll know it when I see it normally means you aren’t going to be launching in the near future

Do you want to launch a successful mobile application?

Find out about the Fastest path to launch a mobile business.

photo credit: the_moog

We develop digital products. Lots of them. So when I talk about things that are hard or easy to do, it’s based on hard won experience.

Two products that we’re about to help clients launch provide a perfect contrast on the two kinds of “hard” you find in software product development.

First we have a data visualization app that cranks through 72 million point datasets and cranks out 72 vector graphics surfaces, each with some 6000 curves comprised of a quarter million points. This is then displayed in real time to an expert audience of specialists via a highly responsive interface. We’ll call this one “dataviz.”

Second, we have a healthcare application that allows healthcare professionals to conduct a guided interview with a patient, both capturing information and educating them via feedback. We’ll call this one “interview.”