The Product Design Process

Process & Technical Feasibility

Paul Boag

Paul Boag

The Product Design Process

Check out a free preview of the full The Product Design Process course

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

Paul emphasizes the importance of designers working in harmony with developers and understanding technical feasibility and scalability. He discusses the importance of understanding HTML and CSS, and encourages designers to at least have a basic knowledge of coding. He also talks about the concept of simplicity in design and shares a process for simplifying complex interfaces by asking three questions: Can I remove it? Can I hide it? Can I shrink it?


Transcript from the "Process & Technical Feasibility" Lesson

>> As designers, we do have this habit of going, well, that's the techies problem. [LAUGH] But actually, we need to work in harmony with developers and side by side with them. So we need to understand technical feasibility and whether our idea was scaled. Is there anyone here old enough to remember

Yeah, it was shoot it's really funny how something could be so huge at one point and then nobody knows about it anymore. It really was, it was like Facebook level huge back in the day, and I happened to be friends with the lead designer there and the lead developer, right?

Daniel Burka and Joe Stump. And they told me this or Daniel told me this story. The whole premise of Digg was that you had, it was a bit, I guess it was a bit like Reddit. That you could post stories basically, things in the news that's up and then people can dig it, vote it up.

Okay, and so there was this little badge where you could vote things up or down, and Daniel was messing around designing a new version of the badge. And luckily he showed it to Joe before he showed it to the big bosses, right? Because Joe took one look at it and said, if you design it like that, I'm gonna have to add at least ten new servers, right, simply because of the demand that it would put on the code base doing it like that.

So understanding the technology and the feasibility and the scalability of things is so important. I'm not saying you need to be an expert developer, but you do need to a, at least talk to your developer. And if I'm gonna throw something controversial into the thing, I would say you need to know how to write HTML, CSS as well, right?

I will get in trouble for that, I suspect, because a lot of people disagree with me over that. But I think it's fundamental. And when we come on later to talk about prototyping in Figma and design systems, you will see just how important it is to understand how code works, at least a basic level, if you wanna call yourself a product designer.

Or, I would argue, a web designer or a user interface designer. Anyway, you can shout at me when you want to. All the hands that went up then. [LAUGH] Yeah, you go for it first.
>> How important do you think Javascript is to product designers and-
>> Yeah, a Javascript is a bit trickier.

I don't include that as a requirement. The reason I don't, and this will become more obvious when we start looking at Figma and and prototyping later. But the big thing that you need to understand as a designer is the idea of the CSS box model, right? So, it's how pages are constructed and put together.

That's the fundamental because you make life so much easier if you just design things well in Figma. But when it comes to interaction, then A, it starts getting more complicated and there is only so much that you can do. And B, probably the way that you would do it would have to be completely thrown out by a grownup anyway.

So I wouldn't include that as much. I mean, I know I'd have write a bit of Javascript. I certainly know how to write using various Javascript libraries, but it's not a necessity. It's not as big a deal. Yeah, you had a question.
>> When it comes to HTML and CSS, are you saying that it'd be good for product designers to become fluent in it, to be able to say, okay, I can write my own?

Or are you saying it's important to conceptually understand how it works and why some things are done?
>> Both, so what I mean by that is you've got to start somewhere. As I said in my user research and testing course, something's better than nothing. So to begin with, just get your head around conceptually how it works, but I wouldn't stop there.

I would say, you need to, if you've got a page in front of you in Figma, I think it would be healthy and good that you could build that page, right? You won't build it as well as the developer will, right? But you should at least be able to have a go, right?

And get to roughly the right result. That would be my recommendation, but I don't wanna shame anybody from it. I don't wanna make people to feel inadequate if they've not got that capability. And conceptually understanding it is a really good starting point, but we should always be pushing to expand our understanding and knowledge, right?

And I was saying you need to learn a bit about psychology, you need to learn a bit about marketing. Well, you need to learn a little bit about development as well. So just push yourself, I guess is what I'm saying more than anything else. The other thing that is crucial, I think, to product design, and we're gonna unpack all of these things more later, but is this idea of just simplicity, right?

But having a mechanism by which you can take anything and make it simpler, right? Having a process for doing that is so invaluable, right? I regularly get called in to sort out [LAUGH] web apps, right? And I was doing one quite recently actually for a warehouse management software.

And it had been, created by very talented team of developers that have done an amazing job. But they've been asked to add more and more and more to it new pieces of fat every time a client asked for a piece of functionality, they just added it in. And it's not a job to kind of sort out the user experience.

So eventually they got me involved. And the route that I use when I'm faced by that is is really, really simple. It's not rocket science, is this is a starting point event or you do reach a point where you need to kind of rethink the whole structure of the thing.

But what I was basically doing there was going through screen by screen and on each screen I would look at every single element on that screen. Every menu item, every icon, every input field, absolutely everything on that screen and I ask myself three questions in order, right? Question number one, is can I remove this?

What happens if I just remove it, delete it as getting rid of it, right? And sometimes it's amazing how much you can do that. So for example, icons, right, that app was riddled with icons, every option had an icon next to it. And then you reach a point where it's like, how does this icon help, right?

Because it was all English speaking. It wasn't meant to be multilingual. So it's like, what's this adding to it? What would happen if I deleted it? And the answer was, well, nothing. At which point you go, well, let's delete it then, right? But obviously, there are some things you can't delete, right?

For example, the main menu that was going down the left hand side, right? Loads of different options, all of which were apparently essential set aside whether they all were or not. So as I worked down that menu, my next question was, well, can I hide some of these elements in this menu, right?

Instead of they had like 30, I think something like 30 elements all down a side menu and it was like, my eyes are bleeding looking at this list and I said well, which ones of these are used the most, right? To which the answer was well, people really are only looking at those four.

All right, well, why are all the others there then? So I put all the rest under a kind of dot dot dot thing or hiding things away, or should we be doing that? Well, if 80% of people are looking at those four, then let's make it easy for those 80% of people before we worry about the 20% looking for other obscure things, right?

And sure, there were other ways of solving it. We could have had different permissions that had different things in the menu, but that was the quick and easy way of just hiding some stuff, right? And then, but sometimes you can't hide things. So the biggest, the great example of that is, we need to show our privacy policy and our cookie notifications for compliance reasons, right?

It was you, you work in banking, don't you? As I remember, yeah. Banking's terrible for this. You have loads of compliance things all over the place, right? No, no, you couldn't hide that because you need to tell people that their house is at risk. But what you can do is you can shrink it you can visually de-emphasize it, right?

So that it doesn't dominate the design and it's not adding confusion, and clutter. I mean, this isn't rocket science, is it, but you have to go through every element on every screen doing this saying, can I remove it? No, can I hide it? No, can I shrink it?

Yes, for every element.

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