Data Marries Design to Drive Customer Success in 2016 | UX Magazine


Big data and design have left their mark on various industries and business functions and now have their sights on customer experience. Data helps us uncover valuable opportunities worth solving, while design thinking guides us to a deeper understanding and more meaningful, user-centric solutions. In the year ahead, the marriage of data and design will offer powerful new ways for companies to build stronger customer relationships and drive growth.

Predictive Analytics Goes Mainstream

Large SaaS-based companies like Amazon have been reaping the benefits of big data and predictive analytics to drive business growth for years. For example, Amazon’s recommendations are powered not only by your past viewing and purchasing data but also by the data from thousands of other shoppers like you.

In 2016, we’ll see an expansion of analytics across two dimensions—across companies of all types—large and small, B2B and B2C, traditional software and SaaS—as well as beyond the traditional sales funnel and throughout the entire journey a customer has with their vendor.  This includes being able to predict likelihood of churn, increase customer references, identify up/cross-sell opportunities, and ultimately maximize a customer’s total lifetime value. Most importantly, it helps ensure that customers are receiving the most value and success possible.

Big data will help drive customer loyalty and business growth in 2016

I’ve seen the power of predictive analytics applied to various stages of the journey a customer has with their vendor. One example from a traditional software vendor is specific to the technical support stage of a customer’s journey. In this example, a model was developed using dozens of attributes that predict both individual support requests and entire customer accounts that are likely to become critical, and used this information to alert the appropriate teams to assist.

As a result, they saw significant reductions in the number of customers reaching this critical status and an increase in overall customer satisfaction. Other experiments centered on being able to predict which additional capabilities of a product already owned by a customer might prove valuable based on the experience of similar customers. The Head of Data Science at Citrix, Mike Stringer, captures it perfectly:

“Data Science has spread down the sales funnel and into the customer success funnel. Companies failing to capitalize are at a huge disadvantage in the Customer Success arena.”

However, many companies have yet to move beyond traditional sales funnel use cases—or to work with predictive analytics at all. There are three reasons why this is about to change.

  1. The ongoing shift to subscription-based models. The promise of shorter sales cycles with stable recurring revenue combined with the increase in demand for pay-as-you-go OpEx purchasing are driving many traditional software companies to the cloud or to subscription-based licensing. Adobe, Autodesk and Microsoft are just a few examples. And even those who aren’t embracing these new models are feeling the consumer pressure to show that they care about the post-sale customer experience as much as the pre-sale customer experience.
  2. The amazing surge of big data startups from the past few years. Now hitting their stride, these companies are making data science accessible and easy for companies of all sizes, and focusing on extremely valuable use cases—including customer success. Keep an eye on GainSight, Totango, and Preact, who have all have zeroed in on this extremely fast-growing market opportunity.
  3. The notable increase in the number of Chief Customer Officer, VP of Customer Success, and similar roles over the past two years. While these roles may have differences in operational responsibilities, they all share a similar set of performance metrics that are grounded in customer value and success. These leaders will look to predictive analytics to be successful in their role.

This is great news for businesses of all kinds. Practical and applicable big data has arrived. As it enters the fast-growing space known as Customer Success, it will bring amazing capabilities to drive customer loyalty and business growth.

But there is one caveat: Being able to predict the future doesn’t necessarily mean that you can intervene and change it. I was once told about an interesting pattern discovered during the 30-day trial period of a SaaS product.  Data scientists determined that if a customer used the product during week three of their trial period—regardless of their usage during weeks one, two or four—they were far more likely to convert into paying customers. The team celebrated these findings and began firing off email nurture campaigns that successfully increased week three usage. The impact on conversions: none.

The lesson we learned is well worth taking to heart: While data is amazing at correlating behavior and outcomes, it doesn’t uncover the underlying motivation. In this example, the teams never explored the “why” behind week three usage, and was thus unable to transform this information into true insight.

Predictive Data Meets Design

In my 2015 article in UX Magazine, Design Thinking and Lean Soup Isn’t Just for Start-Ups, I predicted that in 2015 we would see the approaches and philosophies I outlined adopted by companies of all sizes. My prediction was accurate, but to my surprise, the adoption of design thinking extended beyond large enterprise companies into sectors I hadn’t anticipated.

For example, in the financial industry, a series of design deals included Capital One’s acquisition of Adaptive Path in late 2014 followed by BBVA’s acquisition of Spring Studio in April of 2015. Industry giants also continue to invest heavily in design. IBM is on a mission, since 2012, to hire 1,000 designers, while GE opened a design studio in 2014 and is recruiting heavily in the field. Most surprisingly is the pattern of acquisition that continues in professional services firms, with Accenture’s acquisition of Fjordin 2013, and KPMG’s acquisition of Cynergy and BCG’s of Strategic & Creative in 2014. Last year, McKinsey and Wipro both jumped into the design game with acquisitions of Lunar and Designit.

Design is clearly here to stay—these professional services companies wouldn’t be investing if the demand didn’t support it. Now bring data into the picture and something even more powerful becomes possible. The best term I’ve seen applied to this is “hybrid insights,” which I first saw used in Tom and David Kelly’s book Creative Confidence. They write, “Hybrid insights allows us to embed stories in the data, bringing the data to life. It brings the ’why’ and the ’what’ together.”

In the “week three” example I shared earlier, only the “what” was provided by the data. It was not a hybrid insight. Because the “why” was never understood, they ended up following a path that had no affect on trial conversion rates. A hybrid approach blending the qualitative research and problem reframing strengths of design thinking could have sent the team down a very different and more successful path.

The blend of data and design is a match made in heaven for understanding and solving problems in a meaningful, user-centric way. Tony Costa summarized this well in a recent Forrester paper, “How CX Pros Innovate.”

“Big data won’t replace ethnography. Rather, it’ll complement it by revealing unknown insights, pushing researchers to pursue new avenues of investigation that were not viable before.”

As design thinking and now data science make their way more deeply into the fields of customer experience and customer success, companies who master these new approaches will pull away from the pack. Even companies lacking strong in-house data or design skills can benefit from this trend, as more and more customer experience-focused big data startups and professional services companies enter the field.

Image by Steve Silvas.

via Data Marries Design to Drive Customer Success in 2016 | UX Magazine.

7 things I learned working at a user-centred design agency — Interactive Mind — Medium


7 things I learned working at a user-centred design agency


At the end of November, I handed my MacBook back over to cxpartners and moved on to new pastures over at Hudl.

I’ve learned a huge amount during my time at cxpartners and achieved more than I ever thought I would by my mid-20s. The cxpartners approach to design is far removed from anything I’d ever experienced, so I had to adapt quickly, learning along the way that I was a young & foolish designer who had a bunch of assumptions that were wrong. Here are a few things that I have learned in my tenure at this wonderful agency.


Watching users is eye-opening

I thought my ideas of how people interact with interfaces were pretty advanced. I was wrong. I thought sketching out an idea for ages before producing it in a prototype would mean a user wouldn’t miss it. Guess what.

Watching users walk through your designs is nerve-wracking and eye-opening. You will spot glaring errors in your design in moments and, before you know it, post-its containing user insights will cover every wall.

It blew my mind how much hand-holding users require. I’ve seen users misunderstand propositions entirely, miss huge calls to action, and ignore clear, basic microcopy.

I’ve never left a user research session thinking ‘I have learned nothing today’. Seeing how much a user struggles to understand standalone icons, or how they totally ignore microcopy will stick in your mind and make you become a more empathetic designer.


Post-its and Sharpies. Everywhere.

Designers may be driving the stock prices of post-its through the roof. These yellow squares cover everything in the cxpartners office. There is so much joy in being able to scribble on a bit of paper and build a prioritised list of components in seconds.

This habit must’ve dripped down into my process because, for even the smallest project, I will make sure I have a stack of post-its at hand to start writing notes.


Kick-offs, communication, and stupid questions are essential

Before cxpartners I had taken part in briefing meetings, asked standard sets of questions, and produced designs that required multiple rounds of feedback before getting them right.

I had made the (daft) assumption that non-designers know exactly what it is they want. In reality, we are the experts and it is our responsibility to help the client understand what it is they really require. If we end up producing the wrong design, it’s our fault. If you visit a physiotherapist and tell them your knee hurts, it’s their responsibility to figure out that it is in fact your glute that is the problem.

To get a true, accurate brief from a client these days I ensure the following happens:

  • A 2–4 hour kick-off session with multiple stakeholders and a series of tasks to work out requirements, limitations, personal tastes, and more.
  • Constant client contact through feedback loops and questioning.
  • Always ask the stupid questions to make sure nothing is left ambiguous.

This kind of thing requires additional time up-front, but mean the projects run more efficiently so are often quicker overall.


Fast, collaborative iteration is the best ever.

My most recent projects have involved working closely with ux designers, developers, and the client, allowing us to quickly iterate and deliver designs that everyone was happy with.

What helps this is a massive dose of mutual respect. Each member of the team understood the value of the other members, but let everyone get stuck in. A dev wants to dig into my Sketch doc? Great! I have some input for a UXer on how a layout could flow nicer? They welcome the feedback.

Working this way is the future. No more waterfall projects. There is an overlap in each department at cxpartners, so we should treat it that way instead of throwing wireframes over the fence at designers, and throwing designs over the fence at developers.


Dribbble doesn’t matter. Clients and users do.

A few months after joining cx I deleted my Dribbble account and, along with it, my modest number of followers. Why? Because I was pandering to peers instead of designing what was appropriate for the project I was working on.

This realisation came when I was designing an icon for a project and I asked the Creative Director (Chris) if I could upload it to Dribbble. The conversation went a little like this:

Me: Can I upload this to Dribbble?
Chris: Sure, but why?
Me: I think it’ll look good.
Chris: Have you been designing that just so you can put it on Dribbble?
Me: …

Taking a step back, I realised the mistake I had made. I had been designing something that would look good in a 4:3 panel, and I had been doing this on most of my designs since I got a Dribbble account.

From this point on, I focused on client- and user-needs and my designs projects have been more successful as a result.


Nobody appreciates a lack of humility

When I was a bit younger, I thought my opinion on designs should be defended to the death. After all, I had put my heart and soul into this so I should fight my corner. But I shouldn’t have.

Getting direct feedback from users, clients, and a pool of talented designers at cx meant that I had to back down. Whilst I’m being paid for my expertise and I may have solid rationale, there is always a time and a place for accepting that what I’ve done may not be right just yet.


User experience is deeper than layout

I didn’t really know what ‘UX’ as an umbrella term meant when I joined cx, and I’m not sure I really do now. What I do know is it’s more than sticking ‘UX’ in a Dribbble or Twitter biography.

User experience design goes deeper into user research, ethnography, information architecture, experience mapping, and much more. It isn’t just about layout. UX is an umbrella term that covers many specialist roles, most of which should never ever be ignored or underestimated.


Finally, I want to say thank you to cxpartners for giving me the opportunity to become a better designer. You should go and work for them.

Motion with Meaning: Semantic Animation in Interface Design · An A List Apart Article


danapavlichko-tobiasbernardaminalhazwani_960_440_81

by ,
January 19, 2016

Animation is fast becoming an essential part of interface design, and it’s easy to see why. It gives us a whole new dimension to play with—time. This creates opportunities to make our interfaces better at every level: it can make them easier to understand, more pleasant to use, and nicer to look at.

For example, animation can help offload some of the work (PDF) of processing interface changes from our brains to the screen. It can also be used to explain the meaning and relationships of interface elements, and even teach users how to do things—all without making an interface more complex.

Sometimes all of these factors converge: when you minimize a window, would you be able to tell where it goes without the animation? How much longer would it take you to find the minimized window in the dock?

Hard cuts make it difficult to understand state changes, because changing the entire page means you have torescan the entire thing to see what changed.

So far, so uncontroversial, right? Animation is a good thingwhen done well, at least. But there’s one aspect of animation that nobody ever seems to talk about. Some animation, while technically well executed, makes interfaces more confusing instead of less.

Consider the following process:

When we tap the Overcast app icon on the homescreen, the icon zooms and morphs into the app. The other icons stay in place. They’re still in their initial positions, laid out in a grid around the open app.

We start multitasking. The app zooms out. We should get back to the icons around the app on the homescreen, but instead we see a stack of other apps. Why is the icon above the app now? Where are all the other icons? And why does another homescreen appear next to the apps?

The app is both inside its icon on the homescreen and next to the homescreen. The two animations give us conflicting information about where the homescreen and the apps are located in space.

Diagram showing the multitasking workflow

The two zooming animations have completely different effects in this case.

These animations might make sense if you designed the individual screens in a vacuum. It’s only when they all try to play together as parts of a single experience that things get confusing. The problem isn’t with any of the individual transitions, but with the fact that the animations contradict each other.

History

How did we get here? Let’s take a step back and quickly review the history leading up to this point.

Since their inception in the 1970s, graphical user interfaces were basically a series of static screens (PDF) linked together without any transitions. Every state change was a hard cut.

Although there are some notable early examples of good interface animation that dateall the way back to the original Macintosh (PDF), because of the limited graphical capabilities of computers back then, effective animation was the exception rather than the rule.

Example of a remarkably fluid animation in an early version of Mac OS.

As computers got increasingly powerful, animation started to be used more frequently for things like maximizing windows or opening new tabs. It was still mostly pressed into service for small things, though, and rarely influenced the overall structure of interfaces.

Only now are we starting to get to a point where computing resources aren’t holding interfaces back anymore. With today’s devices, everything can be animated—and increasingly everything is. The problem is that the design process hasn’t caught up to this change in technology. For the most part, interfaces are still conceived as separate, static screens and then linked together with relatively crude animations.

This is probably how our multitasking example came to be; different parts of the experience were designed separately and then linked together without considering either the relationships between them or the consequences of arranging them this way. The problem is that if animation (and therefore the spatial structure of an interface) is an afterthought, it’s all too easy to create contradictory behaviors.

Now that we’ve figured out how we got here, let’s think about how we can avoid such pitfalls.

A simple shift

Adding animation to interfaces fundamentally changes them, and necessitates a new way of thinking. We call this new approach semantic animation. It all starts with a simple conceptual shift:

You can’t treat individual screens as separate entities if the transitions between them are animated. To the user, the entire experience is one continuous space.

Similarly, two representations of the same element on different screens can’t be seen as separate from each other. To the user, there is only one element—it simply changes form.

This means that when you add animations, an interface isn’t a series of screens anymore, but a collection of semantic components inside a single, continuous space. These self-contained components enclose everything associated with them, like meta information or interactive controls.

Example of how a post on Dribbble could work as a semantic component. The post always remains one cohesive element; it simply changes its representation over time.

This may sound complicated, but in practice it’s actually quite simple: instead of designing screens and then adding transitions between them, start by designing individual components and thinking about how they change and move in different contexts. With that in place, layout and animations will come together naturally, following the semantic structure of the content.

Explain relationships between elements

Animations are most useful when they reflect and reinforce the semantic relationshipsbetween elements: for example, “this comment belongs to this article,” or “these menu items are part of this menu.”

Think of every element of your interface as a single, self-sufficient component with a specific meaning, state, and position in space. Then make sure your animations reflect this. If a popover belongs to a button, it shouldn’t just fade in; it should emerge from that button. When opening an email, the full message should not just slide in from the side, but come from within the preview.

You get the idea, right? Once you’re used to this way of thinking, it almost becomes second nature.

The dialogs on Meteor Toys are a great example of semantic components.

The following examples show two completely different approaches to the same problem: one is screen-based; the other takes semantic animation into account. When opening Launchpad on OS X, the app icons just fade in and the background is blurred. This doesn’t tell the user anything about where the icons come from and what their relationship is with other parts of the interface.

OS X Launchpad.

The app drawer in GNOME (a desktop environment for GNU/Linux), on the other hand, uses an animation that elegantly explains where the icons come from and where they are when they’re not visible.

GNOME application launcher.

MULTIPLE REPRESENTATIONS

A common problem to look out for is different representations of a single element that are visible at the same time. This is bad, because it doesn’t make sense from the user’s point of view to see the same thing in more than one place simultaneously.

In the following example from Google’s Material Design Guidelines, when you tap on an image in a list view, a bigger version of the image is shown. The bigger version slides in from the right on a separate layer. This is a textbook case of multiple representations: there’s no connection between the two images.

Why is the image both in the list view and on that other screen? Are all of the big versions of the images stacked to the right?

Google recently changed this example in their guidelines. Here’s the updated version:

The new example is better because there are no multiple representations, but the animation fails to account for the interface elements on top, which change with no animation at all.

Now, here’s an instance of something that checks all the boxes: Facebook Paper’s timeline makes the relationship between thumbnail and detail view completely obvious. No multiple representations, no semantic loose ends. The transition is so smooth that you barely notice the state change.

See how the interface elements on the bottom of the detail view come from within the image? The image is a self-sufficient component, containing all of the information and actions associated with it.

Another example of how to do this well is Apple’s Passbook app. It may seem unremarkable at first, but imagine if it behaved like the first Material example, with the full cards sliding in from the right when you tap a list item. That would be ridiculous, wouldn’t it?

The transition between list and detail view is so fluid that you don’t really think of it as a transition; the elements just naturally move in space. This is semantic animation at its best.

Keep space consistent

Animations create expectations about where the animated elements are in space. For example, if a sidebar slides out to the left, you intuitively know that it’s somewhere left of the visible elements. Thus, when it comes back into view, you expect it to come in from the left, where you last saw it. How would you feel if it came back in from the right?

Lest they break the space established by earlier animations, animations should not communicate contradicting information. Our earlier iOS multitasking example shows exactly why this is problematic: two different transitions tell the user conflicting things, completely breaking their mental model of the interface.

Interestingly, OS X does something similar, but handles it in a spatially consistent way. When you full-screen a window, it scales to fill the entire screen, similar to iOS. However, it also moves horizontally to a new workspace. The window isn’t inside the first workspace anymore; spatial consistency is thus preserved.

Remember: violating spatial consistency is the user interface equivalent of an M.C. Escher painting. So unless your app is Monument Valley, please make sure to keep your space simple and non-contradictory.

Practical considerations

Right now you may be thinking, “But wait—there’s no way to apply this to everything!” And yeah, you’re probably right.

If you did manage to do that, you’d end up with something like a single, zoomable surface containing every possible state of the system. And although that’s an interesting idea, “pure” zoomable user interfaces tend to be problematic in practice, because they’re hard to navigate if they go beyond a certain level of complexity (PDF).

When designing real products, semantic animation needs to be balanced with other considerations like user experience and performance. Most of your interfaces are probably never going to be 100 percent correct from a semantic-animation perspective, but that’s okay. Semantic animation is a way of thinking. Once you’ve adopted it, you’ll be surprised how many things it applies to, and how much low-hanging fruit is out there. It forces you to think about hierarchy and semantics, which helps you find simpler solutions that make more sense to the people who use your products.

Note that we, the authors, are far from having figured all of this out yet. Our article doesn’t touch on many important questions (which we’re still exploring) related to the consequences of animating interfaces. Nevertheless, we’re convinced that semantic animation is a promising idea with real potential for making digital interfaces more intuitive and comprehensible.

About the Authors

via Motion with Meaning: Semantic Animation in Interface Design · An A List Apart Article.

What Does It Mean To Be Simple


All designers say simplicity is important, but what does it really mean to make something simple? Most of the time we think it means less, that by removing stuff we achieve simplicity. We think by keeping content above the fold we’re helping people focus, or by using bullets instead of paragraphs more people will read it, or by cutting text in half it becomes more clear. But simple doesn’t mean “less”. A better definition would be “just enough”.

Oops, I may have oversimplified there…

In some cases designs actually need more of something to become simple. So a better definition of simple is “just enough for comprehension and the ability to pursue and complete our goals”. Instead of hiding or cutting stuff away, here is how we can achieve more meaningful simplicity in our designs:

  • Have a single core idea (not several ideas, or a partial idea)
  • Improve clarity over time (don’t overwhelm with inappropriate details)
  • Use consistency (avoid using unnecessarily unique interfaces and messages)

Have a Single Core Idea

Attention and interest are the first things you need to develop to get someone to take any kind of action. The best way to grab attention and build interest is to present a single core idea, fully fledged. This allows the user to make a binary decision about it: “Am I interested or not?”. Introducing a feature in a way that people can instantly map it to a desired outcome will help them prioritize and be confident about their next step. The need to present a single core idea is true from the big picture all the way down to each of the smallest features.

“Nothing says Send Message, like the words ‘Send Message’.” – Des Traynor @destraynor

This is an example of a small feature being extremely clear to an outcome. The copy here could have been “Go” or “Submit Now” or just “Send”. None of these are as clear or binary as “Send Message”, which in two words allows people to confidently agree or disagree with it. As you move into more complex features being binary gets exponentially harder, but the goal should remain the same: lead people with a core idea that properly sets their expectations. If we fail to do this, the perception of complexity will grow.

A single core idea is:

  • Binary – simple enough that there are only two sides to it…allowing people to assess their agreement or not.
  • Stated in plain language – be as clear and obvious about the problem or opportunity as possible.
  • Repeated constantly – every interface should reiterate the appropriate problem or opportunity where appropriate.
  • Tied to an outcome – the end goal of each problem or opportunity should always be visible.

Improve Clarity Over Time

After gaining people’s interest, getting them to invest their time and mental energy is the next big step. Even when your audience finds your application interesting, there can still be lots of friction. If they’re intimidated by it, the adoption rate will be slow. You have to show them that they can accomplish their goals without frustration.

“Web copy: Write too little and the meaning doesn’t come through. Write too much and the block is skipped because it was too thick to scan.” – Ryan Singer @rjs

Much like a conversation that is refined over time, the right details in the right moments will give momentum to the process and increase the chances of it reaching a positive end. Removing relevant, but inappropriate details, will keep people moving forward and reduce the chances of being distracted. Remember, every investment of time or mental effort without a meaningful result will add to the perception of complexity.

Improve clarity over time with:

  • Clear starting and ending points – make sure it’s obvious how to do something valuable within an interface.
  • Progressive disclosure – be appropriate: put focus only those details that help with comprehension of the current task.
  • Obvious paths – always provide a clear transition to the next step or level of detail.

Use Consistency

A new user and a long-time user are very different animals. If you want to keep people around, you need to help them feel like they’re mastering each part of the application and have no reason to worry about the next one. Each feature needs to be approachable enough to seem enjoyable and feel like it’s going to be the best use of their time and energy.

“Whether it is flags waving in the wind, the difference between empty or crowded train platforms, or the footprints in the fields that suggest paths to follow, we search for significant signs in the world that offer guidance.” – Don Norman @jnd1er

Showing people a friendly face will give them confidence and put a smile on their face. Help people see things they’ve seen before and draw conclusions based on things they already know. There’s nothing wrong with a complex interface when you have a complex problem, but there’s no excuse for dropping someone off in a foreign land without a guide or a map. That’s just mean.

Be consistent through:

  • Consolidating routines – identify similar processes and use similar approaches.
  • Building patterns – put similar things in similar places so people can act through intuition.
  • Occasionally breaking the rules – know when an interface is genuinely unique–it’s probably not as often as you think.

When More is Less

Prevailing wisdom suggests that simplicity is about less…removal and reductionism. But simplicity is really about comprehension and clarity of purpose…can we design such that people instantly understand what’s going on and make a confident decision about what to do next? To practically achieve simplicity we can stick to a single core idea, improve clarity over time, and use consistency to help users achieve efficiency. In this way more can be less…by adding the appropriate details at the appropriate time the entire process comes to seem simple to the people using it. Simplicity has tricked us into thinking its about less. But it’s really about having just enough.

9 Extreme Creativity Questions from Peter’s Laws | The Brainzooming Group


9 Extreme Creativity Questions from Peter’s Laws | The Brainzooming Group
Published on August 11, 2011 by Mike Brown in Brainzooming – All Posts, Career, Collaboration, Creativity, Innovation, Performance, Strategic Thinking,…

November 13, 2015 at 09:50AM
via Instapaper http://ift.tt/1uZUzDd

Lean Mobile UX Lessons To Keep Your App From Sinking Like The Vasa Ship – Smashing Magazine


For many months, your entire team has worked their butts off to create an awesome mobile app. Finally, with your team exhausted and excited, it’s showtime! But then, your dream app turns into the ultimate nightmare: Eager customers download the app, use it once and never return.All the sacrifice and months of hard work — wasted. What went wrong?

Your app has become another victim of the latest trend, joining a whopping 41% of today’s apps that are abandoned after only a single use. This trend has many parallels with the story of the 400-year-oldVasa ship. The most impressive warship of the day, Vasa floundered and sank just one mile into its maiden voyage due to fundamental design issues.

The salvaged Vasa ship in the museum in Stockholm

The salvaged Vasa ship in the museum in Stockholm (Image: Greg Nudelman) (View large version)

In this article, we’ll explore how the lessons from the Vasa ship can help you keep your mobile project from sinking right out of the port.

Create A Clear, Compelling Vision Link

Although the Vasa ship was ultimately a failure, it was unquestionably a magnificent one. The builders dared greatly.

So, before talking about all of the things that went wrong with that project, let’s touch briefly on the one thing that went right: The builders of the ship had a grand vision that told a riveting story of royal conquest and pride.

Even today, 400 years later, their vision is spellbinding. It is expressed in beautiful craftsmanship, the gaily painted mythological statuary, the fearsome armament and the overall appearance of the ship.

Even today, Vasa presents a grand vision.

Even today, Vasa presents a grand vision. (Image: Greg Nudelman) (View large version)

When it comes to vision, your mobile project should be no less compelling.

You must have a clear vision of what you are building — and the benefits the app will provide — before you decide how to design and implement the app.

Fortunately, expressing a vision for a mobile project is fairly simple. You can do it in as little as 20 to 30 minutes, using just a handful of sticky notes to create a storyboard that describes the app’s primary use case.

A good example is the “Be a Hero” storyboard from my book $1 Prototype:

Be a Hero app storyboard from $1 Prototype book

“Be a Hero” app storyboard from $1 Prototype book (Image: Greg Nudelman) (View large version)

This storyboard presents a powerful use case: A person wants to support the typhoon relief efforts by sending funds to a charity of their choice. The benefits are clear: The person donating the supplies gets to feel like a hero, and the survivors of the disaster get the urgent help they need to start rebuilding their lives.

According to Fortune, the number one reason most startups fail is that they make a product no one wants. To make sure your mobile project doesn’t become another statistic, formulate a vision that people can get excited about.

Before doing any actual design or development, take the time to document your vision as a storyboard. Then, show it to both potential customers and your stakeholders to ensure that the response from all key people is enthusiastic.

Your vision must communicate a clear, compelling benefit; otherwise, the app will not be worth building. Once your vision is in place, it’s time to start designing and prototyping your solution.

Test Early, And Inform Executives Link

When plans for Vasa were first presented to the King of Sweden, he made two fatal modifications. One was to arm the ship to the teeth with heavy 24-pound cannons. The second was to make the ship thinner in order to make it faster.

Many would assume that such detailed design guidance meant that the king personally oversaw the construction. This was not the case. The king made only a single visit to the docks.

In fact, the first stability test was not performed until after Vasa was afloat and fully equipped. As Wikipedia tells it:

Thirty men ran back and forth across the upper deck to start the ship rolling, but the admiral in charge stopped the test after they had made only three trips, as he feared the ship would capsize.

Despite the failed stability test, it was too late to do anything about the launch. No one wanted to bring bad news to the king, who insisted that the ship be put to sea as soon as possible.

In the end, we can say that the king got exactly what he wanted, but not what he needed — an impressive ship that sank just one mile offshore.

Nothing is wrong with executive feedback or changes to a proposed design. Both are absolutely essential and are a part of any significant project. What was lacking here was early concept testing and a timely feedback loop.

Just as your vision and prototypes need to be adequately tested at every step of the design and development, communicating the test results to the right people is equally important. Key people need to be part of the solution, or else they will become part of the problem.

As a designer, your job is to provide timely feedback to executives. Clearly communicate any product issues early, while they can still be addressed, to ensure that the best design moves forward.

How do you ensure that you get the executive feedback early? That’s where a minimum viable prototype can be extremely helpful.

I had a chance to visit The Vasa Museum recently before my talk at From Business to Buttons 2015, a conference in Stockholm.

In the museum, next to the salvaged Vasa, sits a 1:10 scale model of the original ship as it looked on the fatal day of the launch. Such a model would have been ideal in refining the design: Anyone would have been able to see how making the ship thinner and taller and adding heavy cannons on top would compromise its stability.

The 1:10 scale model of the ship in Stockholm's Vasa Museum

The 1:10 scale model of the ship in Stockholm’s Vasa Museum (Image: Greg Nudelman) (View large version)

However, this 1:10 scale model was built after Vasa sank, making it useless, except as a lesson to us: Build a model of your mobile product, get executive feedback early, and refine the design before investing in development.

Fortunately today, building a model of your app is extremely easy — you do not need wooden planks, any special equipment or software. Even better, your design and your prototype can be one and the same.

All you need is a pack of 3 × 5-inch plain sticky notes:

Sticky notes mobile prototype

Sticky notes mobile prototype (Image: Greg Nudelman)

For example, here’s a minimum viable prototype for the Be a Hero app:

Final minimum viable prototype of Be a Hero app made with sticky notes

Final minimum viable prototype of Be a Hero app made with sticky notes (Image: Greg Nudelman) (View large version)

With this simple prototype, you can quickly and easily test and refine all of the basic design aspects of your app: the information architecture, the interaction design, the copy, etc. You can even test the icons and transitions.

The lean process is all about experimentation. By creating a minimum viable prototype to set up your experiment and going directly to potential customers for testing, you significantly speed up the process of experimentation and feedback, both internal and external.

In essence, you institutionalize failure in its cheapest and most expedient form.

Early continual user testing of your prototype reduces the likelihood of any fatal design issues when your app launches, vastly increasing your chances of success.

Early Design Tweaks Make All The Difference

While the Vasa disaster is quite famous, many people do not know about Vasa’s sister ship, the Apple. The builders of Apple made two important modifications: they installed lighter guns on the upper deck and widened the ship’s hull by 1 meter (just 10% of Vasa’s original width).

These simple tweaks made all the difference: The Apple sailed successfully for over 30 years.

To ensure the success of your own mobile project, test yearly and expect to make a lot of iterations in the beginning, until the design settles somewhat. Investing time and energy into a high-definition pixel-perfect design right from the start would be counterproductive.

Rather, keep the fidelity of the prototype appropriate to the state of the project. The key foundational aspects of the design (information architecture, interactions and copy) are best tested using quick and cheap minimum viable prototypes made with sticky notes.

In the case of the Be a Hero app, for example, the sticky notes prototype of the home screen underwent five iterations before the team came up with a design that performed well:

Five iterations of the MVP for Be a Hero app

Five iterations of the MVP for Be a Hero app (Image: Greg Nudelman) (View large version)

Only after the team had perfected the key elements of the design did they invest the extra time required to create the high-fidelity prototype:

Finished design for Be a Hero app

Finished design for Be a Hero app (Image: Greg Nudelman) (View large version)

Keeping the fidelity of the prototype appropriate to the state of the project helped the Be a Hero team move quickly and solve most problems early in the design process, enabling them to create the final design in just three weeks.

Don’t know about you, but that sounds like a lot of sunken ships were avoided for the cost of a pack of sticky notes — something even His Majesty the King of Sweden would surely approve!

Ensure Smooth Sailing For Your Mobile App

You have now seen how the history of the Vasa ship can help you avoid a major disaster with your mobile project if you follow a few simple but profound lean UX guidelines.

Before you begin, put your vision in place as a storyboard. Take the time to test it with potential customers and stakeholders — ensure that they are as enthusiastic about your idea as you are.

Once your vision has been approved, begin the design in lockstep with user testing by using a minimum viable prototype made from sticky notes. From this point, continual rapid prototyping and customer feedback should form the core of your mobile design process.

Along the way, don’t forget the importance of two-way communication with executive management and other key people on your team.

By including all of the key people in your feedback loop, you ensure that everyone on the team feels that their ideas are given due consideration from the start. This minimizes the likelihood that anyone will insist on last-minute changes that you cannot adequately test or implement.

Remember to make the fidelity of your prototype appropriate to the stage of the project. Do not invest time and effort in high-fidelity prototypes before you are comfortable with the key aspects of the design. Rather, stick with low-fidelity prototypes for as long as possible, testing design tweaks quickly, and continually incorporating insights back into your prototype.

Lean, rapid prototyping coupled with a continual feedback loop will help your team work smoothly, incorporate new ideas and build a mobile app that not only survives its maiden voyage with flying colors, but sails successfully for many years to come, striking fear into the hearts of competitors.
(da, ml, al)

Continue reading

UsabilityNet: Methods: Affinity diagramming


Affinity diagramming is used to sort large amounts of data into logical groups. Existing items and/or new items identified by individuals are written on sticky…

November 12, 2015 at 10:48PM
via Instapaper http://ift.tt/1iXIUQF