Mastering the Design Process

Design Process Q&A

Paul Boag

Paul Boag

Mastering the Design Process

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

The "Design Process Q&A" 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 answers student questions regarding what phase internally run projects for optimizing a site would be and if having content created or delegating content creation to the stakeholders is preferred. This segment also covers how this process applies to products like web or mobile apps and the differences between using this process in an agency and internal setting.


Transcript from the "Design Process Q&A" Lesson

>> So really, that's all I wanna say around that particular process of running projects. So before we get into how to go about producing initial design, I just wanna come at you very hard with a lot of information in a short length of time. So I wanna give you an opportunity to ask some questions.

If you happen to be watching this not live, I'm always open to answering questions via email as well. You're more than welcome to drop me an email anytime. Once you get the slide deck, you've got my email address. Feel free to use it. Now, I know you had a question because you work in-house, don't you?

So tell me about your situation.
>> So a lot of times, we don't design. I mean, we kinda squeeze a lot of design process to do early tests on certain things, specific things like if we do a drop-down instead of a button or if we do a series of buttons.

We call that AB testing, but it's kind of like discovery, in a way.
>> Yeah.
>> Where do you see that factored in to the design process?
>> Yeah, so what you're talking about there is the kind of micro projects that you run internally to optimize something over time rather than the big project like redesigning a whole website.

Actually, I'll still use that same basic process in that situation. But it's a very, very small scale because the project is very, very small. So my discovery phase is really validating the problem in the first place. So typically, let's say, for example, you've got a form that's underperforming, right, on the website.

So first of all, you've got to identify that that form is actually underperforming. So that's where you look at your analytics, and your analytics will basically confirm that there's dropouts from that page or whatever else, so that you do that as part of the discovery. Then you'd probably look at some heatmaps or session recording of that page.

That's where something like Microsoft Clarity comes in if you want something free or I suspect you guys have something like Hotjar or something like that. So then you're validating where on the page that form is failing. Is it this drop-down menu? Yeah, we can see it is from users.

So that's your discovery phase is defining the problem, okay? Your prototyping stage is what you just described. If we remove the drop-down menu and we try buttons instead, we create a little mock-up of that, see whether that works. Now, how you test that, you're talking about testing it with some AB testing.

That's absolutely valid because if you can throw something together very quick and easy in that situation that you can run a real AB test on, that's awesome. The only thing that I would say is with AB testing, you're learning why a problem. No, so you're learning that something works or doesn't, but you're not necessarily learning anything about why, if that makes sense.

So actually, I tend to favor kind of usability testing at that stage, not facilitated, not that I have to sit down and watch all these people. But basically, you send out a link, let them try it, let them talk over as they're doing it. So you get some more insights that way I find.

And then from there, once that's been done, once you're happy with it, it goes into build where you launch it on your website. Then your equivalent of the live stage, right, so you've pushed it live now, that's the point where I would do the AB testing. And I would see how well it's performing compared to what we had before.

So it's exactly the same stages, it's just in a really kind of micro way. Does that answer the question? Good, what have we got in the chat room?
>> Does Paul consider getting content created to be an important part of the process or does he prefer to delegate all the words to the stakeholders?

>> No, I do not prefer to delegate all the words to the stakeholders. Look, I mean, that is a whole workshop in itself, that question. It's a really good question. Basically, content, yeah, in your discovery phase, right at the very front, you wanna involve all the key stakeholders, right, which will include the content creators, includes the developer.

When you get to the prototyping stage, I would heavily involve the content creators at that point. When I do a grayscale wireframes, that is with first draft content in it. It doesn't need to be perfect. It doesn't need to be 100%, doesn't have to even have the right tone of voice.

But I need to know what content is gonna go where on the page, what messaging is gonna be communicated. So yes, your content creators should be very, very much involved in that. That said, it's not always possible because content is often created by people that aren't full time in that role.

And so as a result, they're always a bit slow in delivering that. So what I would suggest in those kinds of situations is that actually you draft first go content. Now you might think, whoa, I'm not a copywriter. I'm not good at any of that. It doesn't need to be good, right?

In fact, almost if it's bad, that's better. [LAUGH] I know it sounds so weird. What you will do is you will identify what kinds of content needs to go into different places. So let's say you're designing a homepage. You'll go, okay, we want benefits here. Here are the three benefits that spring to my mind, right?

Doesn't need to be researched, doesn't need to be considered, doesn't need to be anything. The role of you putting real content in is you set a placeholder on the page that says benefits are going in here, right, which is good. And secondly, because your content might be not very good, then what will happen is that forces the content creators.

They suddenly go, no, no, no, we're not having that. And so they'll put something else in. So it's a way of kind of forcing them into action. But yeah, you should absolutely integrate them. You should be using real content from the very beginning. Never go with lorem ipsum ever.

I know it's so tempting, but please don't do that.
>> You have been using websites as an example of deliverable per project.
>> Yeah.
>> How much of this advice pertains to products such as web apps or mobile apps?
>> It applies 100%. Sorry, I'm showing a little bit my bias in the kind of work I do, I suspect.

I do a lot of conversion rate optimization work on effectively marketing websites. But no, I also over the years have worked extensively on web apps and exactly the same principle applies. All the way, I can't think of anything I've said that doesn't apply to that. If they can think of any particular problem that maybe what I've suggested doesn't work with, then by all means, let me know through the chat and we'll discuss it.

But now, I would say it's pretty much consistent across the whole thing. Yeah, I tend to use shortcuts. I say the word website when I mean web app and mobile app. I also use the word client when I mean internal stakeholders as well, so apologies for that.
>> Yeah, I think from my perspective, that's the biggest difference is usually in the agency world, you have an external client who's paying the bills.

>> Yeah.
>> Whereas it's management and product situation.
>> Yeah.
>> And they're not necessarily paying your bills, where you have to sell them on a process. You just have to have a process and go through.
>> Yeah, yes and no, I think I've worked with a lot of in-house teams.

And actually, there's not as big a difference as you think. The way you described it is 100% right, but actually, I think a manager can almost be more problematic than a client sometimes. Because with a client, if I set the relationship up right, then the client that I'm working with is my peer, my equal, right?

So I can turn around and say, no, I don't think that is appropriate. We're not going down that road. That can be quite hard to do with someone who's your line manager, right? You feel of a bigger obligation to kind of roll over and do whatever they ask you.

So actually, you do need to sell just as hard, if not harder, to justify what you're doing and why you're doing it. At least that's been my experience, but other people might have had different experiences. I guess it depends on the kind of boss you've had over the years.

I had some terrible bosses [LAUGH] so that could be probably clouding my view.

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