Video: Why "Build it and they will come" doesn't always work

Watch Victoria dismiss the Field of Dreams’ “build it and they will come” fallacy when it comes to building great UX, or read her comments below.

I find that the way products are traditionally made is "build it and they will come" approach. So, a few people in IT sit in a corner by themselves, make a product. Then they get a manual 200 pages long, give it to the user and say, "Use it for the next 10 years." And that takes an effect. So, if, if somebody feels like something is forced upon them, they are less likely to use it. They're not sure how it integrates with the process, and it might be flat-out wrong. It might actually incl ... increase the burden on their wellbeing.

Using the process where the user is in the beginning, and getting that journey, and seeing how this product can improve them. And doing that from the beginning, so the user feels like they're involved in the process. They feel like they're contributing to it. So that when it comes out on the other side, they're not only love using the product, they're an advocate for it.

Video: Lessons learned from design done wrong

Watch Victoria and Allan talk about why design can go wrong and how to avoid the pitfalls. Read the transcript below.

One thing I see very frequently is UX happens in the beginning, development happens second. And so you do the interview, you do the research, you do the user stories, you have the design, give it to the developer, you walk away and you work on something else.

Now in real life, things change when they get developed so, you would have the journey and you would have all of the principles imbedded in that however, you would start working on one of features making sure that's up to scratch, having the screens, the-the designs and then passing on data onto development and you don't walk away because what I find, more often than not, the developer goes we can do ninety percent but this ten percent it's not really feasible so we would go oh, right let's rethink this so you can tackle this right there and then so you can come up with a better solution. Sometimes the solution is actually better than what you originally came up with. And so you tackle that there, everything becomes unblocked and you can start working on-, on other things. So you have design check-ins. 

Victoria's right. That's exactly like, what happens is-is-is sometimes, you know, th--I think any business where there is silos, you're going to have challenges. Um, if you're not thinking about cross functional and the way make cross functional work. Um, it's very easy to go, 'well, let's just stay in solitude, feel safe and secure and we'll have designers a thing over here and we'll make the best design possible and then we'll have this development over here and the best development possible'. Because cross functional is too hard. If you think cross functional is too hard, you--like you really have not been working in the industry long enough because the idea is if you--you have to make that process work if you want to get the agility and the, and the flexibility that Victoria's described. 

I think any business that is still holding onto um, either ivory towers or the way in each of those disciplines without factoring in the results of the other--of any other discipline, that's when it really falls apart. 

What is one simple thing you can do to improve UX?

Watch Allan Waddell, co-CEO of Kablamo, and Victoria Adams, Kablamo’s UX/UI Lead, tackle a thorny UX issue that comes up again and again, but is there to be solved. And Freddy, the Dev Ops dog, makes a special appearance.

If I were to pick one thing, in order to improve user experience that I've seen done, is honestly involving the user. User experience it's in the name but I see it time and time again that the user is left out of the table that's being discussed. We talk about features, we talk about what's in scope, what's out of scope and the user's voice is left behind. So even if they can't be at the table, having that research in the user experience person so that they can be that voice.
Isn't that ironic? The user experience the user is left out.
Yeah, that's often the case. I think--I don't think it's--sorry. It's Freddy. 
Um. Yeah. I can't take anything seriously with him sitting on my lap. I'm sorry but like it's--
It's a 'blamo dog.
Yeah, it's a DevOps dog. I think uh ... yeah, in user experience the number one thing that doesn't happen is users gets involved and I think it's not necessarily the fault of the customers that are doing it. It takes experience to know how to engage customers in the right way. It's not as simple as just putting a wire frame in front of a bunch of people and getting a result. You have to know what your tests are for. You have to know what hypotheses you're validating, specifically and you have to get those answers and be able to, be able to measure that in the right way and then understand those results. It's like saying the difference between data and information. You get a whole bunch of data back but it doesn't really mean what you think it means unless you thought about that preemptively. That's what Freddy thinks anyway. (laughs)