is it really worth it spending that much effort trying to learn things from user interviews when you could use that time to ship faster and start gathering data from real-world usage?

The point is that qualitative and quantitative research serve different purposes. Qualitative is mostly useful for creating hypotheses, while quantitative is great for verifying your hypotheses and solutions.

They really go hand in hand, and if you're only using one of the two you're limiting your learnings.

Also keep in mind that, yes, doing research up front takes time, but it makes up for that by dramatically speeding up the design phase because it makes your goals, problems, and constraints a lot more clear.

That being said, I didn't really check out the case studies you included, but if they're similar to most unsolicited redesigns I've seen, then yeah there's a big chance their research phases are overly hypothetical and full of unverified assumptions that end up driving product decisions. In that case, the "research" doesn't add much value, no. That's just faulty execution though, not an inherent issue with user research itself.

Great question, I feel this tension a lot. I'm a UX Designer, but also love code and shipping (thanks to Discover Meteor actually!)

Most teams front load UX into a project instead of threading it through the delivery and refinement of the product and service. I'd like to get better at that personally and I could see how non-Uxers see that as arduous.

I think modern UX research processes are remarkably effective. Most tools don't take a lot of work, and don't require much in the way of resources. They can be really motivating for teams and users. A great way to help everyone frame a problem and derive a solution. Also your best chance to build a good MVP is going to come out of a UX process, and then you can ship faster!

I think it's a foundational aspect of good UX, being able to iterate. There are many things I've learnt just from shipping! I find so many teams can't ship fast enough. If you can iterate and ship fast, that's the best place to be.

When I started to learn coding I inadvertently spent time building side projects with no UX research. They've never gone well, but have been deeply rewarding. I have found it really hard to keep them constrained and stay motivated when I realise features are wrong footed. It can really kill a project if you're not getting feedback at the right time. You can get to caught up in details that don't solve the immediate issue and ultimately burn out. So I think it's very challenging to build stuff without research and feedback. There needs to be some balance, otherwise you're taking a massive gamble!

Wow, if you have clients who actually ask for research, I'm jealous! Back when I worked at an agency, that was never the case. Now I work at a B2B SaaS company and we've invested a lot in research this past year. This is the first company I've worked at that has done research as part of the design and let me say, I've noticed a big difference:

1) It builds trust. Colleagues from Marketing, Education etc will feel better that what you're building is the right thing and that you're actually listening to customers. If a company says they put users first, that means the company has to walk the talk and talk to customers. Use their feedback to inform your design decisions. Otherwise, you're just operating from assumptions which may or may not be correct.

2) We've caught things we never would've caught otherwise. Tech companies are generally a homogenous group. Diversity, getting different perspectives, being open-minded are all very humbling because it shows that you don't know everything and willing to learn.

3) There's less back and forth. Developers and QA will have less "wasted" work. And in turn you move faster in the bigger picture.

Contrary to popular belief, UX research doesn't take as long as people think. "Research" as a term has a history of being long and drawn out (think medical trials). But "User Research" and "Usability Testing" may add an extra few days upfront but it saves you time in the long run. Instead of building something and having to scrap it later, why not build it right and not waste development efforts? Marketing efforts? Education efforts? Sales efforts? Customer efforts? Each time you change something so often, people have to relearn it again and deal with potential frustrations from it not being designed thoughtfully.

I'm a firm believer that an ounce of prevention is worth a pound of cure. We expect everything else in life to be tested: Pharmaceutical drugs, cars, video games etc. Why is technology and products any different? We have to be more aware that the things we build have consequences. Or else we'll end up where Facebook is right now.

If you need tangible proof that research does makes products and companies more successful, I highly recommend watching the documentary Design Disruptors (https://www.designdisruptors.com/). It's put together by InVision where they interview design directors and leads at top tech companies (Airbnb, Pinterest, Lyft etc). You'll notice that every single person says research is so important and contributed to the success of their company.

My last argument is politics. Think about any policies that have a huge impact on your life, and think about the people who make those policies. For example, I'm a woman and have certain beliefs about what I can do with my body. It annoys me that a demographic who is not similar to me, is making policies about me for me. No matter how hard you try to empathize, at the end of the day you are not the user. Just like how at the end of the day, old men making policies about women's bodies does not make any sense. It should be women making those policies. Or at least, those men should be listening to women. It's an extreme example but the point is, it's very frustrating when people build things for you without really understanding your needs.

Here's the thing: people are watching and you're playing with live ammo.

If it's just you, sure! No problem throwing shit at the wall and seeing what works. Move fast and break things, am I right?

But if you're representing a brand, it helps to realize that to everyone outside said brand, first impressions matter. If you don't nail enough of that initial experience, chances are there's someone across the street, or on another site, or another venue for someone to invest their time, effort, or money into.

And again, the old mantra: your audience isn't you. A few might be, but chances are you're not the target audience, so how can you know how they think unless you do the research?

By the time you collect enough data to test on-the-fly, it's already too late for many. They're gone.

A few years ago, I was working on a healthcare app that allowed patients to pay their medical bills. In the US (and probably elsewhere) there are strict privacy laws around healthcare information that require patients to authenticate their identity before a service can display any medical information. Success for us was to get as many people paying for their bills through our service instead of other means (CC payment over the phone, mail a check, payment in person, other payment solutions, etc).

We assumed that patients would want to see their full medical bill including services and procedures before they would pay. People want to know what they are paying for. Seems obvious right? Well, we challenged that assumption. Would people pay if they only saw the final amount due? I didn't think so. Before we designed or built anything, we learned more about that scenario. We found that there are people out there (a new undiscovered persona) that would do that. Parents, legal guardians, and caretakers often do this. They don't need the full medical information; they just want to pay the bill.

So we designed the software to allow you to create an account/sign in to see all info, or, you can just make a payment (this was actually really technically tricky that added some risk to the overall project). ~50% of payments were made without the person authenticating and signing in. If we didn't do the research, we would have built something that didn't work for those people and the product wouldn't have succeeded.

If we didn't do the research and just released it as first intended, would we have learned what we learned through research? I don't see how that would be possible. We would have received half as many payments but we wouldn't know how much was left on the table. We wouldn't know where to look. We wouldn't be able to look at the database and say, "Oh it's because the we didn't build it to serve parents and caretakers who can't/don't want to authenticate." The Lean Startup build-measure-learn cycle isn't design. It can't tell you what you should do.

I totally felt the same a while back, but as the process is getting more popular between companies it helps to rise salaries and resources devoted for design.

For me the whole process helps to find better arguments for design decisions. As well it adds layer of insurance for the company I work for, that a time and resources spent will be valuable enough for the end client. If research part is well documented it as well helps business people to understand their clients better and keeps discussions more user/people centric.

The thing I definitely don't like about all this process is the language. People who are new in UX and come from roles like project manager or "non-designer" roles, in my experience, tend to over-complicate language with buzz words to compensate their technical knowledge about implementation. This definitely damages communication between other departments, as others don't fell the possibility to participate in discussions.

Obviously in the end that all helps to tailor products and services that actually help people better and better. I would say that research process helps a lot, if done correctly.

Effective especially for products that serve both offline and online jobs-to-be-done; think UberEats (for the driver) or JapanTaxi driver app.

A lot of these modern design methods and exercises, in essence are extracting insights that informs product design & development.

In any case if these designs perform poorly, usually has negative impact not just on the experience itself, but also business.

Hence the exercises are usually closer to the users rather than the products.

With that said, there's nothing wrong with the traditional approach of iterating on the digital products itself.

But most of the times, these kind of products has the luxury of having a digital/web audiences as their main or only user. Examples would be say JIRA or Wantedly. Most of the jobs to be done revolves around digital-heavy interactions. Hence any kind of insights can be extracted via direct feedback or interaction of existing customers; or feature requests from existing or potential customers.

I don't see it as a different way or school of thought for UX design, instead I see it as additional spectrums to UX design that brings us designers closer to the users, rather than towards the products. It complements the old way of focusing on the products and having to constantly guess what the user needs & wants.

Chance is not a good business strategy. That's why so many startups fail to reach product market fit. The way you're doing it basically is throwing bricks on a land field and hoping to build a house. Would that ever work?

I skimmed through the other comments and I think people confuse product work (focused on product discovery) and agency work (focused mostly on delivery). Don't fall in that trap.

This topic is not something to debate on: you either have a process and succeed, or you don't. My only piece of advice is to look into these things right now. Also drop Photoshop - but I guess it's telling why you use it. :P

Begin with a few videos on youtube. Then dive deep.

1. ODI, by Tony Ulwick
2. Gamestorming
3. Market Opportunity Navigator

You'll have this insight after you immerse yourself in these processes: https://twitter.com/andupotorac/status/1054157801659002880.

About a year ago we started doing research rather than just jumping into prototyping. I'm still learning if this is a "great thing" or not but have seen some successes and failures.

On one app improvement project, we retrofitted analytics and learned that 80% of people only cared about 20% of features (weird that this re-enforced the Pareto principle!). This helped us focus our efforts and reduce the scope of the release.

On another product improvement project, we conducted user interviews during discovery and learned a lot of frustrations users have about the status quo. This info still influences design decisions. On a negative note, I'm not sure any of the insights really took us beyond what we know from good old UX principles.

One thing I have noticed is that our clients generally have a great gut feeling on what will resonate with their customers. So they have a good idea of "what" to build. I'd like to find research techniques that bring new insights even to people that have worked in an industry for 20 years and know their customers very well.

I will add that it depends on the stage of the company/product. If it's a tiny startup that's building its first version of a product, then UX research is done, but it's less of the focus, and you're aiming more towards shipping something and learning from the users. At that point do you start spending more time researching.

While I still believe the Discovery phase is one of the most important (and most skipped) of the design process, I do think your point about how much of this process is really used to justify the design choices you would have made anyway?" is important for product teams to keep in mind.

I've definitely been on projects where a "solution" was proposed early on and it started to feel like a lot of the "discovery" research was being done in aid of that hypothesis, rather than a more objective interrogation of the proposed solution. We had to take a step back and do some more clean-slate thinking once we realized this, and in the end went down a different path. But that's why spending time on the discovery phase is so important. It's a fairly good (and cheap :D) crucible of pet ideas.

Discovery phase user research is by far the most important part of any project.

It's where you really find out who the people you are designing for are and what they really need.

It's where you find out that your assumptions about what they need are right or wrong.

It's where you find out if the problem you are about to solve really exists and whether it's worth investing a lot of money and time into.

It gives you a healthy dose of reality, ends arguments, allows you to prioritise your features, and gives you a solid starting point where everyone is on the same page and confident that you're 'building the right thing'

I'm a digital designer and have recently just started to transition into user experience design so I've been reading an learning a lot lately from online courses. I used to always launch straight into design with only a minor understanding of the client and target audience.

I found this tactic worked well in terms of speed but I was always really disappointed with the end result. Sometimes it wasn't easy to use or the structure just wasn't right. And if I'm thinking that as the designer then how difficult must it be for the user?

Since beginning my user experience journey I've been applying some of the learnings to a real project I'm working on and already I can see a huge difference in how I'm designing. Just to give context some of the techniques I used for it included: stakeholder interviews, user interviews, empathy map, user personas, customer journey map, brainstorming, wireframes/prototyping and user testing.

These techniques did provide insight that I previously did not have. If I had just gone with the business' own company strategy then I would have produced a site that worked for them - but they aren't the users of the site. And how can they succeed as a business if the people using the site are struggling or don't like it? Some insights I found included: what types of information people needed to make an informed decision, what types of information were most important for them to know, what situations they are in where they would need to use the website, how they want their experience to go, what the user values, what is unnecessary information, where it is best to put information so it is easily found.

I would never have been able to gain these insights if I had just been guessing. So with the research I'm able to create a website that addresses the needs, concerns and wants of the user. Which is ultimately everyone's goal. Why would I want to risk delivering a product that user's don't like using or struggle to achieve their goals? You're just going to end up losing them as potential clients and then once you redo the website to fix everything you've got the tough job in trying to convince all those missed potential clients to come back and give the site a second try.

I'm not usually one for quotes but this one from Gerry McGovern pretty much sums up User Experience for me: "When you solve the customer's problem you solve your problem."