As users are able to interact with and edit more more parts of their applications, every piece of information (i.e. location data, timestamping, profile info, mutual connections, etc.) and content (profile images, user-generated content, business listings, etc.) must be designed with that in mind.

In this article, we dive deep into 18 different UI patterns for data and content management.

You should also have a look at Exploring Social Design Patterns For the Web and The Importance of Navigation Design Patterns.

1. Favorites & Bookmarks

Examples: Airbnb, Medium

Problem: The user wants to save and highlight content they like.

Solution: Let users save and bookmark content for their reference. This UI pattern is more about personal organization rather than promoting content, and many web apps like Facebook, Gmail and Airbnb let users “star”, “favorite”, “save” or “bookmark” content privately, giving the user a way to come back to any place in the app that they might need later.

As opposed to liking or sharing content that tends to get lost in the timeline as the user’s activity progresses, Favorites and Bookmarks can be used to mark content that the user would need to come back to, for example neighborhoods a user is researching in Airbnb or a particular email that the user wants to mark as important. This UI pattern gives users a private way of highlighting important content as opposed to taking an action on it like sharing or liking it.

2. Stats / Dashboards

Examples: LinkedIn, Medium

Problem: The user wants to easily keep track of their activity and status.

Solution: Present important information and statistics to summarize user activity and status in terms of numbers. Twitter and Quora show users the number of followers and tweets or answers they have for an indication of activity. While some web apps only show number of likes, shares or followers, others like Medium, LinkedIn and Quora also show users more detailed statistics about their activity using Dashboards that used to be limited to business applications.

With the extensive tracking and analytics data available for user interactions, this pattern will become even more popular as users want to track their activity on the system and even analyze how they’re doing in comparison to others.

3. Contextually-Aware Content

Examples: Facebook

Problem: The user wants to interact with content in different ways based on the context without having to take additional actions.

Solution: Change the state of content based on other settings in the application or it’s sizing, positioning, or other attribute. For example, you can auto-play multimedia content as the user scrolls past. This makes the consumption of user content much smoother by eliminating the step where users stop and hit the play button.

In terms of making things easier for users, this pattern makes sense but at the same time it is worth considering the annoyance it can cause. For that reason alone, this pattern is worth considering only for sites and networks that feature a lot of multimedia user-generated content where the user is browsing with the explicit intention of consuming that media. The user would probably not browse through a Vine timeline for any other reason than to watch the videos, so it makes sense. Facebook‘s implementation is a little suspect for the same reason.

4. Hover Controls

Examples: Pocket

Problem: The user wants to have access to controls without cluttering the content view.

Solution: Hide actions and control buttons until a user hovers over the item they relate to. It’s always good to give the user complete control over content, but when an interface has a lot that can be acted upon, each button steals focus away from the content. This UI pattern hides these contextual controls until the user hovers over the content with their mouse, keeping them out of the way until needed. Pinterest puts all focus on the photos, so the “heart”, “send”
and “pin” buttons are invisible until you hover over the photo.

As discussed in Web UI Design Patterns 2014, this fits well with the modular cards UI pattern. Since the buttons appear over the image itself, there’s no confusion about which item they will act upon.

5. Context Menus

Examples: Dropbox, Medium

Problem: The user wants to have access to controls without cluttering the content view.

Solution: Put contextual action buttons in a menu that pops up when the user selects an item or right-clicks somewhere in the UI. A context menu opens up to show essential actions that can be taken in the current view or upon the selected content. This makes things faster for users. Instead of having to scroll up to a toolbar, users can simply perform their desired action in place.

The traditional context menu is triggered by a right click, and applications like Word Online, Google Drive, Evernote and Dropbox that emulate a desktop UI use them mostly for CRUD controls. Another implementation of context menus is a menu that pops up when users select text on the page. Medium puts the “notes” button and “share as a tweet” button behind this kind of context menu, and Quora puts an option to quote the text in an answer.

6. WYSIWYG

Examples: Gmail, Medium

Problem: The user wants to add formatted text and preview what their content looks like without having to worry about markup languages.

Solution: Implement a WYSIWYG text editor that lets users format their entered text without having to go into Markdown formatting or HTML code. This gives users a clear preview of how their content will look once published and can be a great way of lowering the barrier of entry for novice users. In the spirit of direct manipulation, this pattern is widely implemented in most blogging and email web apps, allowing users to edit and preview formatted multimedia content as they would in a text editor on their desktop.

7. Autosave

Examples: Gmail, Medium

Problem: The user wants to protect their data and continue working without having to remember to do so.

Solution: Prevent accidental data loss by implementing an autosave feature in your app. Gmail and Google Docs does this flawlessly, auto-saving your work every few seconds and preventing any “oh, no!” moments. The autosave pattern is an unobtrusive way of doing that without forcing the user to remember to save every few minutes.

Browser crashes, power or connection failures, or even accidentally closing the browser tab are major annoyances that can be soothed when the user is assured that their work hasn’t been lost. With cheap data storage and other UI patterns like User History, it makes sense to preemptively save user data rather than risk losing it by mistake. Of course there needs to be a clear indication that the app is autosaving, and perhaps even an additional “Save” button to provide a greater feeling of control.

8. Lightbox Photo Slideshows

Examples: Facebook, Pinterest

Problem: The user wants to browse through multimedia content.

Solution: Show multimedia content in a lightbox overlay. This modal window creates focus on the image or video content and breaks it free from the confines of the page’s design. It also puts users in a better position to simply browse through the gallery without being distracted with the surrounding “chrome” in the page.

Most implementations of this pattern also dim the background page behind the modal window and that prevents the user from losing their place in the main content view. This can come in handy particularly when paired with an infinite scroll pattern, as in Facebook and Pinterest. It’s faster than loading a new page for each image and also preserves the user’s flow when the want to back out of the multimedia gallery. For photo galleries, a modal lightbox slideshow is an essential UI pattern.

9. Full-Screen Modes

Examples: YouTube, Medium

Problem: The user wants to focus on content instead of being distracted with the UI

Solution: Design a full-screen mode that hides or minimizes the UI clutter around content. This helps users focus on what matters, rather than being distracted by the clutter of the UI. While multimedia web apps like YouTube and Vimeo let users view videos in full-screen mode, other web apps like Medium and Facebook are using the full-screen concept to eliminate unnecessary “chrome” when the user wants to perform particular actions.

For example Facebook lets users browse photo albums in a Lightbox Photo Slideshow (above), which is another pattern that we cover, but this expands to the entire screen. Medium removes all distractions when the user is writing, effectively achieving the same immersive effect as an otherwise traditional full-screen mode.

10. Interactive Content Layers

Example: Airbnb, Yelp

Problem: The user wants to know which items within a content view they can interact with in further detail.

Solution: Layer interactive items to provide an “augmented reality” approach to your content. Yelp and Airbnb provide classic examples of this pattern: Next to the search results for different locations, these sites include a map that highlights each search result with a corresponding location ‘bubble.’

When users hover over the search result, the corresponding location bubble in the map becomes highlighted so that users can immediately see where each result is located. Additionally, users can interact with the map itself, e.g. by dragging to different locations – both Airbnb and Yelp have a ‘Search when map is moved button’ that automatically shows new location bubbles in the new areas of the map.

11. Maps As Backgrounds

Examples: Airbnb, Foursquare

Problem: The user wants to spatially place content on a map to see what’s going on around them.

Solution: Provide maps as backgrounds when the user is browsing for information that’s local in nature. Web apps like Foursquare and Airbnb layer their listings onto the map view, transforming the user’s search and browsing activities into an immersive experience. This makes sense for most location-based web apps which provide users information about localized content because it helps them place it according their own location on a map in a way that’s more intuitive than just browsing a list.

12. Group Friends & Content

Examples: Google+, Google Play Music

Problem: The user wants to organize content according to their own groupings

Solution: Allow users to sort and organize friends and followers inside the app. Google+ and Facebook among others allow users to group friends and content alike. Besides allowing users to sort their friends, web apps like Google Play Music and Ebay allow for content to be categorized into playlists and collections that not only help them organize the huge amounts of user-generated content for their own convenience, but also create a way for them to share these collections with their friends and followers.

As content of all forms – including friend profiles – continues to proliferate, the ability for users to curate and organize things in a way that makes sense to them becomes more important.

13. Grids

Examples: Pocket, NYTimes

Problem: The user wants content to be organized.

Solution: Show snippets of content in a grid. Spotify and Google+ present all their content in a grid, as do Pinterest and Digg, effectively separating each item from the other while maintaining a structure. Grids are a great alternative to the simple list views and work extremely well for content that can be represented visually, making it much more enjoyable for users to scroll through lots of content.

Other sites that are content heavy, like NY Times or CNN can also benefit from a grid layout to help provide some visual structure to the various pieces of content. Some like Pocket and Groupon also allow users to toggle between the grid and list views depending on their preferences.

14. Cards

Examples: Twitter, Google+

Problem: The user wants to browse through content quickly and interact with it, without the detail views cluttering up the UI.

Solution: Present snippets of information in bite-sized cards that can be manipulated to show more information if the user wants it. Popularized by the likes of Pinterest to show large image thumbnails in a compact layout, we see “card” views now being implemented in a variety of web apps beyond video and photo galleries on the web, and often this is combined with a Grid pattern.

This pattern works best for “modules” of data that can be viewed or manipulated individually, like posts on Tumblr or Facebook. Cards are a way to allow users to browse and discover all kinds of content in a more engaging way while accommodating responsive design trends, as well as social feed patterns.

15. Hidden Information

Examples: Medium

Problem: The user wants quick access secondary information that’s not usually necessary to show.

Solution: Hide contextual information that’s not essential behind the UI but make it accessible for power users. Medium hides comments behind a number, subtly showing users that there’s additional information available.

This keeps the user’s focus on the primary content without distracting them with extra clutter in the UI. As users become familiar with the system, the visual shortcuts become easier to spot. Google+ achieves the same effect by hiding multiple tags on each post and marking it with a colored bar to indicate extra tags other than the first one that is always visible.

16. Empty States

Examples: Airbnb, Pinterest

Problem: The user needs to know why a section of the application is empty and what to do next.

Solution: Make sure your UI provides a good first impression by designing for the “blank state,” that is the condition when there is no user data. This is the natural state of your UI and the first thing a user sees. It is also the point where many users decide whether its worth it to continue, so designing the empty state is very important. This is a great place to show some examples that will help users get started or simply to show them instructions on how to proceed.

Airbnb shows a mockup of how a particular section would look like once it’s populated by the user’s content, while Pinterest takes the opportunity to guide the user through what next steps they should take; other sites like Tumblr and Medium give users hints on what the empty area is and what it should be once the user takes a certain action.

17. Direct Manipulation of Content & Data

Examples: Asana, Facebook

Problem: The user wants to interact with entered content or data in a direct and intuitive way.

Solution: Allow for content to be edited directly without having to transition between editing or deleting modes. Letting users work with data directly on the screen can make your UI more engaging by eliminating the extra layer of interaction provided by a button or context menu. Instead of selecting the item and then toggling between individual CRUD (Create, Read, Update, Delete) states, users of Asana for example can directly tap on task names to edit or delete them.

Other sites like Tumblr and Medium follow the same principle however they do include a toggle which moves the user into an editing mode. This pattern is an alternative to the WYSIWYG pattern discussed earlier but goes ahead of just giving users a preview of what their formatted content will look like, showing them also how it looks in context of the surrounding content as well.

18. Draggable Objects

Examples: Asana, Google Play Music

Problem: The user wants to sort and organize items in a way that makes sense to them in the current view without pogo-sticking between master and detailed views of content.

Solution: Content can be picked up and rearranged, or simply dragged across to perform an action. One great example of this pattern is when you’re arranging items on the homescreen, but we see this being implemented in a lot of web apps as well.

Google Play Music lets you drag and drop songs in a playlist to rearrange the order in which they’re played. Since this is a very interactive action, you should make sure the UI provides visual feedback in the form of animations or color changes to clearly indicate that something is happening. For example, items being dragged in Asana are highlighted with a shadow. Another visual cue is highlighting the drop target, that is the location where the item will fall when the user lets go.

Keep Your User Organized

Keep track of where your users are supposed to be interacting with data and content, whether they ever view those sections of the application, how often they interact with them, where they’re coming from and going to in the application (i.e. the user flow) and so on. Keep rearranging, re-sequencing, re-sizing, and tweaking those controls until you get more of the desired actions. And, of course, think deeply about how the user is actually using your mobile application when they’re viewing and engaging with the data and content – make sure you’re new and existing not missing something obvious when designing your app.

The post A Deep Look at Data & Content Design Patterns appeared first on Speckyboy Design Magazine.

As Lean UX advocate Jeff Gothelf describes in a piece for Smashing Magazine, thick deliverables created simply for future reference regarding the user experience become obsolete almost as soon as they’re created.

In today’s Lean and Agile world, the experience should be the focus — not deliverables. Whether you choose lightweight or more detailed processes, the key is that your documentation should help move the design forward (rather than being just a lagging indicator).

The following is an overview of product design and development documentation, individual elements, and the respective phases to which they belong. Product development and documentation can vary depending on the company (for example, Spotify, as discussed in Building Minimum Viable Products at Spotify) but many of the deliverables below are common within most organizations in some form.

We’ve chosen the methods that we think work best, but feel free to pick only what works.

How They All Relate

When it comes to product design documentation, theory and practice are two very different things. We all know basic tenets of user-centered design. We recognize different research methods, the prototyping stage, as well as the process of documenting techniques in our rich methodological environments. The question you probably often ask yourself, though, is “How does it all work in practice?”

Simply put, it’s all about making documentation complementary rather than supplementary to the design process. Before we go into detail, it might help to take a quick birds eye view of documentation during product design and development. Below, we’ve given a practical explanation of how every step of design documentation ties together:

1. During the initial phase of product definition, you’re brainstorming the product and how to execute on the project at the highest level with all necessary stakeholders. This might result in project kickoff plan, a lean canvas, and a bunch of really early concept maps and mockups of what you’re looking to build.
2. Moving into research, your team refines assumptions and fills in the blanks. This stage varies based on complexity of the product, timing, resources, level of existing knowledge, and many other factors. In general, however, it’s good to build out competitive and market analyses and conduct customer surveys. If you have an existing product, reviewing analytics, heuristics, content, product context, and user tests are also quite helpful.
3. In analysis, the product marketing data collected so far provides the foundation for personas, experience maps, and requirements documents such as prioritized feature spreadsheets and user-task matrices. At this point, the product definition, product priorities, and product plan has been defined and are ready for more formal design deliverables. As discussed in the Guide to UX Design Process & Documentation, sketches and diagrams are also likely constantly being generated throughout this time.
4. From this output, scenarios, concept maps, and mockups may be created, leading into the design phase. Common documentation includes sketches, wireframes, prototypes, task-flow diagrams, and design specifications. For example, competitive analysis and personas created during research and analysis feed into the mockups, concept maps, and scenarios. In turn, these pieces influence intermediate and advanced deliverables such as wireframes, storyboards, and detailed mockups.
5. During implementation, code and design assets are assembled to create a product that follows the product design specifications.
6. Upon launch of the live product, feedback data such as support tickets, bug reports, and other analytics continue to drive product refinement through subsequent iterations, and upgrades. With the offering in production mode, data should be continually generated and monitored in the form of analytics and reports to ensure continued success.
7. Continual, data-driven product improvement is achieved through measuring and iterating the offering in production, using performance dashboards and analytics.

Guiding Principles

Now that you’ve seen how each stage is connected to each other, let’s look at some helpful principles for moving the product along each stage. We’ll explain how to use design sprints so that the process evolves over time instead of being defined only in the beginning.

Image Source: Source: User-Centered Design.

Similar to its Agile software counterpart, design sprints are 1-3 week sprints that focus on solving specific product and design issues. According to Alok Jain, UX Lead at 3Pillar, the three key elements to design sprints are collaboration, reduced handover friction, and team focus.

In a nutshell, your documentation is a collaborative effort that must always focus on the user itself. Because you move quickly between each stage, you build momentum and minimize waste. More importantly, you’re tackling smaller problems which allows for more exploration and risk-taking.

An extremely lean version of the complete cycle can be found here, but we’ll describe in detail below how to apply this thinking as you understand the product, design the product, and release and improve the product.

1. Understanding the product

Before you can build a product, you need to understand its context for existence. Why should stakeholders, the company, and the users care about moving forward with your idea?

Image Source: Achieve Shared Understanding.

According to Smashing Magazine, you need to include activities that address business requirements, user requirements, and the best design solution to satisfy both. The keyword here is “activities”, because while documents like the Business Model Canvas and Lean Canvas are important, you need to energize stakeholders — otherwise you just have a bunch of expensive people talking about stuff everyone already knows. These activities are efficient and invite collaboration:

• Stakeholder interviews — Using this template, you can have each team member interview 3 stakeholders. How will the product make customers feel? What should they do? By recording how stakeholders think customers will think, feel, and do, you’re setting a benchmark to compare against usability testing and user analysis.
• Requirements workshops — Get stakeholders together, discuss the project plan, and start discussing how concepts feed into product and
  technical requirements. You can start with a blank Business Model Canvas or Lean Canvas and complete it with the team.
• Crazy 8s — Grab some markers and get everyone to sketch 8 product or feature ideas in 5 minutes. Have everyone score each idea, and
  you’ll start to see trends and preferences. This was actually Step 2 in the redesign process for Google Ventures.

Once you’ve laid out the groundwork, talk and test with tons of users so you have real field data for research and analysis. Marcin Treder, CEO of UXPin, dove deep into customer development and usability testing after identifying the problem and scope.

Back when UXPin was just a paper prototyping tool, Marcin documented (on paper and video) over 50 user interviews and in-person usability tests with UX superstars like Brandon Schauer, Luke Wroblewski, Indi Young and others. The product team then used these insights to create personas, write dozens of user stories, and eventually, outline the product requirements.

At Amazon, an alternative “working backwards” approach is used in which the first step is drafting an internal press release for the finished product.

This approach helps to work backwards from the customer, rather than trying to bolt customers to an idea. By iterating the press release until it sounds appealing, the product team gets an immediate reality check as well as a quick benchmark document for later design and development.

2. Designing the product

Once you have a sense of the product purpose, your main goal is to build a prototype. Whether your team likes to draw on napkins, create high or low fidelity wireframes, you should ultimately end up with something functional. What’s unique about this stage is that for most of the deliverables, the documentation is the design.

According to Cennydd Bowles, Design Manager at Twitter, the product team should research two iterations ahead, design one iteration ahead, and review the previous iteration. If you’re trying to stay Agile, he advises diving straight into low-fidelity prototypes as a way of prioritizing “interactions over processes.”

If you want to get a bit more detailed but still want to stay somewhat lightweight, you can start with concept maps or sketches, then iterate to low-fidelity wireframes, and finally create a high-fidelity prototype. Regardless of your method, make sure you test with stakeholders and users.

If budget and timing allow for it, you can also create experience maps to highlight where the product meets or fails user needs and task models to provide insight into activities users perform to reach their goals. While these aren’t part of the design, they are complementary since you also need to see where your product fits into mind and market.

Interestingly enough, Yelp takes their design stage a step further by creating a style guide that includes common lines of code, allowing the documentation to literally be built into the product.

At UXPin, our process is to hold a group sketch session with sharpies on gridded paper, then cull that down to a few wireframes, and then add detail until we have a high fidelity mockup. If user testing is involved, we will build the mockup into a high-fidelity prototype. For large feature releases, we conduct extensive user testing so the ratio is about 70/30 in favor of prototypes.

3. Building and launching the product

As you start to do the heavy technical lifting, it’s important to create documentation that helps you see the overall vision. Specific requirements may change as you refine the product, but your documentation should help you understand priorities as your product goes into the wild.

Kristofer Layon, UX Manager at RedStamp, believes that you can visualize product requirements and technical specification documents as a roadmap. The product road map shows user stories and helps prioritize the features you’ll build to satisfy them. Sometimes, specific dates may be added into the roadmap so that it also works as a timeline.

The elegance of the roadmap is that helps you prioritize what you’re building, making it complementary to the “how” defined by your product requirements and technical specs. When deciding features, you can use the Kano Model to evaluate them in 3 categories:

• Basic Attributes — These are absolutely required just for the product to work. For example, a laptop’s basic attribute is the keyboard or screen.
• Performance Attributes — These can be compared between different products as a KPI. For example, a laptop is judged on CPU speed and hard drive space since people tend to prefer fast computers that can store lots of data.
• Delightful Attributes — These are subjective depending on customer preferences. For example, the Macbook Air is extremely thin and smooth to the touch. The right customer would find it a great selling point while others are unimpressed.

By scoring features on a 1-5 scale based on this model, you can then plot them out on a prioritization matrix to help you start envisioning what your product roadmap will look like.

At Apple, the “Rules of the Road” and “Apple New Product Process” serve as the product roadmap by defining responsibilities, stages of creation, and significant milestones from inception to launch. In fact, the Rules of the Road is taken so seriously that losing it can result in immediate termination (it’s even stated in the document).

4. Improving the product

As you build (and ultimately launch) your product, the documentation also needs to focus on defining and tracking sales and other KPIs. After all, you can’t improve the product if you don’t know what metrics you want to optimize.

Image Source: Product Management by Numbers.

Dave Daniels, Founder of LaunchClinic, advises that you write down the launch goals (e.g. 30,000 downloads in 30 days) and verify that you have the right tools to document progress. Using metrics tools and bug reporting software, you can set up recurring reports to keep tabs during the first few weeks of launch and beyond. On the customer side, you can also segment users and send them custom surveys to gauge where you may want to iterate.

At Spotify, the iteration phase is the longest stage of product development. The product team uses current metrics and prioritization matrix (likely created during the Design stage) to weigh benefits vs. effort of improving certain products beyond their “local maximum”. If they determine the effort is worthwhile, they will then return to the Definition stage to revamp the product for it’s “global maximum”.

Objective Processes In a Subjective Environment

When it comes to product design documentation, there is no single magic bullet. Almost all companies that use our product employ bits and pieces of the tactics we’ve described above. While product development and UX design are highly subjective spaces, your processes and documentation don’t need to be. After all, the end goal of a product is revenue, and there’s nothing subjective about that.

Image Source: Design Process Notes.

Whether you go lightweight or prefer more detailed documentation, the goal is all the same — get it out of your head and onto paper (or the screen) so your team can interact and react. Documentation should be a compass for the product, not rules carved in stone.

Some of the stages we discussed may happen in slightly different order or even parallel, but they all exist to provide method to the madness. Use what works, scrap the rest, and evolve your documentation as your product evolves.

The post The Guide To UX Design Process & Documentation appeared first on Speckyboy Design Magazine.

While social features are becoming increasingly important for many reasons, they require careful thinking about the identities and respective communities impacted by them, and how the nature of the product changes with this kind of user interaction. For example, every social network you could possibly link to (i.e. for sharing purposes) is different and serves a different purpose for the users involved. And some information may be really sensitive (i.e. bank information, personally identifiable information, or users may want privacy so they can’t be viewed or contacted by certain people or anyone. These are just some considerations, but the list is virtually endless as mobile applications incorporate more designs around who we are as unique and social people.

In this article, we dive deep into 10 different UI patterns for social design. We’ve also previously delved into the importance of navigation design patterns, you should check that out as well.

1. Achievements & Badges

Example: Codecademy, Stackoverflow

Problem: The user wants incremental encouragement and a general sense of progress

Solution: Build gamification into the user’s interactions with the website. Apart from the regular user interactions like listening to a song or posting an update on a social network, many sites also want to encourage users to complete their profile information or interact more frequently with the app. In these cases it makes sense to provide some incentive to the user so that this extra step appeals to them.

Gamification is one of the most popular ways of doing this as it can be a great way of increasing user engagement. Gamification applies the mechanics that hook gamers in order to make the users more engaged on the site. A gamified app is characterized by rewards the user receives as they move through different stages of the “game”. For example users of Codecademy receive points and badges as they complete different tutorials. Stackoverflow and Quora implement the same and provide users with points that can be used to unlock additional features like asking targeted questions or contributing to protected questions.

2. Auto-Sharing

Example: Quora, Vimeo

Problem: The user wants to easily share their activity with their social networks.

Solution: Build an option that lets users automatically share particular interactions with their social networks. A lot of web apps like Tumblr, Spotify and Vimeo are building granular sharing settings which allow users to automatically post updates to their networks based on their activity. These updates can be posted within the app or even shared with external social channels like Facebook or Twitter.

Not only does this help the user engage with their friends and family in everyday activities like listening to a song or reading an article on an external website, its also a great way to build awareness and engagement with the app itself. For interactions like uploading a photo to Carousel or a video to Vimeo, this pattern makes it even easier for users by eliminating an extra step in the process which they are most likely going to take regardless.

3. Activity Feeds

Example: Medium, Vimeo

Problem: The user wants to keep up with what’s happening around them and get quick updates on recent activity.

Solution: Show recent activity that’s relevant to the user within the app. Aside from the obvious Facebook or Twitter news feeds, other web apps that contain an element of social interaction, like Quora or Medium have implemented activity feeds that provide users with an overview of recent activity from their friends or people they follow.

The activity stream can be used to aggregate recent actions by an individual user, commonly used on profile pages; more commonly however, activity feeds are used to aggregate multiple users from the perspective of one user. These feeds are extremely useful in demonstrating different features of the UI by showing how other users are interacting with it, and this also plays a great word-of-mouth role.

4. Friend Lists

Example: Goodreads

Problem: The user wants to keep track of and engage a subset of their friends on the site.

Solution: Show all the user’s connections or friends in a list. Spotify and Airbnb are part of the growing number of web apps that give you friend lists which can be used to help users engage with the app in a better way by keeping up with how people they know are using the app. Combined with the Follow pattern, which we discuss next, a friend list gives users an easy way to keep track of this information, which comes in handy to give some social proof to content that the users are interacting with.

Friend lists also come in handy when the users want to control who they share with. Whether it’s one-on-one communication or keeping track of someone’s tastes and preferences, the way users explore their blossoming friend groups will become increasingly contextual, requiring friends to become a more integral part of the content-consumption experience.

5. Follow

Example: Google+, Pinterest

Problem: The user wants to track and keep up to date with activity on topics or themes, not just people.

Solution: Let users select items that they want to stay up to date with. Aside from the purely social web apps like Twitter, Pinterest and Spotify, they let you select friends, channels or artists that you want to keep track of, and updates are shown in the user’s newsfeed. Whether you have friends or not, there’s endless user-generated content to keep you busy.

Users can gain access to a lot of varied content by “following” the activities and recommendations of other users and this pattern allows them to do so without having to worry about how many of their actual friends are using the app. Content shared with followers on sites like Google+ and Pinterest makes the content curation community possible and users can choose to follow topics, events, themes or even people to get fresh content built by and around the channel being followed. For the same reason friend lists will become an increasingly important UI design pattern, so will following.

6. Vote to Promote

Example: Medium, Reddit

Problem: The user wants to endorse and share content they like.

Solution: Let users participate in content curation by designing a voting system, where content they like can be promoted. The idea of crowd-sourced content curation was popularized by the likes of Digg and Reddit, and today we see almost every app that has user generated content integrate this pattern to bring up the best from the rest. On Reddit, Stackoverflow and Quora, users can vote on content created by other users. Not only does this create a history of what the user has upvoted or downvoted, it also gives users a way of popularizing content and publicly associate themselves with something they enjoyed.

7. Pay To Promote

Example: Quora, OKCupid

Problem: The user wants to highlight certain content above the regular content feed.

Solution: Let users pay to to promote their content. On sites like Quora and Facebook, users can give their posts a boost by paying a certain amount that gives them greater visibility in the content feed above the regular non-paid content. OKCupid allows users to give their profile a boost in views and LinkedIn does the same albeit as part of the paid membership plan rather than by individual content like in Facebook. As discussed in the e-book Web UI Design Patterns 2014, this form of native advertising can be a great way of allowing users to gain traction and greater visibility while maintaining the user’s experience in the platform.

8. Direct Messaging

Example: Spotify, Twitter

Problem: The user wants to send private messages to their friends from within the system.

Solution: Allow users to interact with each other in private messages alongside their other interactions. Instagram and many other web apps offer chat or direct messaging as an integral part of their experience. Private chat UI design patterns will continue to blossom across many web apps, not just traditional “social networks” now that users are finally comfortable sharing more private things online and they have substantial breadth in the content they’re generating online.

9. Like

Example: YouTube, Pinterest

Problem: The user wants to rate content in a simple way without having to worry about the degrees to which they like it.

Solution: Simplify rating controls by making them binary choices – the user either likes it or dislikes it. Eliminating the fine-grain of stars and rating scores, this makes rating things easier for users as well as interpreting them. If I liked a video, should I rate it 4 stars or go all the way with 5 stars? YouTube and almost every application lets you like (or even dislike) everything in a binary way instead. A lot of web apps provide a way of showing appreciation by simply “liking” or “hearting” content.

10. Find & Invite Friends

Example: Pinterest, Airbnb

Problem: The user wants to experience the application with their friends.

Solution: Make the invitation process simple and easy to complete. Since word-of-mouth and referrals are a huge driver of growth especially in consumer applications, you’ll see this UI design pattern proliferate and evolve even more. Providing users with a way of connecting with and sharing the app with friends also gives them a better, more immersive experience even if just in terms of more content. The invite feature can be built into the onboarding pattern or even as the empty state design, both of which we’ve covered earlier.

Let The User Socialize

Keep track of where your users might want or need to socialize, whether they ever view those features, how often they use them, where they’re coming from and going to in the application (i.e. the user flow) and so on. Keep rearranging, re-sequencing, re-sizing, and tweaking those controls until you get more of the desired actions. And, of course, think deeply about how the user is actually using your mobile application when they’re trying to socialize – make sure you’re not missing something obvious.

The post Exploring Social Design Patterns For the Web appeared first on Speckyboy Design Magazine.

Once someone starts using your website or web application, they need to know where to go and how to get there at any point. If they can’t navigate through your your application easily, you’ll quickly lose them. Thus, designing effective navigation in your web application is crucial.

1. Jump to Section

Example: Pinterest.

Problem: The user wants to jump through whole sections of a web app or content quickly.

Solution: Create a shortcut button or hot spot that takes users directly to a certain part of a web app, typically at the beginning or end but more commonly other specific points.

For example, users can click a tab or button to scroll to the top of the page from wherever they are. This comes in handy especially if you’re also implementing the Infinite Scroll pattern (see below) and the page can get really long as new content is loaded one after the other.

If users want to access controls or information that is only visible at the top of the page, returning there after several pages worth of scrolling can be a nightmare. Pinterest solves this user headache by showing an unobtrusive “jump-to-top” button that instantly scrolls the user back.

2. Single-Page Web Apps

Example: Gmail.

Problem: The user wants a central place to view or take actions on most or all content so they don’t have to waste time navigating between pages.

Solution: Use modern web development techniques to build a single-page app that doesn’t need to reload itself as the user browses through it. This pattern is more of a complete restructuring of how the web works rather than something you can hack into your app afterwards. In a way, the “page in a single-page app isn’t really a page in the traditional web sense, rather it’s more of a particular data view. Single-page web apps load asynchronously (using AJAX), in that they perform instantly without the user having to wait for separate pages to load between operations.

Gmail is a good example of a single-page app that integrates multiple actions into a single “page”. The trend of single-page designs is a less-hardcore implementation of this UI pattern, where all content can be accessed on the same page. This makes browsing much faster and responsive, blurring the line between desktop and web apps.

For web apps like Spotify, the single-page app pattern becomes essential when you consider that the user might play music in the background but also browse through more music at the same time; having a single-page app eliminates the need for a page reload, so the music can keep playing.

One consideration you’ll need to make when implementing a single-page app is the URL structure. Because content is loaded dynamically using JavaScript, URLs can become useless and accessing a particular view can become impossible if not done right. Web apps like Gmail and Twitter overcome this by explicitly generating unique URLs for each view, which also solves the problem of the browser’s Back button becoming unusable.

3. Recommendations

Example: Spotify.

Problem: The user wants to know which content to view.

Solution: Show content suggestions and recommendations at various points to help the user browse through your content. Using the information from the user’s profile preferences or their past interactions in the app, Facebook, Eventbrite, Spotify and Yelp among many others generate tailored recommendations for their users to help them discover new and related content or connections.

These recommendations can come in the form of “popular” or “recently posted” items. Facebook provides “related” pages based on the user’s interactions with posts in their timeline as well as a more dedicated recommendations section where users can discover new pages and people to follow. The stream of content available to users can be endless especially in social web apps that feature user-generated content. As discussed in Web UI Design Patterns 2014, providing a robust recommendations engine in the UI can be a great way to help them discover new content.

4. Related Content

Example: New York Times.

Problem: The user wants to browse similar content if the current content isn’t exactly what they’re looking for or they simply want more.

Solution: Show similar or related content to help the user find more items that are similar to what they’re currently viewing. Like Recommendations (above), this is becoming an essential UI pattern for web apps that feature user-generated content, except rather than tailoring the suggestions based on the user’s preferences or previous activity, Related Content is more about showing related items based on the way they are categorized and tagged.

Amazon, TIME and New York Times are good examples of sites that show items and stories similar to the one currently being viewed. Medium takes this a step further by allowing readers to suggest related content by adding a link to the article’s Further Reading section.

5. Next Steps

Example: Quora.

Problem: The user wants to know what next steps to take after finishing a task.

Solution: Give the user a clear list of next steps that they can follow to enrich their experience. Quora for example creates a to-do list for users to follow to complete their profile. LinkedIn does the same by showing a list of sections the user can add to their profile, pairing it with the Completeness Meter pattern to provide users with an incentive.

Most complex web apps have multiple user flows, so providing users with a to-do list can be a great way of guiding them along. Another pattern this can be paired well with is Related Content; Medium does this well, by showing the teaser for another article when the user reaches the end of the current one. This keeps the user engaged and immersed in your UI.

6. History / Recently Viewed

Example: Amazon.

Problem: The user wants to recall what they interacted with last.

Solution: Let users pick up activities where they last left off. For example, Amazon keeps track of the user’s browsing history and shows recently viewed items so that they can get back to them easily if need be. Many web apps also keep track of what the user has been doing and the Facebook Timeline is the ultimate example of this. Not only does a user’s Timeline record posts made and photos uploaded, it also logs interactions with other pages and 3rd-party web apps like Spotify in an interactive history that the user can refer back to whenever needed.

Google Play Music and Spotify keep track of recently played songs. This pattern helps users keep track of content they’ve interacted with and can also serve as a way of bookmarking things to do later.

7. Featured Content

Example: Airbnb.

Problem: The user wants to know what kind of content can be created with the app.

Solution: Feature specific content front-and-center for users without it getting lost in the mix of often time-related content. This content could be paid, popular, new, or some other important variable.

Featured content serves to show users the possibilities and helps them understand what the platform can accomplish as well as the things other users are using it for. Sites like Airbnb, Etsy and Flickr show random content on the front page that helps users explore the site without having to make a commitment beforehand, as well as encourages existing users by helping them reach greater audiences.

On the other hand, it can also help particular pieces of content gain traction by giving it particular importance. Paid or “featured” content can be marked as such to clarify expectations.

8. Infinite Scroll

Example: Pinterest.

Problem: The user wants to browse through all content.

Solution: Automatically load the next set or page of content when the user reaches the bottom of the current page, creating the effect of an infinite scrolling page. This way new content is automatically loaded and the user does not have to wait after clicking on a “next page” link. Infinite scrolling works best when there is a lot of content to show, as with most social media giants like Facebook, Twitter, Pinterest and Tumblr among others.

However while its great for browsing content, especially multimedia galleries, two basic problems are that users can become disoriented and lose their place. If they want to skip to a particular point or bookmark to come back later, infinite scroll can cause problems. Facebook works around this when browsing a Timeline by creating a pagination/infinite scroll hybrid that lets you jump to a particular month or year. Pinterest integrates the Scroll to Top pattern, with a small button that lets users jump back to the start of the page.

9. Walkthroughs & Coach Marks

Example: Slack.

Problem: The user wants to know how to use the different features of the application.

Solution: Design a walkthrough or tutorial that demonstrates how each function works. A lot of web apps have begun using this technique to show users around when they first launch and there are two basic ways of doing this.

Some web apps, like Slack go the route of overlay instructions, highlighting important parts of the UI with “coach marks” to explain what they do. Slack takes things to the next level by integrating a chat bot that helps users set up their profile. This makes perfect sense given that Slack is a chat app, and the “Slackbot” walks the users through filling in their profile information like phone number and display name like a conversation.

Alternatively, Tumblr presents a walkthrough to help the user get acquainted. This walkthrough is also a great time to collect important information that goes beyond simple registrations, much like a setup wizard. The importance of this pattern cannot be stressed enough for any application that isn’t immediately intuitive because the more a user knows about your product, the more reasons they’ll have to come back.

10. Overflow Menus

Example: Spotify.

Problem: The user want quick access to additional options or actions they can perform.

Solution: Hide extra options and buttons in an expandable menu so that they don’t clutter the main interface. Both Facebook and Google use “overflow menus” to maintain very clean user interfaces on their web apps by hiding the most important secondary options in an expandable menu.

This can also be used to show the most important actions in terms of engagement. For example Pinterest keeps a share on Facebook button visible to help speed up a common and desirable user action on each “pin”. Alternatively, an overflow menu can be used to contain additional menu items or actions as they are incrementally added to the UI.

11. Morphing Controls

Example: Pinterest.

Problem: The user wants to perform different types of actions, but there’s limited screen real estate to show all these controls.

Solution: Replace buttons and on-screen controls with alternative functionality. Depending on what the user is currently doing, the UI could entirely replace an element with another, e.g. “do” and “undo” or “add” and “delete.” This makes sense when the alternating actions are related in some way. Pinterest and Facebook use the same button for “like”/”unlike” to save space and also indicate the current state to the user. This UI design pattern saves real estate, makes undoing any action quick and clean, and is an overall playful solution.

12. “Sticky” Fixed Navigation

Example: Houzz.

Problem: The user wants to have access to the menus anytime while on the web page.

Solution: The top, side, or bottom navigation stays in place while a page is scrolled. In some cases, headings from sub-sections may also become fixed while scrolling and replace or be appended to the existing fixed navigation.

The main navigation bar for both Google+ and Pinterest sticks to the top of the page, allowing users to quickly access those menu items and filters whenever they need to. When paired with the Infinite Scroll pattern, a sticky navigation menu can be a great convenience for users who scroll past more than the first page’s worth of content.

13. Vertical Navigation

Example: Spotify.

Problem: The user needs a way to navigate between different sections of the app, but there’s limited space to show this information.

Solution: Important sections of the UI can be presented in a list, which the user can scroll through to get what they want. This also leaves the header and footer of the UI free for more “universal” navigation, such as action bars. Traditionally, most navigation patterns have been horizontal in the form of tabs or buttons. The vertical navigation pattern has emerged as a significant evolution to navigational design to deal with user-generated content like user timelines and infinite scrolling content.

14. Popovers

Example: Facebook.

Problem: The user wants to view relevant information without losing their current place in the UI.

Solution: Show important notifications and additional information in popovers. This UI pattern has the advantage of providing a lightweight and straightforward way of viewing additional information or taking a particular action, but they do so without pulling the user out of their current activity.

Pinterest and Fitocracy use modal popovers for quick actions, and Facebook uses popovers to quickly show snippets of content from the Activity Bar. The popover UI pattern is important for actions like these because they are being performed on the data and this way users always know what these controls apply to.

With the content still visible in the background, the user can tweak sorting options or change the font size without having to go back and forth between the views – it all happens right there. Popovers and modal windows can also be used to display important notifications or notices where it’s essential to get the user’s attention because dismissing them requires a tap or swipe.

15. Slideouts, Sidebars & Drawers

Example: New York Times.

Problem: The user needs a way to navigate between different sections of the app without being distracted in each individual section.

Solution: A secondary section of the application – such as navigation, chat, settings, user profiles, etc. – is tucked away in a collapsible panel hidden under the main section when it is not needed. When accessed, it usually either moves the main section aside or slides over it. Since the slideout is in a separate layer from the main content in the application, there’s a lot of flexibility in terms of how content can be laid out inside the drawer – icons, text, and even simple controls are viable options to provide quick access to important actions here.

Often times, the drawer can be hidden under a “hamburger menu” or a simple arrow that indicates there’s more content there. It’s an easy way to hide all the less important things in a “side drawer” so that you only have to focus on how to distill the most important information in each view. Examples can be found everywhere. Asana, Spotify (search box), and Facebook (chat boxes). Some more specific examples include Houzz, which has a sub-navigation drawer that disappears as you scroll down and reappears back at the top; and the New York Times, which hides a side drawer that appears on the left when the user clicks the ‘sections’ button at the top left side of the page. As you scroll down in Pinterest, an up-arrow button appears for easy navigation back to the top, and in its ‘How It Works’ page.

16. Links to Everything

Example: Asana.

Problem: The user needs a consistent way of navigating through content without being distracted by additional content.

Solution: Most or all user content within the app is linked, giving users the freedom to explore and find the exact information they’re looking for without hitting dead-ends or being distracted by a litany of hyperlinked text, additional buttons, calls to action, etc. that you would normally see on a website. If they want to interact with a piece of content in the app, odds are that they can tap on it and go to a new view for a more detailed experience.

Content-heavy web apps like Asana and Spotify let users explore all kinds of content by clicking on it, for example clicking on an artist or user takes you to their profile, items can be clicked on, table heads can be clicked on to sort and many other actions.

Let The User Navigate

Keep track of where your users are supposed to navigate, whether they ever view the navigation elements, how often they navigate to certain areas of the application, where they’re coming from and going to in the application (i.e. the user flow) and so on. Keep rearranging, re-sequencing, re-sizing, and tweaking those navigation elements until you get more of the desired actions. And, of course, think deeply about how the user is actually using your mobile application when they’re trying to get to certain parts of the application – make sure you’re not missing something obvious.

The post The Importance of Navigation Design Patterns appeared first on Speckyboy Design Magazine.

If over 80% of new products truly fail, does it make sense for anyone to take a professional career risk by committing their time and talents to building new products? From a portfolio perspective, what must the ROI of the remaining 10-20% of successful products be to offset the costs of a development program that fails at that rate? Operationally, how long would it take to realize these returns and what manager would realistically employ time, talent and money on these new product projects?

Luckily, in reality, the failure rate is 30-49% across all industries, roughly 39-42% in software & services and technology industries, respectively,
according to nineteen peer-reviewed research studies between 1945 and 2004 (sources 1 & 2). Although the rate of failure is dramatically lower than what is rumored, the many risks of product failure cannot be understated.

Below, I talk about the many ways products can fail, how to tackle those risks systematically, and how UXPin has done so over the years.

Systematically tackling 3 types of risk

Ash Maurya, CEO of Cloudfire and author of Running Lean – Helping Entrepreneurs Succeed, offers a lot of advice about products, especially MVPs. He’s covered topics such as how to build an MVP, delivering customer value, product launches and identifying the riskiest assumptions. On the last topic, he claims there are three general approaches product leaders can take:

1. Use your intuition.
2. Start with the 3 universal risks — I’ve detailed 4.
3. Talk to domain experts.

Ultimately, you alone have to own your business model and product roadmap so having a systematic approach to evaluating them throughout the business and product lifecycle is imperative. Since the first and last approaches are arguably more risky — especially at the earlier stages of a product — I’ll only elaborate on the second approach using the Lean Canvas framework below for nailing your product or MVP.

In his post about 10x Product Launches, Maurya describes in detail how to address the 3 universal risks and I’ve summarized them below. This focused and systematic thinking about product risks was influenced by the management philosophy Theory of Constraints (TOC). Adopting the common idiom “a chain is no stronger than its weakest link,” this management paradigm assumes that processes, organizations, etc. are vulnerable because the weakest person or part can always damage or break them or at least adversely affect the outcome. As a result, managers put this philosophy in practice by focusing on a very small number of constraints that could limit their business or product “system” and restructuring those systems around the constraints to achieve more goals.

I’ve summarized the steps below:

1. Identify the system’s constraint(s).
2. Exploit the system’s constraint(s).
3. Subordinate all other resources to the constraint.
4. Elevate the system’s constraint(s).
5. Rinse and repeat.

Image Source: The 10x Product Launch.

1. Product Risk – Getting the product right:

• First make sure you have a problem worth solving.
• Then define the smallest possible solution (MVP).
• Build and validate your MVP at small scale (demonstrate UVP).
• Then verify it at large scale.

2. Customer Risk – Building a path to customers:

• First identify who has the pain.
• Then narrow down to early adopters who really want your product now.
• It’s okay to start with outbound channels.
• But gradually build/develop scalable inbound channels – the earlier the better.

3. Market Risk – Building a viable business:

• Identify competition through existing alternatives and pick a price for your solution.
• Test pricing first by measuring what customers say (verbal commitments).
• Then by what they do.
• Optimize your cost structure to make the business model work.

How teams fail to address these risks

An MVP can fail for myriad reasons. Some of these failings have been highlighted in the Forbes’ article, 8 Reasons Startups With Good Ideas Fail, but we’ve got in far greater depth below.

1. Product Failure

Image Source: LeanBlog.

• Solving the wrong problem — Overlooking the purpose of the product before building, or simply focusing on the wrong purpose. You’ll
  either end up with a product nobody cares about or one that doesn’t give you the right answers. As discussed in our Guide to MVPs, understanding the business viability of your MVP is more important than whether it’s technically feasible.
• Solving the worthless problem — Worse than having the wrong product that can be tweaked (or pivoted) to solve the right problem is solving a problem correctly, but it’s so minor in people’s everyday life that it ultimately can’t be sustained.
• Poor customer communication — You can’t solve someone’s problems correctly and if you can’t ask them the right questions.
• Not translating customer problems into correct product requirements — You understand the problem that needs to be solved but end up building the wrong solution.
• Not iterating on solutions — You understand the problem being solved and have a great idea for how to build a solution, but you don’t consider alternatives that could be far better and would give you better answers to the question’s you’re trying to solve. Lack of brainstorming, customer engagement, sketching, and wireframing and/or rapidly prototyping could hurt you.
• Overbuilding — You figure out the right solution but add too many features that clutter the valuable functionality, leading to customer abandonment or confusion which will also impact the quality of your learnings because the user feedback and data is so scattered it doesn’t make sense.
• Launching late — Again, you know the solution but then spend too much time building before launching your product. You either become disconnected from the customers you’re trying to satisfy or run out of time, money and resources.
• Lacking data — You’re not tracking or, worse, you’re improperly tracking user behavior so you can’t properly make informed decisions and ultimately (in)validate your hypotheses about the MVP. You just move onto the next product release with only one eye open.
• Lacking scale — If you don’t get enough data points, your hypotheses about what you’re building is harder to (in)validate. This is more important the bigger or more sophisticated your product becomes because it’s harder to get signal from all of the noise for the growing number of questions you have about the product.

2. Customer Failure

Image Source: “What is Customer Development?”.

• Solving one’s own needs, not customers — It’s one thing if you built a product that solves your problems and it’s another if the product only solves your problems. You need to socialize your product with others to find who actually needs your product. Then figure out where you can find more of them.
• Building for too broad of an audience — You can’t be all things to all people. You end up being a ” Jack of all trades, master of none.” The results of this are twofold: You’ll have a product that solves more people’s problems to a lesser degree but you’ll also have a harder time figuring out who to go after first. After all, it takes time, money and energy to get anyone to become your customer, and the task is even more daunting when you’re trying to make the entire World your customer.
• Not finding early adopters — Focusing on the wrong early customers can be just as bad as not having focus. If your first customers are people who aren’t in love with your product, then your product either sucks or you haven’t found the early adopters yet. Think about it. You’re solving a problem that led you to put every day of your life into building a product. You want people that would use your product every day of their life — or close to it.
• No plan for marketing and user acquisition — You have early adopters who love your product but no real way to get your product to market. Your great product will die a slow death from neglect.
• Pushing to customers, not pulling them — You can only scale so much by cold calling and emailing people. Even if your product is successful early on, you’ll need to find better ways to get inbound interest.

3. Market Failure

Image Source: Wikipedia.

• Not considering alternative solutions — You understand the problem being solved and have a great idea for how to build a solution, but you do it in a vacuum. Consider that customers have the power of choice and that you have to compete for their business. If it’s a big problem, you’re not the only one trying to solve it.
• Not charging — It’s hard to get a sense of what your product is worth to customers if you don’t charge (or at least ask them verbally early on). It’s also impossible to sustain your product if you don’t make money. While ad-based businesses often start out free or freemium, they still have a path to revenue. You should too.
• Not pricing correctly — Charging improperly can be as problematic as not charging at all. You could have a false sense of what your product is worth and not catch this for a long time. And it’s always changing based on the next best alternative, customer behaviors and many more factors. Don’t just throw discounts at customers to get them in the door. Try to really understand what your customers will pay. This could also lead to failure for many reasons.
• Not tying pricing to customer value — Along the same lines, your product typically provides different value to different customers for different reasons based on specific functionality you’ve built. Your product doesn’t offer a standard utility to everyone. Therefore, it’s important to really understand how specific aspects of your product can be segmented to get the most revenue and deliver the greatest customer value.
• Not adapting the business model to be profitable — You may have to find a new customer or a new way of getting money from your existing customers even if the product is serving a really important need.
• Not adapting the product to be profitable — Some parts of your product may make it really expensive to operate, may cause a lot of customer service maintenance, etc. Your product can impact your ability to sustain itself. It’s not just the business that could be wrong.

4. Team Failure

While Maurya doesn’t include this in his framework, the human factor in product failure is critical to consider. Forbes’ article, 8 Reasons Startups With Good Ideas Fail, is a good starting point. I’ve laid out some of the main points of failure below:

• Not taking action — Ideas and direction are worthless if nobody can deliver on them. Don’t get too far ahead of yourself with your ideas (and idealism). You’ll spin your wheels and spend your resources without getting anything tangible done. Or someone else will come in and take your spoils because you were too busy brainstorming release 10 when you haven’t finished v.1.
• Giving up — You just stop, call it quits, throw in the towel. You give up. Building an amazing product and business is hard. Don’t feel bad if it happens. Just recognize that it happened and don’t make excuses.
• Lack of expertise — Collecting data and talking with customers is great. But if you don’t know how to interpret the feedback you’re getting, you’ll be blind. And the blind leading the blind may drive you off a cliff.
• Disagreement about goals and/or direction — If you don’t have a clear objective for your MVP across the team, then your methodology and, therefore, conclusions may be compromised.

Stay Focused Or Your MVP Will SUX

Any of the above MVP failures (or a combination thereof) will produce a product that SUX — an offering with a “Sh***y User Experience.”

At UXPin, we try to address all of these potential failing points. Like many companies, we’ve certainly been guilty of building features that weren’t the most important to our customers or, ultimately, company growth. However, we’ve been aware of and addressed many of the potential failure points mentioned and the results have been incredible.

While I can’t give you exact numbers, you can at least see that we’re driving significant changes in one of several key metrics over the past few months and are on track to blow that number away as well.

The post 4 Reasons Minimum Viable Products Fail appeared first on Speckyboy Design Magazine.

In this article, we’ll take a look at some of the companies that got their MVP right and what they did to go on and launch some of the hottest products in the market today.

1. Dropbox

In his book The Lean Startup, Eric Ries, cofounder/CTO of IMVU talks about how Dropbox tackled the question of market viability by demonstrating their product in a video.

To answer the question of whether customers would want to use and pay for their file-sync solution and to justify the market to investors, Houston and his team had to “get out of the building” and put their proposed user experience in front of actual users to get feedback. Instead of digging into servers and building a high-availability, low-latency, always-on network even before they had any clue people would use it, the team decided to try something else.

Image Source: Dropbox.

They made an explainer video and started sharing it with their network to see how people would react. If a picture is worth a thousand words, then a video demonstrating your products user experience is worth a million. The 3-minute video demonstrated Dropbox’s intended functionality and resulted in signups increasing from 5,000 people to 75,000 overnight — all of this in absence of a real product.

Dropbox’s explainer video served as a brilliant validation of the market before the founders ever had to invest in the infrastructure and development needed for a high-tech product like theirs to reach a functional level in the real world. It walked potential customers through what the product is and clearly demonstrated how it would help them, eventually leading to why they would want to pay you for it.

When it comes to product development, it’s easier said than done but when you’re building an MVPs, that’s not necessarily a bad thing.

2. Airbnb

In 2007, Brian Chesky and Joe Gebbia wanted to start a business, but also couldn’t afford the rent of their San Francisco apartment. There was a design conference coming to town, and they decided to open up their loft as cheap accommodation for conference attendees who had lucked out on the hotels nearby. They took pictures of their apartment, put it up on a simple website, and soon they had 3 paying guests for the duration of the conference, a woman from Boston, a father from Utah, and another man originally from India.

Image Source: TechCrunch.

The up-close interaction gave Chesky and Gebbia valuable insight into what potential customers would want. This concierge MVP helped validate the market and prove people would be willing to buy the experience. With their initial assumptions answered, that people would be willing to pay to stay in someone else’s home rather than a hotel and that not just recent college grads would sign up, they started Airbnb (then called AirbedAndBreakfast).

3. Groupon

Andrew Mason started with a website called The Point, a platform to bring people together to accomplish things they couldn’t do alone, like fundraising or boycotting a retailer. But the site wasn’t gaining much momentum, so they decided to try out something else.

Using the same domain, they set up a customized WordPress blog called The Daily Groupon and began posting deals each day manually. When someone signed up for a particular deal, the team would generate a PDF document and email it using Apple Mail. This simple website they “cobbled together” showed the team this was a market worth looking at with just a manual-first (“Wizard of Oz”) MVP that helped them pivot their offering from what they had been doing previously.

They didn’t invest any time into developing a coupon system and designing a new website. Instead, they took what resources they had and made a piecemeal MVP out of them to test the hypothesis of whether people would be interested in what they were offering. Starting from a customized WordPress website and manually emailing PDF documents to a mailing list isn’t exactly what you’d call scaleable, but Groupon’s MVP was successful in answering that question for them.

4. Buffer

Buffer is a simple app that lets you schedule your posts across your social network, essentially letting you space out your updates so that you don’t flood your friends’ newsfeeds at one point in the day with interesting stuff you want to share. When starting out, Joel Gascoigne, Buffer’s founder, didn’t want to get stuck building a product no one wanted to use. So he began with a simple test.

Image Source: Buffer.

Buffer’s first minimum viable product was just a simple landing page. It explained what Buffer was and how it would work, encouraged people to sign up and offered a plans and pricing button for people to click on if they were interested. When they did, however, they were shown a short message explaining they weren’t quite ready yet and that people should sign up for updates. Joel used the email addresses received from the signup form to start conversations with the potential users of the app, gaining valuable feedback and insight into what they would want.

Next, they tested the hypothesis that people would want to pay for this by adding the prices table in between the landing page and the signup form. When someone clicked on the pricing plans button, they were shown the plans to see whether they would be interested in paying for something like Buffer. This showed Joel how many of the visitors to the site could potentially become paying customers. This zero-risk MVP helped Buffer identify the market and shape their product features in the coming development as well.

5. Zappos

Today, we know that people are comfortable with buying shoes online when Zappos had annual sales of more than $1 billion and was acquired by Amazon for $1.2 billion in 2009. But in 1999, when co-founder Nick Swinmurn wanted to build an online retail store that stocked a great selection of shoes, the assumption that other people would use it needed to be tested.

Swinmurn began by putting up photos of shoes from local shoe stores on a website to gauge demand for an online store. When someone ordered the shoe online, he would come back to the store and buy it. Instead of first investing in infrastructure and inventory, this gave Zappos a chance to answer the question of whether their product would be accepted by the market.

This Wizard of Oz, man-behind-the-curtain technique is used to test market hypotheses. It comes from the idea of putting on the impression of full functionality, essentially faking it until you make it. Customers believe they are experiencing the actual product, but in reality the work behind the scenes is being done manually. In the case of Zappos, by Swinmurn.

The Wizard of Oz approach is great because it also allows for greater interaction with customers at this crucial stage when you’re designing the product. The expedited learning, albeit at a small-scale, provides opportunities to test many assumptions you might be making about the product or the marketplace.

6. Twitter

Twitter traces its origins to the podcasting platform Odeo. When Odeo found the ground underneath slipping away after Apple stepped into the podcasting game with iTunes, the company started running hackathons to come up with ideas of where to head next. One result of this was an idea for sharing updates with a group of people via text messages, codenamed “twttr”.

Image Source: One Month Rails.

The first prototype was used as an internal service for Odeo employees, who eventually became so obsessed with it that they began racking up “monthly SMS bills totaling hundreds of dollars”.  This gave the team the push they needed to release Twitter to the public, but it was only at the SXSW festival in 2007 that their user base exploded when they showed off members’ tweets about the event on TV screens across the venue.

7. Zynga

Zynga is a game studio that builds social games, popularized by the likes of Farmville, which surpassed $1 billion in revenue from in-game purchases in 2013. For their game development process, the company follows a mix of landing pages and adword MVP tests to gauge interest in a planned game or particular aspect of the game.

Image Source: TechCrunch.

By running short ads in existing games and online that pitch potential game ideas and features, the company is able to gather data about which direction to steer development towards, preventing them from wasting any resources on building a game that people don’t end up playing.

8. Foursquare

Foursquare is a location-based social network that lets users check-in with their location to share with friends and family. After their first such network, SMS-based Dodgeball, was acquired by Google, founders Dennis Crowley and Naveen Selvadurai set out to work on a mobile app based network they called Foursquare.

Image Source: TechCrunch.

Backed by VC funding, they didn’t let development time slow them down, however, and launched with a single-featured MVP that didn’t bog them down in design and unnecessary features. They began with check-ins and the gamification rewards and focused on improving that side of the user experience, using feedback to mould their product.

Once they were comfortable with the basic functionality, they began adding extra features like Recommendations and City Guides years later. Additionally, they used existing services to help manage the service, for example using Google Docs to gather feedback and requests from users, which goes to show that you don’t need to do everything yourself when you start in order to build a scalable business.

9. Spotify

According to Henrik Kniberg, Agile and Lean Startup consultant and author, Spotify uses a 4-stage iterative product cycle (Think It, Build It, Ship It, Tweak It). When they launched in 2009 with a landing page, they focused on the single feature that mattered most: music streaming experience. With the desktop apps, they were able to test the market in the limited beta run, giving them time to build momentum to tackle the music industry licensing concerns that were sure to come as they planned on expanding to the US.

Image Source: Wired.

They follow the same agile process today to help scale. Each one of Spotify’s four stages are Lean since small teams are always working smartly to test assumptions. The “Think It” stage tests the merit of conceptual MVPs while the “Build It” stage releases a physical MVP only after it’s been tested for quality. The “Ship It” and “Tweak It” phases ensure long-term quality and customer alignment by releasing the MVP gradually, learning from feedback, and iterating tirelessly. We go into detail about the process they follow in our article on Building Minimum Viable Products at Spotify.

10. Pebble

Pebble is an e-paper smartwatch, arguably the one that brought the “wearables” market to the mainstream today. After investor funding dried up, founder Eric Migicovsky turned to crowdfunding site Kickstarter for fundraising and ended up becoming the most successful project there, raising more than $10 million from interested customers looking to support development.

Image Source: Pebble’s Kickstarter page.

Migicovsky recorded an explainer video to demonstrate the prototype and asked interested customers to contribute. They reached the original goal of $100,000 in 2 hours and by the end of the week had raised $600,000. When the funding round on Kickstarter ended, more than 60,000 people had pledged $10.2 million to the project and Pebble went on to develop the watch for consumers. As of March 20, 2014, Pebble has sold over 400,000 units.

Testing the Riskiest Assumptions

In his book, The Lean Startup, Eric Ries writes about how to choose what to test when designing an MVP:

“When one is choosing among the many assumptions in a business plan, it makes sense to test the riskiest assumptions first. If you can’t find a way to mitigate these risks toward the ideal that is required for a sustainable business, there is no point in testing the others.”

For most startups, the riskiest assumption is the existence of the market. For Dropbox, that assumption was that people wanted to use a file synchronization service. For Zappos, it was that people would buy shoes online. For Airbnb, it was that they would be willing to live at a stranger’s house as opposed to in a hotel. And in each of these cases, they designed their minimum viable product to answer those questions.

The post 10 Massively Successful Minimum Viable Products appeared first on Speckyboy Design Magazine.

Spotify’s vision was to give people the right music at the right time while incentivizing artists by paying them based on number of shares their music received. A tall order, no doubt, when you consider how hard it is to build out such a platform, let alone make it profitable. Yet Spotify defied the odds and grew from zero to over 1 million paying subscribers in the US — a market foreign to Spotify’s native Swedish team and one already teeming with competitors.

Source: How Spotify Stays Lean.

So how did they develop a product that fulfilled their vision without driving them into bankruptcy? They took an iterative approach combining elements from Lean Startup, Agile, and MVP methodologies.

To achieve its current 10 million paying and 24+ million total user base, Spotify set out a basic roadmap of prototyping early and cheaply, launching only when a baseline of quality was met, and then iterating based on user feedback. In this piece, I’ll explain the goals of each stage and how they all contributed to a sustainable product development cycle.

Lean & Agile at Spotify

According to Henrik Kniberg, Agile and Lean Startup consultant and author, Spotify uses a 4-stage iterative product cycle (Think It, Build It, Ship It, Tweak It) that emphasizes small teams (referred to as ‘squads’) completing small batches of work while producing a complete product. Let’s take a look at the goals of each stage:

• Think It — Decide what product to build, then build prototypes and test viability internally.
• Build It — Create a physical MVP ready for user testing.
• Ship It — Gradually release the MVP to all users while collecting data and improving.
• Tweak It — Iterate continuously based on feedback until product is shut down or revamped (returning us to Think It).

Sound familiar? It should. It’s essentially a hybrid process combining practices from Lean Startup and the Agile Methodology.

Principles of Lean

Lean Startup uses a “Build-Measure-Learn” cycle to reduce waste while achieving quality, speed, and customer alignment. At the heart of Lean Startup is the MVP, a quickly and cheaply produced quality product for learning purposes. Therefore, Lean Startup eliminates the idea that a team can build what it “knows” it will need in the future.

To that degree, each one of Spotify’s four stages are Lean since small teams are always working smartly to test assumptions. The “Think It” stage tests the merit of conceptual MVPs while the “Build It” stage releases a physical MVP only after it’s been tested for quality. The “Ship It” and “Tweak It” phases ensure long-term quality and customer alignment by releasing the MVP gradually, learning from feedback, and iterating tirelessly. Spotify does deviate slightly from Lean, however, since the “Think It” stage only tests prototypes internally — Lean emphasizes customer testing as often as possible.

Source: Entrepreneurs Love to Learn.

Principles of Agile

Lean thinking is necessary in order to develop the mentality needed for Agile practices.

While Lean is used to efficiently define and build a marketable product, Agile is the means to accomplish this in software development.

Team members from all disciplines collaborate on short bursts of work (sprints lasting 1-4 weeks), and in doing so, react better to requirements changes. The Spotify strategy stresses this collaboration by preserving the same product team throughout all four stages. These sprints are especially important for keeping resources in check during the “Build It”, “Ship It”, and “Tweak It” phases when all the heavy lifting is done. All the testing and validating in each phase also keeps Spotify on the Lean path even if product requirements must be changed to reflect customer and market needs.

I. Think It

Before committing resources to a project, companies need to evaluate the viability of the idea. The “Think It” stage consists of small teams asking themselves “Why?” rather than just “How?” At Spotify, this phase is the conceptual stage of the MVP since viability is assessed and minimalist solutions like landing pages and prototypes are used to test user demand.

Source: How Spotify Builds Products.

According to Christina Wodtke, former General Manager at Zynga, the importance of looking at viability through a business lens can’t be stressed enough. For many companies, it can be tempting to build the perfect viable product simply because they have the resources to do so. By prioritizing viability, Spotify ensures it won’t even waste time and money assigning an MVP team if the overall idea isn’t profitable.

If, however, management verifies an idea is viable, a small “Think It” team consisting of a developer, designer, and product manager is formed. At this point, the team works on creating a product definition document so that a usable prototype can be built. Using the document, they’ll seek to answer questions such as:

• Who will benefit from this and how?
• What are the key metrics that we expect this product to improve? (e.g. songs streamed, number of downloads, etc.)
• What are the hypotheses?
• How will we know if this product is successful?
• Is this a “step change” (a product yielding at least a 2x improvement on the chosen metric)? If only minor metrics improvements are expected, another strong strategic reason should exist.

The goal here isn’t to outline features or technical requirements but to create a data-focused value proposition. The heart of the product definition is narrative. And the story told by product is what the first iteration of the MVP will test.

Matchist.com cofounder, Stella Fayman, aptly states the goal of an MVP is to prove that people will use your product. Landing pages and paid ads are a great low-cost way to gauge interest because you test the basic value proposition first (or narrative, in the case of Spotify) before sinking money into anything. This is precisely what Spotify does. When developing its Mobile Free Radio (one version being “Radio you can save”), Spotify ran a Google Adwords campaign to test narratives. In doing so, Spotify exemplifies applying minimalism towards an MVP.

Once the messaging is finalized through testing, the Think It team builds low-fidelity paper prototypes and high-fidelity runnable prototypes (with fake data). Internal user testing provides feedback on which prototypes best convey the narrative until the list is narrowed down to just a few contenders.

David Aycan, Design Director at the esteemed design and consultancy firm IDEO, explains that multiple prototyping avoids tunnel vision. Ideating on different user experiences puts your eggs in different baskets (preventing over-attachment) and finds the best solution through real data instead of trying to predict what users want. Testing multiple prototypes lets Spotify find the most viable MVP by focusing on breadth rather than depth.

Source: Don’t Let The Minimum Win Over Viable, HBR Blog.

In UXPin, we can turn wireframes into prototypes rather quickly in our web app. We take a similar iterative approach to Spotify by starting out with several lightweight, even low-fidelity, prototypes and narrowing down the options from there. However, we like to involve a small subset of friends and customers in the prototype testing (unlike Spotify which just keeps it internal) since they help us “think outside the building.” Ultimately this keeps our team centered on a good customer solution instead of just a technical marvel.

Spotify, on the other hand, will only move forward if it can match the right prototype to the narrative. Because it only involves prototyping and experimenting, the Think It stage is the essence of MVP thinking — the team fails quickly and cheaply, and keeps learning until they find the exact product to build.

II. Build It

Now that a product is decided, the team moves beyond testing concepts to creating a physical MVP that is good enough to release to external users and test assumptions.

Source: How Spotify Builds Products.

The right balance of minimalism and quality must be struck with the physical MVP. Building a feature-complete product requires too much time and money, but rushing a feature-poor product out the door would embarrass Spotify and yield no useful learnings. As such, the team must create the smallest possible thing of quality that still fulfills the narrative and delights users.

As Former Apple chief evangelist Guy Kawasaki asserts in his MVP philosophy, the physical MVP doesn’t need to be perfect but it must be revolutionary. Early adopters are incredible force multipliers when it comes to early-stage products, and the only way to gain their influence is to create an MVP that embodies five important qualities — it must be:

1. Deep — Great products have just the right level of functionality and don’t become useless after just a few weeks.
2. Intelligent — Great products map specific solutions to pain points (and make customers aware of problems they didn’t even know they had).
3. Complete — Great products are completely usable, even in early stages.
4. Empowering — Great products incite users to action and encourages them to spread the news to help others.
5. Elegant — Great products have intuitive user interfaces and work the way people think they should.

You’ll see in the above diagram that the key question Spotify’s product and management team asks is “Is the MVP good enough for real users?” By making its
MVP narrative-complete and not feature-complete, Spotify is able to inherently satisfy all five qualities for a desirable and usable MVP. Perhaps, a better term for Spotify’s MVP would be MLP (Minimum Loveable Product).

The Cupcake Model, which was first coined by Brandon Schauer, CEO of Adaptive Path, emphasizes desirability and completeness regardless of iteration. The analogy states that instead of starting with an uninteresting cake and then adding filling and icing, you start with a cupcake and iterate it into a cake. That way, you invest less resources and the MVP is desirable — people will pay for a cupcake because it’s complete with filling and icing. On the other hand, a dry cake requires more resources to create and is unlikely to be good enough for real users. By following a Cupcake Model, Spotify more importantly avoids misleading conclusions: “Well, we baked a plain cake and nobody wanted it, so the cake failed and we shouldn’t bother adding frosting or filling.”

Source: The cake model of product planning.

III. Ship It

The purpose of the Ship It stage is to gradually roll out the product to all users while measuring and ensuring that the product fulfills its promise in the real market.

Source: How Spotify Builds Products.

Spotify starts by releasing to a small percentage of all users (usually 1-5%) to collect early feedback. During this stage, the hypotheses that were internally tested during the Think It stage are now externally validated.

As you’ll see in the above illustration, the beauty of this stage is that Spotify doesn’t need to get it right on the first try. Collecting data, iterating the MVP, and then A/B testing the changes allows for continuous rounds of maximized learning at minimized cost. Releasing an MVP early and to a small user base allows Spotify to iterate until it becomes an EVP (Exceptional Viable Product) that is ready for all users.

First coined by Rand Fishkin, co-founder of Moz, the EVP prevents companies from prematurely releasing an MVP that just isn’t ready to excite early adopters. Spotify understands that first impressions matter a lot, so it takes a cautious approach of having a limited release of something good before making it great and unleashing their brilliance. Based on the below diagram, Spotify releases its MVP somewhere between “Good” and “Truly Impressive” and then uses customer feedback to improve it into an EVP.

Source: Moz, “7 unlikely recommendations for startups & entrepreneurs”.

When management and the product team agree that the product is having the intended impact on the small user group (based on the product definition), Spotify will gradually roll it out to all users, while still measuring and improving.

IV. Tweak it

At Spotify, this stage is the longest, and perhaps most important. Unless products get scrapped during the previous MVP stages, they spend most of their life in this completely iterative phase.

Source: How Spotify Builds Products.

While they may have proven themselves to a certain extent in the Ship It stage, Spotify’s products are never considered feature-complete. The team continues the Ship It process of gathering customer feedback, experimenting, and A/B testing to improve the product, resulting in either major rework or just minor tweaks. But, at some point soon, they may reach a point of diminishing returns when the cost versus benefits of new features just looks less and less attractive.

As demonstrated in this article on value vs. complexity, this is an important crossroad where feature prioritization is required. While Spotify believes that no product is truly complete, it also understands the danger of feature creep. Once a product hits its “local maximum” where small tweaks won’t really improve things, Spotify’s product team and management evaluates if being at the top of the hill is sufficient, or if a higher peak is in sight. If the effort isn’t worth the time, the team will move on to other products. Otherwise, the product returns to the “Think It” stage so it can be reworked and leap to the next peak of quality. Spotify’s Tweak It stage ensures that it does not fall victim to the idea that first to market will always stay king of the hill.

Gerard J. Tellis, a professor at USC Business School, believes that product quality has become so important in recent years that network effects alone will no longer protect companies who are first-to-market. In fact, network effects actually reinforces competition for quality by driving customers to superior products. According to Tellis, the average duration for market leadership in the software industry was only about 3.8 years. When you consider that Spotify is slowly inching towards iTune’s market share as of 2014, Spotify’s evolutionary product strategy is definitely working.

More Product Stages = Less Cost, Less Risk

For many companies, one of the most dangerous mistakes is building the wrong product. They sink enormous cost into ideas that they think customers want and then speed down the path of no return.

Source: How Spotify Builds Products.

As you’ve seen, Spotify’s 4-stage product cycle helps them carefully find the right product early and build it quickly and sufficiently. The length of each stage may differ, but the constant balance between minimizing resources and maximizing product quality is consistent. Ultimately, it leads to a lower cost, lower risk, higher quality product.

We hope Spotify’s strategy has helped you better understand the roles that Lean, Agile, and MVP thinking play towards streamlining your own product development. Don’t be afraid to fail fast and quickly — as long as you keep testing, your most profitable idea might just come from what you learn.

The post Building Minimum Viable Products at Spotify appeared first on Speckyboy Design Magazine.