Mastering the Design Process

Design Project & Avoiding Pitfalls

Paul Boag

Paul Boag

Mastering the Design Process

Check out a free preview of the full Mastering the Design Process course

The "Design Project & Avoiding Pitfalls" Lesson is part of the full, Mastering the Design Process course featured in this preview video. Here's what you'd learn in this lesson:

Paul discusses common reasons design projects struggle, including scope creep and subjectiveness. Suggestions for how to avoid design pitfalls, including introducing objectivity, involving the client often, and providing reassurance, are also covered in this segment.


Transcript from the "Design Project & Avoiding Pitfalls" Lesson

>> Let's start with the fundamentals, how to go about running a design project. Because if you run the design project in the right way, all of those other things we're gonna touch on like presenting design, getting feedback on the design, ensuring the design flourishes. Things like how to produce a design an effective way.

If you're running the project in the right way, all of those things kinda naturally fall into place much, much easier. So that's why I wanna start by looking at the fundamentals of actually running a design project and what's involved. So I think a good starting point in that conversation is to kinda step back and say, why is it that design projects often struggle?

Why do they fail to deliver? Well, in my mind there are kind of three typical pitfalls, if you like, that design projects naturally fall into. The first one is scope creep, right? So once somebody can start seeing design concepts, once they begin to see the shape of what you're producing for them, then they start having ideas, right?

It's a completely natural thing, a project is very nebulous and quite hard for people to picture in their heads. But once you start creating something, once you start showing them something visual, then that sparks ideas, and actually that's a good thing. It's good that people can begin to get invested in the project, can begin to have ideas.

But, if you're working on a fixed price, fixed deadline, your fixed scoped project, scope creep is the enemy, okay? And it creates all kinds of problems, it slows down the design process, etc. So we need to be able to deal with scope creep, not to eradicate people's ability to have ideas, right?

But to manage it in a way that is appropriate, not just for the design process, but for the build as well, right? Because obviously having a great idea halfway through the build is much more expensive to implement than it is right at the very beginning of the project.

So, scope creep, that is one big problem I see all the time with design projects because that's what design does, is it hopefully inspires and makes people think of things. The second big problem with design is subjectiveness, right? Design is utterly subjective, code isn't. Code either works or it doesn't.

Okay, there are endless debates about what coding framework you use. There's endless debates about whether you've done it in the most efficient way, but at the end of the day it either works or it doesn't. Design on the other hand is a totally different ballgame. What I like as design will be completely different to what you like as design.

Our view of design is heavily shaped by our life experiences, right? For example, [LAUGH] I realized that I had a particular dislike to a particular shade of blue, right? And when I thought about where does this come from, I realized that that shade of blue was the shade of blue that my auntie had on her curtains at her house, and I really didn't like my auntie, right?

That is a classic example of, we have all of these things, reasons we don't like certain design, certain color, certain typography, because of weird associations that we can't always even identify. This causes problems because what happens is in this situation is, let's say we in this room, we're trying to agree on a design, now we've all got different likes and dislikes about design.

And so what we'll try and do is, we will try and come to a compromise between something that we can all tolerate, right? And you end up with bland design as a result. If you don't design for somebody you end up designing for nobody, right, something that doesn't please anybody.

And that's why design by committee is so bad, and creates so many problems, okay? And worse still, what often happens is you try and take all the different people's likes into account, maybe you produce multiple design concepts in order to try and find the right way. And then people start picking and choosing from these different design concepts, and you end up with Frankenstein design.

Where you've got different bits from different bodies kind of smushed together into this horrendous monster. And then obviously the big problem when it comes to subjectiveness is it leads to iteration. It leads to, wow, okay, I don't like that blue because of my auntie, can we try it with green?

And now the green means that the images don't work and so on, so you get stuck in iteration hell, right? Which has already been mentioned in the chat. And it will be the subject that comes up again, and again, where you literally cannot get out of this loop of design.

And it goes something like this, right, a stakeholder feels like something is wrong with the design, they're not entirely sure what, it just doesn't pop for them, or wow them, or whatever, right? So what they do is they request a change to the design that they hope will fix that problem.

So it might be, can you change the blue to red or something like that? So you as a designer, because at this point you've had the life beaten out of you and you've lost the will to live, you just give them what they want, right, in an attempt to kind of shut them up.

But when you make that change, then that doesn't actually fix the problem, okay? But that stakeholder isn't going to admit that, they're not gonna say, no, I was terribly wrong, go back to the blue, no, cuz that's not human nature. So what they'll do is, they'll try and find something else that might fix the problem, and you go round and round in a loop.

Endlessly tweaking the design, it progressively getting worse, and worse, and worse, right? So that is a big problem, and that is one of the most fundamental problems of design. And why if you are sitting there as a pure coder, and you don't get to currently touch the design, if you're just design curious, you can feel really smug at this point because you don't have to deal with this kind of horrendousness.

I nearly use a swear word there, probably better not to. So, that is iteration hell. But what about those of us that have to deal with that? Well, how do we go about avoiding some of these pitfalls? Well, there's kind of three areas that we need to start touching on.

Area number one is introducing some kind of objectivity to the process, right? So, instead of it being subjective, I don't like blue because of my auntie, right? There needs to be some more kind of objective way of measuring the success or failure of design. It's the only way you're gonna get away from this process of kind of endless iteration, and everybody having different opinions, and design by committee.

So, that's one thing that we need to achieve. The second thing is we actually need to involve the client more often, now this might seem counterintuitive, right? One of the things that happened to me, and I've seen it happen to pretty much every designer, is that early on in their career they produce their designs.

And the client and the stakeholders start to have opinions on those designs, it gets demoralizing, it gets frustrating. So what we tend to do is try and shut out the stakeholders, right? We don't show the developer for example the design cuz they might have an opinion on it, right?

[LAUGH] Or we don't show whoever because we fear the feedback we're gonna get. Now the problem with doing that, the problem with having that kind of mindset, is that if someone isn't actively involved in something they don't feel any ownership over it. They feel excluded from the process, they feel frustrated and ignored, and actually that makes them more aggressive in their feedback, right?

They wanna be heard. And also because they've got no sense of ownership, they weren't involved in creating it they can pick it apart all they want, right? No skin off their nose. So actually the big mistake that we make of excluding the client from the process actually makes it worse, not better.

So we need to look at how to involve the client in the process to get them a sense of ownership, and also use the process to educate them about what good design is. And then the final thing we need to do is we need to reassure our clients, right?

Design feels dangerously close to being art [LAUGH], right? And art feels all a bit kind of airy fairy, and all a bit kind of ill considered too many people, right? They don't get art. And design feels like this mysterious thing, right? So you give the brief to the designer, the designer goes away and, I don't know, sprinkles unicorn dust over it, and miraculously out of the end, the design appears.

And because it's like this black box of magic that they don't understand, they're nervous. We get nervous at anything we aren't controlling or anything we don't understand, it's a natural human behavior. So, a lot of the times where the client or stakeholder is interfering in the design, it's because they don't really trust you as the designer, and that can be really frustrating.

And I've seen a lot of designers get almost petulant children of going, well, I went to art college, you've got to listen to me, and that is not the way to get people to trust you, right? Instead, we need a robust process that instills trust in people, okay?

So we wanna introduce some objectivity, we wanna involve the client, and we wanna build trust through a robust process.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now