Bokardo: Social Web Design
November 12th, 2012
Applying the Fundamental Attribution Error to Product Design
by Joshua Porter | Responses | shortlink: bokardo.com/p/2154
From the Wikipedia: “In social psychology, the fundamental attribution error describes the tendency to over-value dispositional or personality-based explanations for the observed behaviors of others while under-valuing situational explanations for those behaviors.”
In other words, we tend to undervalue the environment when explaining the behavior of others while overvaluing someone’s personality. This seems right…and makes sense because we often don’t know the situation someone else is in and so go by what we know: their personality.
The fundamental attribution error directly applies to product design. Think about the common problem of designing a new product for a particular market. We want to find product/market fit, right? Well, one of our first inclinations might be to find an existing market and then try to figure out what product might be useful for them. This happens a lot, and the markets are often looked at from a personality-based standpoint. Oh, I’m going after the 20-something hipsters market. Or I’m going after married women in their 40s who drive a Range Rover and want to enjoy life. We imagine people within these groups to have similar personalities…and they might.
To look at markets from a personality-based standpoint is to fall prey to the fundamental attribution error. It’s as deadly a trap as is a demographic-based standpoint. What we must do instead is to look at people’s behavioral similarities to discover really valuable markets for product design.
People can be very dissimilar demographically and personality-wise but still have the same basic needs. Imagine two people getting married: one a 45 year old woman and the other a 24 year old man. A traditional marketing and product focus would treat these two people very differently…they are in different life stages, different careers, different family sizes, etc.
But both are doing very similar activities at the moment, and their needs overlap more than anybody else right now. For the activity they’re trying to complete (getting married) they have to do the paperwork, plan a ceremony, hire caterers, invite others, choose a venue, etc. All of these things have extremely similar steps, and a product/service that might support them can come really close to supporting both. There will be differences, of course, in the taste of the two people, but the actual activity at hand is extremely similar.
That’s why the fundamental attribution error is so important…because these two people seem really different. They come from totally different backgrounds, have different goals at the moment, completely different demographics, and opposite personalities. But from a product design standpoint…their needs are almost the same.
So the takeaway is that when designing products we should avoid the fundamental attribution error by emphasizing the situation in which our users find themselves. What activities are they trying to complete? What are the constraints of that activity? What environmental factors change their options? What are the common friction points for people doing this activity? By systematically emphasizing the environment in this way we can begin to see the patterns in behavior that result not from personality but from the shared human activities we all take part in.
November 6th, 2012
Sometimes Design is Pulling your Clients into the Future
by Joshua Porter | Responses | shortlink: bokardo.com/p/2142
The pushback on your design is not always obvious or visible. It’s not always direct or forceful. Yet there it is, a subtle brushback you get when trying to design something new and different. Maybe it comes in the form of polite but negative feedback. Maybe it comes in the form of a political campaign against you. Or maybe it comes in the form of being ignored…they’re just going to ignore you and hope you go away.
But you’re seeing the future that they don’t see. That makes you different from them on most days. You have to see the future…in fact it’s your job to visualize and design new things that don’t exist yet. You are planners who plan for a future in which today’s problems are solved. For many people the future is uncertain and only means change, which means the pain of not knowing something yet. The future can be scary for a lot of people. But the future is not scary for you.
Designers: Unsatisfied and Optimistic
Designers hold two opposing thoughts in their mind at the same time: you are at once unsatisfied with how things are and optimistic about the future. That’s an odd combination if you think about it. Most optimistic people are not unsatisfied…and most unsatisfied people are not optimistic. Holding those two ideas in the mind at the same time is not easy…it can be a manic ride. Wow…that totally sucks! Ugh…devastated. But WAIT…what if it were like THIS! That would be awesome…let’s go build it!
Any designer who has worked professionally knows that it’s not just about the design, though. It’s about your clients, the stakeholders you’re designing for. You have to make them happy and do work that they appreciate so they’ll tell their friends and you’ll get more work. Or, if you’re at a larger company, you have to show and tell whenever you do design work to point out those details of the future that only you cared about. You have to point out why the future is brighter than the present.
Sometimes other people can see the future with you. But sometimes they can’t. And sometimes your job as designer is to pull your clients, despite their protests, kicking and screaming into the future.
October 31st, 2012
What you should know before you launch your product
by Joshua Porter | Responses | shortlink: bokardo.com/p/2124
The common refrain “We don’t know anything until we launch” is completely false. Here’s why.
At a recent design meetup here in Boston I was talking to a product manager who was anxious about an upcoming release. He was talking about several new features they were adding that they had high hopes for but didn’t know how well people would use them. To sum up his thoughts he said “Well, we’ll just have to wait and see what happens after we release. We don’t know anything until we launch.”
My first reaction was to agree wholeheartedly…it just sounds right. And I have long been fond of this quote by Mike Tyson: “Everyone has a plan until they get punched in the mouth”. So I agreed with his notion that you can’t know anything until after you release your product.
This product manager isn’t the only one who thinks this way. Every day I hear someone say or write about how you just have to release your product to know anything at all…there is a general ethos that shipping is the only way to know if something is going to work or not. And it’s the way software is going…tools that let us ship faster and faster lead us to believe that shipping is the only crucible upon which wisdom is gained.
What you CAN’T know
Yes, it’s true that there’s a lot you can’t know when you release. Some things are just not predictable until your product actually hits the market and people use/purchase/try it out in a real setting. Here are the big things you can’t know:
- You can’t know if your product is going to succeed.
- You can’t know if you’ll make lots of money.
- You can’t know if you’ll have a high viral growth coefficient.
Each of these things are answered only by the actual market, the group of people who you end up offering your product to. Just like an Olympian can’t know if they’re going to win a medal without actually performing on game day, you can’t know if your product is going to be a success in the market without actually releasing it to the market. But that doesn’t mean the only way to learn anything is by shipping.
What you CAN (and SHOULD) know
There are many things you can…and therefore SHOULD, know before you launch. Most of these things are crucial to the success of your product and therefore greatly affect your success in the market. Knowing these things earlier will help you improve your chances when you do end up launching.
- How usable your product is: You can know if your product is easy to use. Not just whether people can use it, but can they use it well. It is easier to use than what they currently have, or is it harder?
- How clear your messaging is: You can know if your product is easily understood in the marketplace. This is crucial for new products…even if they are easy to use do people understand what purpose they serve and whether or not they should pay attention to them?
- How valuable your product can be: You can know if your product is valuable to someone, not everyone. Do they enjoy using it and find value in it over time? This is essentially what we need to know in order to have a successful product, and it’s possible to find out with a small group before launch.
Not only that, but you can know some of these things before the first line of code has been written. Before you even hire a developer, you can have a working, clickable prototype that gives you confidence you’re heading in the right direction.
So how much can you know? A lot. How confident can you be before a release? Very.
The Basic Tools
With a simple toolkit you can have all of these things.
- Clickable mockups. Clickable mockups are interfaces that don’t really work but are clickable and appear to work. You can use these to get a tremendous amount of insight into the value of an interface without ever writing a line of code. We use these very successfully at HubSpot to know if we’re on the right track…just last week we completely changed direction because the clickable prototype we were using just wasn’t the right model, saving a tremendous amount of time down the line. You can easily create clickable prototypes in Adobe Fireworks or with tools like Invision.
- Usability testing. Usability testing is the best method to give you specifics about what’s working and what’s not working in an interface. It gives you details that no other method gives you, such as whether an interface element makes sense or whether button text is right. If you believe that details make all the difference then you must usability test. Don’t trick yourself out of usability testing by saying you’ll get plenty of feedback from real users when you launch…while that’s valuable it’s a different type of feedback. Test both clickable prototypes or live software.
- Private beta periods. Once you’ve tested clickable mockups and moved on to build the actual software, roll it out in a private beta. You can tell a lot about whether or not people will actually adopt something by giving it to them this way. It won’t tell you much about the finer details like usability testing but private beta testers do give you a good coarse look at usage and anything bigger you might have missed. If you can’t get people using your software in a private beta, then you probably shouldn’t launch.
Usability testing and interface prototyping give you something most people lack when going into a launch: confidence. They can’t say whether your venture will be a success, but they can tell you if people find what you’ve built easy to use and understand. That’s half the battle. And just like an Olympian practices every day for years before they finally step onto the field, you should be testing and prototyping most every day until your product has proven itself ready to launch.
August 3rd, 2012
Why lurking (and de-lurking) in social networks is a big deal
by Joshua Porter | Responses | shortlink: bokardo.com/p/2117
The latest story on lurking at GigaOm (they are covering this topic nicely): Thanks to Quora, now you can’t read anonymously
Lurking is the number one activity on the Web. That is, looking at other people’s profiles, photos, blog posts, and other information with the knowledge that they probably don’t know that you are doing it. Since the beginning of the Web this has been implicit…never a stated rule but understood by everyone.
Lurking is the primary activity on Facebook.
When the observed party knows they’re being observed, everything changes. Not a small change, not a tweak in behavior or a “hello there, thanks for checking me out”, the entire process is completely changed forever. The relationship between those two people is permanently altered, for better or worse.
There have been many instances when software has been built to surface lurking. Some email clients used to let you know when someone read your message…and almost everyone turned it off. There was an app on Facebook early on that let you see who was viewing your profile…the observed liked it (the observers hated it) and Facebook killed it. LinkedIn, of course, charges for the privilege to see who is looking at your profile.
Imagine being able to have a record of everyone who looked at you (or things about you) as you moved throughout your life. You would quickly notice patterns that you normally wouldn’t, and everything would change. In fact, much of interpersonal interaction is a dance of observing discretely…
Imagine also that some other human could see through your eyes everyday and know what you look at. It’s not that you might have a lot to hide, but it surely would change many of your relationships. Who knows…maybe we would empathize with others more…knowing what they pay attention to?
I’m not sure what the answer is for all of this…but I do know this road will be anything but smooth.
August 1st, 2012
Stating the Obvious
by Joshua Porter | Responses | shortlink: bokardo.com/p/2107
It could be that your users are always attentive, always aware of what’s going on with you and your product or service. They are always up-to-date with what you offer, where they are in their progress with you, what account they’re logged in with, what payment plan they’re on, and what they were doing last with your product.
Or, it could be that they’re just like the rest of us and trying to stay afloat while their attention is being pulled in a thousand directions at once and could use you reminding them what seems like it should be obvious.
A couple points about obvious:
- Obvious almost always isn’t. With the sheer number of different world views people have these days one person’s obvious is another person’s revelation.
- Nobody minds when we state the obvious. Not even geniuses. That’s because it’s a helpful part of normal human communication…where we set context in talking with others. It builds confidence that we understand each other and are on the same page. It is often necessary before jumping to that the next step in the lifecycle.
- In UI design, obvious is usually about describing a user’s current state. As I wrote about in Designing for the Next Step, communicating the current state is a crucial part of preparing someone to take the next step. To gain confidence about where we might go we first need to know where we are.
The other day when I logged into Google on my iPhone I was presented with a simple little message telling me what account I logged in with. (I have three Google accounts…I think)
As a designer it would have been super easy to assume that this wasn’t necessary…indeed for a while Google didn’t tell you what account you logged in with, but then it became frustrating when you tried to access your Gmail or Calendar when you were logged in with a different account. By stating the obvious (that you just logged in with a certain account) Google is making it more likely that you don’t have this frustration anymore. (granted the mere fact that we log in with different accounts to the same service is a problem in itself…this is a decent solution for the current structure of Google’s service)
In short, stating the obvious too often gets a bad rap. But when the first priority of user interface design is clarity, often the most important thing we can do is to state the obvious.
July 20th, 2012
Is design building interfaces or solving problems?
by Joshua Porter | Responses | shortlink: bokardo.com/p/2099
I’ve been talking with a lot of designers lately and it’s clear to me that many of them(us) are struggling with development processes that aren’t always design-friendly. The other night, for example, I made the off-hand comment that it’s hard to organize design efforts in sprints because not all design problems are two weeks long.
The response I got surprised me…it was “thank God I’m not the only one who feels that way”. It was relief…I think a lot of designers working at startups and other places where sprint-based work is being done are feeling this pressure…they are forced to work within schedules that aren’t always conducive to the way they want to work.
It depends, of course, on your view of design.
If you view design as “we need an interface for this” then you can more easily schedule a fixed amount of time for building the interface. How long does it take to mock something up, get it into HTML/CSS/JS, and fully integrated with the backend? Those steps are roughly predictable if you know how many screens you’re creating and the process of mocking up is not much more than going with your first decent guess. From an development perspective this is the ideal case…a predictable design process that takes roughly the same amount of time every time.
But if you view design as “problem solving” then all bets are off. In this case it may take an hour or a week to figure out a solution to a design problem…it depends on the problem and the tenacity of the designer. This makes the initial design phase more unpredictable because your first decent guess is almost always wrong or inelegant (as usability testing often shows). And this makes it more difficult to schedule…and it’s why design doesn’t fit into fixed-time sprints very well.
The second view is the view of most designers I know. What motivates them is that they love solving problems…they are unsatisfied with the status quo and want to improve things. They get their kicks out of solving problems with interfaces as solutions, and the thing they hate the most is an interface that doesn’t truly solve a problem (but purports to). And because solving the problem is the goal some designers keep working through deadlines…in the same way that a Sunday morning crossword puzzle can stretch into Sunday afternoon simply because it’s not solved yet.
So if you view design as merely building interfaces then you can schedule that work relatively easily. But if you view design as problem solving then it’s probably better to have a separate design process out in front of your development sprints that allows designers to adapt to the problem at hand.
Update: Josh Seiden was kind enough to respond with this post: Team Problem Solving, suggesting that we not get caught up with simple time periods and work to be more collaborative.
May 8th, 2012
New Resource: Principles of User Interface Design
by Joshua Porter | Responses | shortlink: bokardo.com/p/2088
I’ve just published a new resource that I hope is useful: Principles of User Interface Design. It contains a list of 20 or so design principles that I refer to all the time. This was a good way to get them down into one spot…so I can point people there in the future.
You’ll also notice that the page is very simple and (I hope) extremely easy to read. I wanted to start from scratch and really simplify the page much more than a normal blog post and make it easily readable on mobile devices as much as larger screens. I first started using media queries and planning out different style sheets for different devices…I had an iPhone style sheet and an iPad style sheet. But as I simplified and simplified, it occurred to me that I might be able to get rid of media queries all together. So that’s what I did. There are only 13 CSS rules to the whole page…
So please let me know if you have any feedback on the new principles page…it is a work in progress and I’ll be improving it over time.
January 16th, 2012
Designing for the Next Step
by Joshua Porter | Responses | shortlink: bokardo.com/p/2041
Note: this is an excerpt from my forthcoming book Make them Care!
In a recent post (Why you should bury the sign up button) I told the story of a redesign I did in which people just didn’t want to click the “sign up” button on the home page, no matter how beautiful or sexy that sign up button was. What I realized from that project is that there are cases in which no amount of visual design will significantly improve the state of things…instead we need to focus on making people care.
Here’s another example. On cyber Monday this past November I received an email from the New York Times informing me that I could save 50% on a Times Digital Subscription. It was time sensitive…offered today only, so I had to act fast in order to take advantage. While I don’t read many emails like this, I did read this email because I think the New York Times is one of the better news outlets out there (although now I’m not so sure) and I have an iPad that I enjoy reading on. Perhaps the Times had something interesting here, so I kept reading. Here’s the email:
I ask you to notice several things about this:
- It’s an offer about money. The primary content of this email is about the savings one would get for taking advantage of this offer. “Save 50%” is the first text you read and the most visually heavy content on the page. Variants of the message of “saving” are repeated throughout the email. The number one message this email communicates is that I can get a very good financial deal here.
- The email assumes the value of the offer is already known. There is almost no information at all about what a digital subscription from the New York Times is. The only clue are the few words in this sentence: “Award-winning articles, videos, blogs, and more – it’s all wrapped up in a perfect package…”. That is the only description of what one would actually get with this offer.
- I have to make up my mind immediately. The only call-to-action on this page is “Get it Now”. Clearly this is designed for people who already know they want a digital subscription, or have decided to get one after reading this email. People who click that button are people who have made up their mind…who have already decided that now they want to get it.
Well, even though I’ve read the Times online for years I have no idea what a “digital subscription” is. I can already read the Times on my computer, my tablet, and my smartphone (I simply visit nytimes.com or the nice Skimmer app), so I’m already receiving the Times “digitally”. What exactly is different about a digital subscription? The only thing I know about it is that I’m not currently paying for the Times but with a subscription I would have to…but I have absolutely no idea what I would get by doing that!
A Straight-forward Fix
The design solution to this is relatively straight-forward.
The first piece of missing information is my current status as a New York Times reader. Tell me what I’m currently getting by stating it plainly. Say something like: “You currently enjoy the free Times online edition, which includes loads of free content, including top news, sports, and political news”. This could be in pretty good depth, too. Reiterate the amazing breadth of content that the Times offers for free online…and perhaps showcase one or two amazing stories of late. It’s easy to assume that readers/users/people know their current status but in many cases they will not.
The second piece of missing information is the difference between where I’m currently at and where I could be…what exactly is being offered here? Explain what is included in the digital subscription. What additional content, commentary, and news is delivered if one were to subscribe? Is there a different delivery mechanism or app I would use on my various devices? How are they better? And don’t be generic here…”videos” and “blogs” are not compelling features of a digital subscription! I’ve got those in spades, baby. Show me…dive deep into the details about how this experience is superior to the one I currently have. The design problem here is to answer the question of what makes the Times videos and blogs different and better.
Remember that comparison is how people make decisions. The email the Times sent does not allow me to make the comparison they need me to. By sending an email with merely an offer to pay money the only comparison I can make is between not spending money and spending money…think about that for a second! I think we all know which one will be chosen. Choosing to not spend money is the rational choice here. So give people something to compare! Show the comparison between these two sets of information side-by-side and let people compare what they’re getting with what they could get. Paint a beautiful future for them! Never assume that people know anything about an offer…and strive hard to clearly communicate that comparison every single time you make the offer.
The Times email problem and the sign up problem from my last piece are similar. The designer(s) are trying to compress a process that takes time into an immediate decision with little information. In both cases the conversion rate is going to be low…very low…I would bet dollars to doughnuts the Times was not overwhelmed with the success of their Cyber Monday email campaign.
Designing for the Next Step
I call these design failures a failure to “Design for the Next Step”. When designs fail to provide an appropriate next step for users it stops them in their tracks. They simply click away to another web site, stop using an app, or otherwise leave.
So let’s dive into this fundamental problem of interaction design. It is easiest to start by putting the problem in context. The Usage Lifecycle shows the progression someone makes as they use your software over time. From a practical standpoint most people go through stages as they learn about, try out, make the decision to use, and continue to use your software.
Here is an example of what the Usage Lifecycle looks like:
We can also dive down a level deeper and look at a stage in more detail. Here is how we might find the “Interested” stage of the Usage Lifecycle:
These steps are stable for most software. When we fail to design for the next step, we break this progression in some way. Most designs suffer from one of the following ways to blunder:
- Moving too fast through steps. When you give people too little information and ask them to continue to the next step anyway. You’re asking them to move too quickly through a process that takes time. This happens a LOT, and usually results from a lack of context given by the designer. Too little explanation, too many competing screen elements, not enough examples or supporting content, all of these things contribute.
- Skipping a step. When you completely skip an important step. This usually happens early on in design…you simply don’t make it very far if you’ve skipped a step as your usage plummets.
- Steps out of order. Asking for billing information before showing shipping rates on e-commerce sites is a common example. This tends to stop people in their tracks, as people want to know what they’re going to pay before they enter their billing information. This is exacerbated because shipping costs are often higher than expected. This is common in app design as well. Using templates is an interesting example…sometimes you choose a template before creating a thing and sometimes you want to create the thing first. I’ve seen both ways make sense, depending on the object in question.
- Showing a step too early. Timing is important, too. Take pricing, for example. Pricing is a signal, and if your pricing is relatively high it is easy to dissuade people from buying if you show them prices before you’ve convinced them of the value of your product. Another example is asking people to share your app with friends upon initial entry…while you may get some activity from happy clickers, you are asking your users to share something they are not yet familiar with. This will not only frustrate them but also stop some of them in their tracks. Better to share when appropriate, after they’ve had success with the software.
- Automating a step while taking control away from users. In general, software and hardware is an augmentation of human thinking and action, so automating tasks is usually very helpful. But in recent years we’ve seen software go way overboard. Sites that tweet for you without your permission. Apps that auto-friend you with others. The crucial aspect is control. If you do something for someone while keeping them in control you are usually good. Do something for someone and take away their control of it and you will have problems.
- Inappropriate next step. Or the next step might just be inappropriate, the wrong next step. This often happens when designers try to leverage some other action you take with what their ultimate goal is…when their priorities are not aligned with yours.
For every interaction you design, think about why it’s not working in relation to these questions. Are you moving too fast? (likely) Did you display the steps out of order? Is the next step appropriate? Etc…
Three Pieces of the Next Step Puzzle
So how do we design for the next step? Well, every design situation is different and will require a different design. But in general there are three things we have to get right. Clearly communicating the current step, the next step, and how to get from here to there.
- Clearly communicate the current step. As I explained above, the NyTimes were not fully supporting the current step I was on as a reader of the New York Times. They did not clearly communicate to me my current status, so their promise of a better status didn’t make much sense. This often feels like a recapitulation of the obvious…I’ve heard designers say “Why would I tell people something they already know?”. Fight this tendency! It’s always better to be clear about agreed-upon status than assume people know something.
- Clearly communicate the next step. The Times also failed to communicate the value of becoming a digital subscriber. This is a classic problem of not addressing real customer needs. The needs of NyTimes customers is to get better news than they’re already getting (to be better informed)…not to take advantage of an offer! So the task is to clearly communicate the future in which one is a digital subscriber and is better informed than they currently are now.
If the Times had successfully communicated both the current and the next step, they would have allowed people to compare the two against each other and make a real decision.
- Clearly communicate how to get there. The Times did this well. They clearly communicated the offer and how to take advantage of it. The call to action was clear. Unfortunately, the Times didn’t satisfy the other two requirements so the offer fell flat for anybody except those who already decided to take advantage of it.
Designing for the next step is a fundamental problem of interaction design. Almost every screen we design, be it in an app or marketing website, can be improved by really focusing on the steps and sequences of steps a user goes through. In our haste we often speed up the process too much, get steps out of order, fail to present an appropriate next step, or otherwise break the sequence. By re-assessing your app or site in light of these potential errors, you can discover the sequence and timing that your users need to successfully make it to the next step.
December 17th, 2011
Design is not Horsepoop
by Joshua Porter | Responses | shortlink: bokardo.com/p/2030
In his impassioned piece Design is Horseshit, YongFook suggests that the increased focus on designers as founders is misguided because design isn’t what makes most startups successful.
In my recent post The Golden Age of Design in Startups I was bullish on designers as founders, so I’m here to call bullshit on Yongfook calling bullshit…or something like that. (actually, the idea of “calling bullshit” seems silly to me…why not just respectfully debate a point?)
Yongfook’s argument is that design is not the reason why startups are successful. He suggests that startups are successful when they “create value” and in his view “Design enhances value, it does not create it.”.
It depends, of course, on your definition of design.
Implicit in Yongfook’s argument is his definition of design. He is equating design with making something look good. This is clear from his thesis:
“Stop creating shitty startups that look amazing. A product or service that is indispensably useful yet looks like ass is infinitely more likely to be successful than a product that solves zero problems but looks like a work of art. Stop this cycle of creating beautiful novelties, getting your 15 minutes, then disappearing. Create value.”
“Look amazing”, “looks like ass”, “looks like a work of art”, “beautiful novelties”. Each of these terms is about “looking good”. So if you agree that design is the act of making something look good, then you’ll undoubtedly agree with Yongfook’s piece.
I hear this notion of design every day. Many people seek out design help because they can’t make something look good on their own…they just haven’t had practice doing that. But designers secretly know that their role is much more than just making something look good…it’s solving the right problem and communicating the right message.
And this goes for startups as well. For some reason, Yongfook wants to separate “value creation” from “design”. But that’s hard to do…as design is in part the process of discovering problems and then conceiving of solutions to them. The idea that a founder would go out and “create value” without actually designing something along the way doesn’t make much sense…in solving the problem they would end up designing something, even if it only be conceptual design of a proposed product. (if they’re not conceiving of something new then they probably don’t have a business anyway)
In short, Yongfook’s dismissal of design as decoration is a long-standing, myopic view of the field. This is not just my opinion. Steve Jobs, in an interview about the iconic design of the iPod, addresses this notion of design directly:
“Most people make the mistake of thinking design is what it looks like. That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.”
If you agree with the idea that design is how something works, then you won’t agree with Yongfook’s post. Instead, you might insist that learning about what problem to solve in the first place (which Yongfook is adamant about and which I agree with) is actually the first step of design. You cannot create a successful product without first understanding the problem you’re solving.
Founders who talk to customers are not black swans. There are people who do this all the time….UX people in general continually interview, survey, and test with users to make sure that core problems are being addressed and solved. (as much as I’m a fanboy of Blank and Ries they were not the first people to get out of the office and talk to customers) In a startup you might not have a UX person at the beginning…but I would recommend hiring one sooner rather than later. Startups who