I would rather have a company acknowledge that no one owns UX than have them push their personal user experience desires as the UX agenda. Everyone has a personal opinion that comes from their personal interactions with the application, but an effective UX designer puts aside their personal desires in favor of the needs of the user(s).

Effective UX is about observation, experimentation, measurement and iterative evolution (IMHO). Since software can have usable UI without UX, many companies find it hard to invest in UX because they find it hard to measure the tangible value. Or they invest just in UX research, without investing in the full resource suite behind it required to implement and measure it’s effectiveness.

I’ve lived through companies where UX took 3-4 months to evaluate one user flow where no changes were ever implemented. I’ve also experienced the “blue versus orange button” epiphany where a simple color change skyrocketed conversion.

Just like a tech company needs to “be Agile” and not “do Agile”, we need to all get better educated on what UX is, understand we’re not the experts at it, and we need to radically evolve our fundamental mindset when we approach UI design.

UX is theoretically where startups should be killing the big incumbents. Once you have a mature product, it’s really hard to account for all the dependencies and features nooks and crannies that you’ve accumulated over time. As startups we don’t have any excuse. We have a relatively blank slate. I’d argue that the enemy of UX isn’t lack of attention to it – it’s all the dead weight features that get built and ultimately aren’t that useful, that just consume real estate, create data tables that have to be cross referenced, and get in the way. It’s so hard to strip out things after you’ve introduced them, and the UX suffers most. Ironically, I’ve also found that “personalization” features that we try to build tend to muddy the UX more than help it. Go figure.

Brad – so glad you blogged about this! Lots of great comments already so I won’t rehash them but the points that resonate with me the most are 1) good UX is invisible 2) UX is NOT the same as UI 3) its almost impossible for consensus-driven startups w/o a person owning UX (and knowing what they are doing) to do this right, and 4) its not helpful to say UX is the product and dismiss this. There are thousands of successful products with terrible user experiences. Rather – its what makes some products truly great and loved by their users IMO.

At Filtrbox I was super focused on getting features out while holding onto the 3-clicks-or-less approach, but it wasn’t holistic and our UX showed it. (Note to self – pick a UI stack you can iterate stupid-fast on). On a related note – I do have to give Jive Software a lot of credit in the UX department. The team there is super passionate about UX and has dedicated folks (NOT UI devs, not designers) who work on improving and streamlining the product around the key use cases so “it just works”. Jive has a ton of functionality that shows itself at the right time. Their latest releases really show the work here – its way deeper than UI. The software/interface disappears eventually as you get work done.

I agree with awaldstein that the UX is the product, and I agree with bfeld that someone really need to own the UX.

As the Founder and CEO designer of an ipad app game and complimentary physical products, I’m being told that I have quite a bit of Steve Jobs in me regarding how tightly I control my UX and how fluid and elegant I want the experience. I am applying for a patent on the app, for now the design is so clean it can be applied to other data sets.

I completely agree that there should be a seamless experience for my user, especially since my youngest will be around 4. I have never designed an app before, and there are some challenges to work in that space, but I take clues from other apps I like and am mindful of the mistakes of others.

Mr. Brad Feld, I love what you said here: “Some are crafted beautifully from a UI perspective, but once I start using them on a daily basis I want to scream.” And, thank you so very much for sharing your thougths on this matter.

I see a lot of great comments here pointing to the ownership of UX and the consistent point of decision and direction. I agree this needs to occur to have any hope of and application (or dare I say a suite of applications) to have a consistent enough feel for users to be happy with the day-to-day experience vs. the happy sales meeting.

One thing I find however when working on new systems or revamping old systems is that it’s not enough to just have an identified person in control of this but you need an architecture for interaction. Yes I know that architecture in software can be considered a dirty word but bear with me for a moment.

When I’m talking about UX architecture I’m speaking in the terms a brick and mortar architect would about the consistency of interaction with the space. This person needs to think not only about how the interactions will occur and in what way those should direct the response of the application, but also about where the user came from, why they might be there and who they are. If these questions can be consistently answered, the experience can be driven very simply, basically your take them to the item they need in the most expedient fashion. I see a lot that applications are developed generically without taking these role and responsibility potentials into account which leads to many different ways to get to a piece of content. This seems to stem from the application developers not being quite confident about where the users should go first. I think this is the core of the responsibilities of the UX architect, in that they are focused on understanding the who, when, and why’s of user interactions in their systems and the rest will fall out.

I recently taught 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 they are baked into the company or product from day 1.

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.

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.

You Are Not Your User

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!

My feeling is you need one person to own it, and because customers and product are always changing, you need to always be testing (ABT?)

Great post Brad.

I’m a CEO of a cloud computing startup and I am completely obsessed with creating an awesome user experience. Too many times, people make things way too complicated and populate platforms/applications with tons of useless features – drives me nuts. I believe that if it’s not brain dead intuitive and super easy to use, adoption will be severely impacted and the product will ultimately fail. This is my first time owning UX and I wouldn’t have it any other way. I think it’s an extremely fun process and one that I really enjoy being a part of and am very passionate about. We have done other things to increase our odds of creating a great product and great user experience:

1. Teaching customer day 1. I think this has been one of the most beneficial things for us. We understand quite well how the end market users do their job today and how we can make it easier/quicker/much less painful. Lliterally working side by side with a teaching customer has really been enlightening. They tell us how painful the current apporach is when doing their job and what would be ideal to them and what they care most about. They want quick, simple, intuitive, effective. Dont assume you know what they want. Trust me, it’s a huge mistake to make.

2. Our UI guy is involved in the process along with myself and our teaching customer. We discuss as a group features that need to be implemented, whiteboard flows, I usually come up with a sketch of how I see it being visually represented and working, Then my UI guy will take my chicken scratch and create a mock up version with suggested improvements and something close to look and feel. We’ll then run this buy the customer to get his reaction and feedback and discuss as a group what works and what doesn’t, then make additional changes/modifications until they like it. Once the customer is happy, then we build the page(s).

The customer’s feedback tends to take a pretty high priority in terms of the product usability direction. I’m ultimately the one that decides from the company standpoint, but I let my UI guy actively weigh in, since he has a lot of experience. There are times I choose his approach and times where I take things in a different direction based on our teaching customer comments and my own gut instincts.

3. We’re very focused on getting out the initial functionality to our first customer and get them to start using the product extensively. We will then take the feedback on what works well and what needs to be improved and continuously iterate until we collectively feel we have it going in the right direction. Then we’ll bring on more Alpha and early Beta customers.

4. Our UX philosophy is:

* Keep it SIMPLE!!!
* Listen to our customers and use their feedback and suggestions – they’re the ones that have to live with our product, not us
* When in doubt, take stuff out
* Get it functionally correct, then worry about making it pretty/sexy
* Use common sense
* It has to be brain dead intuitive – give it to people who dont understand the app and see if they can use it successfully – if they can’t, back to the drawing board
* Provide a help panel that actually helps

Since this is my first time through this process, not clear that it will work as planned, but I trust my gut.

Great article and love the comments. UX should be owned or at least part of a holistic branding approach. Brand experience, if done correctly of should be aligned to cognitive models or patterns of the intended user/audience.

Lean UX residency (luxr.co) and Cooper (cooper.com) both teach advanced courses and offer training workshops to startups and executives on how to tighten their UX product and process. There are also a few top design consultants in the Bay Area I could recommend who do exclusively UX (not UI). Finally, Amy Jackson is an awesome designer recruiter who might be able to find your startups a full-time UX product owner.