Startup Tools: Wireframing Tools

I recently taught a seminar on digital product design at UC Davis and included an introduction to user experience as part of the class - I agree with all those that said you can't just add UX later (whether intentional or not, every app already represents the user experience philosophy of the creators), and great user experiences happen because when considered as an integral part of building the company and the product.

My personal belief is that for most startups, the best way to tackle this is to have the product manager/product owner also own the UX philosophy - a good product manager is the keeper of a great user experience and is the last line of defense against shipping something that sucks. Often this is the CEO in early stage startups, and later someone else when the company can afford to have a dedicated product manager position.

Here are lessons that have helped me over the years:

Think in Flows, Not Screens

Web and mobile applications are primarily about making it as fast and easy as possible for a user to complete a desired task or series of tasks. Unless you're still at the most basic MVP stage, your application probably helps users complete at least several tasks, and each one of these tasks has a series of steps that the user must go through to be succesful. This series of steps is called a task flow, and when striving for a great user experience it's important to think about how to make this task flow as easy as possible.

In my design process, the very first iterations of a new feature happen entirely at the most basic level of outlining the task flow in a text editor. When drafting a task flow for a new feature, I try to remember that it's not just about describing the task I'm focusing on, but also how the new task flow relates to the existing application and the other features (task flows) it contains. How the user accesses this new feature (the start of the flow) and where they end up after they complete it (the end of the flow) are as important as the steps in between.

Additional info: Chapter 3 in Robert Hoekman, Jr.'s excellent Designing the Obvious - A Common Sense Approach to Web & Mobile Application Design and Jason Putorti's 10 Things You Need to Know About Design.

Understanding Mental Models

If you're a technical founder or product lead, remind yourself that your users don't see the source code of your application. This may sound obvious, but it's easy to forget that your users don'tknow why you designed a feature a particular way, they don't have the benefit of understanding how all the pieces of your app fit together, and they don't really care about the functional processes going on behind the scenes, except when things don't work the way they expect.

Real users understand products through a process of discovery and trial and error, and as they use your application they slowly develop a mental model of how they think it works. A mental model is effectively their internalized understanding of the task flows in your app. The process of building a mental model can be artificially supplemented through tutorials, tooltips and other learning aids, but the best user experiences are designed so that the application itself helps the user quickly build an effective mental model, without relying on additional learning aids to convey key information.

Additional info: Chapter 5 in Designing the Obvious - A Common Sense Approach to Web & Mobile Application Design.

Don't Re-Invent the Wheel

When designing the experience for a feature, think about how other applications address similar task flows. Humans are natural pattern matchers, a trait you can leverage to accelerate the construction of effective mental models by relying on existing design patterns that many users will already recognize from their previous experiences.

Design patterns are often platform-specific (especially on mobile) so it's important to build and maintain familiarity with platform standards and design patterns used in popular applications (apps shipped with the OS are a great place to start).

The same point applies internally to your own application. If you have two features that are related in terms of similarity of task flow or the goal achieved upon completion, try not to re-invent the wheel. In the common case where you're adding a 2nd feature where the flow is similar to an existing feature, consider refactoring the UI of the first feature to accomodate the needs of the new feature, keeping the interface harmonious and consistent. Just like your codebase, the user experience of your app will accumulate cruft over time - you will have to go back and rework things as you iterate.

Additional info: Theresa Neil's Mobile Design Pattern Gallery - UI Patterns for Mobile Applications - skim it once, then try to refer to it when specing new features or refactoring old features. See also Google's official design patterns for Android and Apple's iOS Human Interface Guidelines.

Finally, as a founder or employee of a company building a product, you need to know that you are not your average user. Even if you started your company to scratch your own itch or solve a problem you have and you're trying to serve a target market of people similar to yourself, you spend at least 100x more time thinking about your product than any of your users do.

The difference in your level of understanding vs your users is often a source of angst (especially for technical people), and is commonly surfaced in you or your team's negative reactions to user support requests. If you find yourself dismayed at the apparent lack of intellegence of your users, you're guilty of falling into this trap.

Building and maintaining empathy with your users is key to a great user experience. When you're deeply involved with the creation of a product, you can no longer depend on your own intuition to maintain this empathy. Talking to real users is an effective solution, and it doesn't need to be costly or time consuming. If you've never done it, you will be astounded by how much you'll learn in a half day, informal usability testing session where you spend time with 3 actual users who don't work at your company.

Start running your own quick and dirty usability tests: skim Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems, watch the example usability test video, hire testers on TaskRabbit, and get to it!

As a designer & founder, Brad Feld's recent post Who Owns Your UX Philosophy? asks about an area I've spent quite a bit of time working on. User experience is a a tricky skill set to build or hire for, as it requires a mix of traditional design and product management skills that I think are best learned through apprenticeship rather than traditional academic design education.

I recently taught a seminar on digital product design at UC Davis and included an introduction to user experience as part of the class - I agree with all of the commenters on Brad's post who said you can't just add UX later (whether intentional or not, every app already represents the user experience philosophy of the creators), and great user experiences happen when considered as an integral part of building the company and the product.

My personal belief is that for most startups, the best way to tackle UX is to have the product manager/product owner also own the UX philosophy - a good product manager is the keeper of a great user experience and is the last line of defense against shipping something that sucks. Often this is the CEO in early stage startups, and later someone else when the company can afford to have a dedicated product manager position.

Here are some UX lessons that have helped me over the years:

Web and mobile applications are primarily about making it as fast and easy as possible for a user to complete a desired task or series of tasks. Unless you're still at the most basic MVP stage, your application probably helps users complete at least several tasks, and each one of these tasks has a series of steps that the user must go through to be succesful. This series of steps is called a task flow, and when striving for a great user experience it's important to think about how to make the task flow as easy as possible.

In my design process, the very first iterations of a new feature happen entirely at the most basic level of outlining the task flow in a text editor. When drafting a task flow for a new feature, I try to remember that it's not just about describing the task I'm focusing on, but also how the new task flow relates to the existing application and the other features (task flows) it contains. How the user accesses this new feature (the start of the flow) and where they end up after they complete it (the end of the flow) are as important as the steps in between.

Additional info: Chapter 3 in Robert Hoekman, Jr.'s excellent Designing the Obvious - A Common Sense Approach to Web & Mobile Application Design and Jason Putorti's 10 Things CEOs Need to Know About Design.

If you're a technical founder or product lead, remind yourself that your users don't see the source code of your application. This may sound obvious, but it's easy to forget that your users don'tknow why you designed a feature a particular way, they don't have the benefit of understanding how all the pieces of your app fit together, and they don't really care about the functional processes going on behind the scenes, except when things don't work the way they expect.

Real users understand products through a process of discovery and trial and error, and as they use your application they slowly develop a mental model of how they think it works. A mental model is effectively their internalized understanding of the task flows in your app. The process of building a mental model can be artificially supplemented through tutorials, tooltips and other learning aids, but the best user experiences are designed so that the application itself helps the user quickly build an effective mental model, without relying on additional learning aids to convey key information.

Additional info: Chapter 5 in Designing the Obvious - A Common Sense Approach to Web & Mobile Application Design.

When designing the experience for a feature, think about how other applications address similar task flows. Humans are natural pattern matchers, a trait you can leverage to accelerate the construction of effective mental models by relying on existing design patterns that many users will already recognize from their previous experiences.

Design patterns are often platform-specific (especially on mobile) so it's important to build and maintain familiarity with platform standards and design patterns used in popular applications (apps shipped with the OS are a great place to start).

The same point applies internally to your own application. If you have two features that are related in terms of similarity of task flow or the goal achieved upon completion, try not to re-invent the wheel and maintain two similar but slightly different patterns. In the common case where you're adding a 2nd feature where the flow is similar to an existing feature, consider refactoring the UI of the first feature to accomodate the needs of the new feature, keeping the interface harmonious and consistent. Just like your codebase, the user experience of your app will accumulate cruft over time - you will have to go back and rework things as you iterate.

Additional info: Theresa Neil's Mobile Design Pattern Gallery - UI Patterns for Mobile Applications - skim it once, then refer to it when specing new features or refactoring old features. See also Google's official design patterns for Android and Apple's iOS Human Interface Guidelines.

Finally, as a founder or employee of a company building a product, you need to know that you are not your average user. Even if you started your company to scratch your own itch or solve a problem you have and you're trying to serve a target market of people similar to yourself, you spend at least 100x more time thinking about your product than any of your users do.

The difference in your level of understanding vs your users is often a source of angst (especially for technical people), and is commonly surfaced in you or your team's negative reactions to user support requests. If you find yourself dismayed at the apparent lack of intellegence of your users, you're guilty of falling into this trap.

Building and maintaining empathy with your users is key to a great user experience. When you're deeply involved with the creation of a product, you can no longer depend on your own intuition to maintain this empathy. Talking to real users is an effective solution, and it doesn't need to be costly or time consuming. If you've never done it, you will be astounded by how much you'll learn in a half day, informal usability testing session where you spend time with 3 actual users who don't work at your company.

Start running your own quick and dirty usability tests: skim Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems, watch the example usability test video, hire testers on TaskRabbit, and get to it!

• Jesse James Garret's The Elements of User Experience will help you understand how UX relates to other design disciplines and think through the layers to be considered from user needs/task completion all the way through to the presentation layer.
• The personality your product expresses can have a big impact on how users perceive the experience of using it. Designing for Emotion is a great place to start thinking about this facet.
• If you're working on mobile UX specifically, Tapworthy provides a concise intro to some of the common issues and pitfalls you should think through.