Blab #24: Creativity vs Functionality

Welcome to Marketing Labs. This podcast is brought to you by Marketing Labs, an expert digital marketing agency based in Nottinghamshire. If you're a business owner or marketing professional looking for straightforward non-salesy tips and advice to help grow your business online, then this podcast is for you. Strap in because we're about to reveal the things that other agencies would rather you didn't know.

Hello and welcome to another episode of the Marketing Blobs podcast. I'm your host, Tilly Hayes, and I'm the SEO exec here at Marketing Labs. When building a website, creatives and functional teams often find themselves at odds. Well, on occasion our team does. While designers want to create a visually stunning experience, developers want to ensure that the site is fast, secure, and scalable. But what happens when these two worlds collide? In this episode, we're going to explore the delicate balance between creative vision and functional reality when it comes down to a website build. Join me as I chat with our creative director, Tom Haslam, our head of content, Mel Healy, and our web development specialist Josh Stapleton. How are we doing guys?

Good. Good. Yeah. Very good. We need some boxing bell, don't we? Ding, ding,

Ding. Yeah, I feel like this is going to be a bit of a face off today.

Are we going to end up scrapping?

I hope not.

What we got then tills.

So what are the key considerations for you guys as creative and functional teams working together on a website build,

Make it look as nice as possible.

Make it function as nice as

Possible. No, in all seriousness, I think we do get quite a good balance. I think Josh, I do give Josh a few challenges. I think sometimes,

Yeah, and I'd say I probably give quite a lot of pushback as well. It is quite a fine balance between design and dev. I guess you do have to take quite a lot into consideration right from the start, but yeah, generally speaking, if both sides are working towards the same goal right from the beginning and let's say potentially bad ideas or potentially non-functional things are put to bed straight away or other things are sourced out really early on, it usually works out pretty well.

So there'll be times when I'll show Josh my initial design and he'll look at something and he'll just go, no,

Sometimes

That's not going to happen.

Yeah, no. Sometimes things just you can tell something's not going to work right from the get go and it may look good, but functionally and especially in the eyes of Google as well, if stuff's, I dunno, just going all over the page, it animations and things like that, it's not really going to be as performative. I'm not saying that you are guilty of that at you. No. To be fair, some of your sins are pretty minor, but you do see a lot of other things that aren't great.

I think especially when I first started working at Marketing Labs, I was very much focused on making websites look as nice as possible with I'd say very minimal consideration towards how it's developed and beyond that. Whereas now I do take a lot more into consideration. I think as far as a design process goes, it's always evolving no matter how early you get sort of initial sign off from a client, it always changes and develops as time goes on. So I think especially between designer and developer, you've got to have that initial sort of right. We're happy on both sides, so it's just getting to that point and then the hard part is explaining to a client why you've done what you've done and sometimes justifying it, but it's all about

Trying to enforce it. Sometimes it's very hard seeing a client ask for something or almost fall something that you're like, it's not going to work. It's a bad idea and you're probably going to put your side maybe not a risk, but definitely a risk in terms of Google rankings for example. Yeah, very hard to get that across.

I was just going to say it comes to how me and Mel work as well because we have that argument of Mel's obviously got a challenge of writing all the content that has not only got to be right for the user, but it's got to be good for search engines as well if you're keeping it simple. So I think between ourselves, I've also got to consider design layout, shall we say that is suitable for a copywriter to just step in and add the content. There's been times aren't there where you've created the content first and then I've gone and designed a layout around that.

Yeah, it is quite difficult because although you would think that the copy process shouldn't have anything to do with the design and vice versa, actually it does because the layout is part of the reading process, so it actually makes a big difference to how people digest the information, the order in which they do it, how impactful it is, whether they go on to make another step through the website. So actually the layout and the content very much fit together, hand in glove, and so there is often a back and forth between us isn't there on that.

So having said that, I think I've got the hardest job because one, I have to make a head of content happy and a web development guru happy,

Although if your design ends up compromising Josh's functionality, he's the clients to deal with when things break,

He's going to keep you in charge. This is it. It's finding the balance within it all.

I guess that comes onto to how you would navigate those trickier decisions amongst yourselves when it comes to impact on functionality.

Yeah. Where do we start with this? Should we try and think of some examples? So one I've got that's just sprung to mind, this isn't necessarily not necessarily a design thing, it's more of a client thing. To be fair is image sizes. So if you've got a hero image for example, we've had one recently where it's quite a thin letterbox kind of shape and clients don't often understand the way that aspect ratios work on images. So they might upload a portrait image or a square image and it's in this really wide area and not understand why it's stretched to fill instead of just having white gaps on the sides or on the top and bottom. Another one as well is resolution, and this one definitely goes into I'd say more functionality slash performance stuff is like if you're serving huge images all over your site, it's going to slow things down and trying to get people to understand that they can't have everything looking completely crystal clear without paying fortune for hosting and optimizations and stuff like that.

A big one for me I think is obviously UX because from a website has to take a user on a specific journey, so you've got to consider that from a design perspective and a content perspective initially, and then obviously whatever we as in me and Mel come up with on that process, Josh has then got to make it happen. So UX should be at the sort of centric point of all of it, but there's lots of things to consider. There's certain things that you'll have to a client will have to make a decision on and say, oh, well we'll not have that, but we'll have that because it's going to be better for the website for performance. It's going to be better for the user because of this. So it's just trying to get I say a balance between all of that before you even pass it to a developer because it should be as simple as possible really for Josh to just take a design and make it functional and work and come to life on a webpage. Like I say, we design all our websites on staging environments anyway, so once the initial sign off on the design has been done, essentially Josh then steps in and makes it live essentially on, but not on the actual domain.

That makes the collaboration process with the client a lot easier because we can get feedback, they can see how it functions and we can then ultimately justify what we've done we,

Yeah.

Tom, what would you say to a client who wanted their website to look or feel fundamentally different from a lot of the others out there? How do you stay at the cutting edge of design and still make something that's functional and performs well?

Good question. I think my mantra in all of design is just keeping things ultra simple because I think you can overcomplicate a lot of processes or overcomplicate design. So I think generally speaking, I try and aim for no clutter, plenty of breathing space or white space if you want to refer it as that, breaking the site up into clear readable sections so that it's easier for you as well to go in and be able to write that content. I think generally speaking, it's quite hard, but you have to take into account also the brand, the visual identity of the brand that you're working with as well because obviously that's important. So let's take RTS as an example. We've recently redesigned that one, their little logo is like a square with a cut in it. It's like an R with a dot. So it was easy to use that sort of shape. That sort of formed the design of the website with cutout images and things like that because it was replicant of that shape and then using the logo in icon spaces and things. So I think there's a lot to consider with that from that side of things.

Do you think though, or do you ever come across this instance where, for example with ads you need something striking to get caught through because there are so many out there as there are so many websites, how do you get cut through with website design but still make sure that it does its job? I mean, what's left to do now in web design, what's not been done before? That could still be done.

I think with ads specifically, there's a special formula for those because we know what layouts convert or have higher conversion rates for example, and I don't think there's any reason why you can't make ads specific pages if we refer to 'em as landing pages different to the core, so it still have to be linked to the site and have the logo and everything so that people know where they are. But I think to some degree, landing pages can be very different to the site in terms of how it's structured because they're coming with a specific intent. So you've got different messaging and I think we generally understand what formulas work in terms of layouts for ads. So I'd say with that you can take a slightly different approach but stick to a formula that works at the same time.

I'm just thinking of, for example, we looked at a few websites the other day, didn't refer all the companies in our industry or the marketing agencies and one of them had a different of pointer. How would you describe that pointer? It was sort of a circle, but it had a lag on it, didn't it? So it looked like it had a tail.

Josh probably just things that replaced your normal mouse and things like that,

So that was pretty groove and it fit with the brand because it was a creative agency and so the fact they've done something different, obviously it played into that functionally. I don't know what sort of difference that makes to

The user. Most stuff that's generally going to be like a JavaScript file or something just like playing about with things in the browser, as long as you can keep it lightweight and not interfere with I guess more necessary things on the page, then it shouldn't be too big of an issue having stuff like that, I think for me, obviously performance when you are looking about with things like that is a key thing to think about. You don't want it to be slowing down page load and anything like that. And also posing accessibility issues if you are, that's a

Really good point, accessibility

If you can't see because of this thing that's following your mouse around or if you're just completely unused to the idea like, oh, where's my mouse gone and I've just got this weird circle or something, that can be a bit of an issue. But generally if your page structure isn't messed up by it, if you've got good, I dunno, good layout, good accessibility, you shouldn't really see issues from something like that.

Yeah. How much do you take into consideration when you're designing a website in terms of accessibility?

I think for the majority of our clients, I wouldn't necessarily consider something like that first off. However, if a really outlandish creative agency came to us, then I might consider something a bit different and wacky and out there. I think that's because we are, I think a very good balance between a creative agency and a digital marketing agency and we get a really good balance between how sites look and feel and operate, but actually work. And I think sometimes, and I'll come back to when I had my own creative agency, I would just focus on making websites look as nice as possible with minimal content and all these features that felt and looked really snazzy but

Had just words.

Yeah, yeah, I mean I think there's lots that you can fall into the trap of and other designers might be completely different to me, but again, keeping it ultra simple and does it need that light, Josh would say add a bloat. So I think it's taken into consideration the client and in let's say 85, 90% of our case, we wouldn't ever look at anything like that, but clients want more and more now. They want to consider different things that are going to help 'em stand

Out,

And

I think in the example you gave though, it actually makes sense for them to be sending out for something like that. Whereas you can often find just regular companies probably isn't the best way of saying this, but people that don't necessarily need that kind of functionality and fanciness on the website, if they're just doing, I dunno, just like B2C kind of stuff, you don't need that. You just want it to be load quick, sell stuff to your customers and get your product out there.

I guess it's the industry and the client, isn't it? If we were working with a video agency, we'd want full width video everywhere. I know it would probably be a bit pain file size wise, but that's what they do. So you've got to show stuff visually. On the flip side, an e-commerce website, they want to sell products, so you've got to have the products at the forefront of that goal. It comes back to everything. What's the goal of the website? So it's quite, there's a lot to think about in the whole process.

Are you for or against animation, Josh, on a website?

Generally against, although subtle animations. Yeah, I can let something like that slide I guess. I think when you've got, so there's different types of animation as well, which is probably worth noting. You can have CS animation, which is done by your style sheet, usually pretty lightweight and generally not going to cause too much issues with accessibility and things like that. You've also got JavaScript animations, which JavaScript's an additional file you load in logical stuff and that can potentially add a few more issues. But yeah, I think subtle stuff with css, like buttons changing colour and shape and things like that aren't too big a deal, but when you've got one thing that Google will call you out on for example is CLS, which is layouts moving around especially buttons and clickable things. So if you've got somewhere on your page and then some CSS is targeting that, moving it around or doing something stupid with it, if it makes it harder for the user to click that button, that can be quite a big signal to Google that something's off with this site. It's a bit sketchy maybe. So generally if you can avoid, avoid animations or at least keep them minimal, that's probably for the best.

Yeah. Do you ever encounter any real issues with video? Like with page load speed and stuff

Can do If you load a massive file?

Yeah, yeah. Videos that are playing straight off the bat, I think, yeah, probably generally speaking, most of the time if you are loading something later down the page or if you're loading it with a play icon is not going to cause too much of an issue. It's actually loading until you clicking on things. But like hero sections for example, that can be a bit of an issue with speed.

Just asking you Mel, you know how we have the argument of whether you design first content first. What is actually your preferred? I think I know the answer,

It is not the answer that you want, but it depends, depends where the request has come from for the page and what the purpose of the page is. So for new pages that we are suggesting to the client for a particular marketing purpose, then I think the content would come first. If it's a full web project, a new website, and it didn't have any sort of layouts or style sheets, is that what you call them? Style sheets?

I don't call 'em style sheets, just does, that's what they're called

Then I think the design has to come first.

Yeah,

That's not the answer that you wanted. No, we do it both ways though, don't we?

Yeah,

Yeah.

I think like you said, if it's a fresh design then I guess it's good for you to see, you can see what the old site looks like. Let's say for example, we've got an old site and we're redesigning it, you can see that layout, but nine times out of 10 we're completely changing that, aren't we? So

For

You to see what that layout looks like, I think a big one that I want to bring up that we've had almost big scraps over recently is, and there's no real right or wrong answer to this is when we're having service pages all follow the same structure.

No, there is a correct answer. There's

Not, I don't think there is

No there.

So let's outline the argument, right?

There's a balance between the two I think, but go on.

For people who don't understand what we're talking about, let's say there's a website and they've got six core service pages, six services, essentially what we would do is we would create a service page layout or design, whatever you want to call it, and then for that service page specifically I would say right, here's the service page layout for the window cleaning page. I dunno where that came from, Mel content over to you sort of thing.

And then potentially if they've got a different service painting decking or something, I don't know where these are coming from, here's the painting decking layout. They're both similar but maybe they've got a slightly different section. What has different columns on there? They've got a section with a slightly different layout. Let's just keep it simple and then vice versa for the other four service pages that they've got. So you've basically got a service page layout with maybe six variations of Josh's argument is that all those service pages and I'm with him and against him at the same time, all of those service pages should follow the same layout ideally

Because it makes

His job easier. Yes, it does

Make his job easier,

Not

Just that it makes my job easy, it also makes it easy for the client. Futureproof in the website and Josh is a big thing of future proofing future.

That's biggest bit for

Adding extra pages you mean?

Yeah, well adding more service pages. So expanding on it a little bit more, the way you've got to think about this if you've got a site and you're aware of these things is when you're adding blog posts for example, you're doing the exact same thing. You'll add a post in the backend and it'll take the same formatting for all of your posts across the front end of the site. So the idea is that you're doing the same for your service pages, you're just popping the content in the backend and it's automatically popping it into the right areas on the front end. And I do see where you're coming from because for some services for example, you might want to include a video to explain the service a bit better or you might want to have some images and there are ways that you can do this, but generally if you've got loads of service pages and you ever want to come to move your site elsewhere to a different host or different CMS or something like that, it's going to be a hell of a lot harder to get all those pieces and move them about, put them back on your new CMS, which is generally why I tend to say if you can do it all in the same way each time, it's going to be a lot better because then it's literally a case of you make one template on the new place and it's just ready to go straight off the bat.

It makes development, future development a hell of a lot easier. Yeah,

I see where you're coming from, but I think that's too rigid for me. I like to have the flexibility of saying, okay, so this particular service requires different modules on the page, so this needs to be a bulleted section, this needs to be a slider tunnel of sliders, and if you can't do that, then I feel like you're missing an opportunity to present information in a way that's easier for the user to consume.

And I guess we've been playing about with this bit recently, there's a few other things that we can do to add that additional flexibility. One thing on WordPress for example, you can set different templates for different pages. So say you could set all of your service pages to follow one template or one layout for example, and then maybe two or three of them you could say, okay, these three can use a different one, and then you've just got two to build on whatever future website that you may or end up moving to. It's when they're all using unique templates or not even unique templates at that point. Just unique content, unique layouts and everything. That's what really gets to me.

Let's use an example that a site that has hundred services, God forbid they've got a hundred different services. I do agree then that this format is the only real way to go

And we could potentially have a service template, A, B, C, maybe even three variations of a service page and then we can chop and change. So like Josh says, we're not designing 100 different pages, we're designing three, they're making the content work on them. I think it keeps the CMS, especially in WordPress's case, a lot cleaner. For those of you that don't know what post types are. Essentially if you've got a blog that's a post type, we would then be creating a service as a different post type. You'll probably be able to explain a little bit better, but I think if in a case in that that's where it's golden, it really,

Yeah, post types as well. I think we've covered on a previous pod actually.

Maybe a short or

Something have been a short could be worth looking up. But yeah, generally all your different content types should be separated out over post types. Again, makes development in the future a lot easier.

Yeah, same goes with other post types. You've got services, you've got blog posts, you might have events, you might have case studies. There's lots that you could probably think of in terms of different, we've got lots of different ones. We've got podcasts, we've got shorts, we've got projects. So depending on the client then we might have to consider that whole structure. If they've only got four services, four core services, then you add a post type because they might want to have more in the future. I knew you would say that. Yeah, it does make sense, the future proof in. But in that case also we could create a page layout and then duplicate it and then make a variation of it for the other service just for argument's sake

Could, I mean there's nothing stopping you doing that, really having all your different layouts and things when you are doing something like this, say you've got loads of different unique layouts. Generally speaking, when you're developing these kind of things, you add in variables for things like colours and fonts, sizes for example. Other stuff as well that I can't think of on the spot. If you for example changed or dropped a brand colour, you'd have to go potentially, if you've not done it right in the first place, you'd potentially have to go into every single one of these layouts to change things in the future. Whereas if you've got one and you've got your example of a hundred different service pages, you just change it on one and it's done across all a hundred of

Them.

So the more of the template pages that you have, the more you've got to maintain in the future.

Yeah, that's a very good point.

It doesn't think, this whole argument doesn't really apply to me as much, actually applies more to Mel because I think from Mel's approach it's about making the content work for that specific service as an example. So like we've said before, that might require a slight tweak or different section or different variation of a section. We've done this though we we've gone through that process. I've been able to make it

Semi variable point.

Semi variable, yeah,

That's why I'm calling it. There's probably an actual term for this, but I flexible off the top of my head, flexible to a degree for anyone listening that's interested I guess that's using, so generally when you're doing custom post types like this, you're using advanced custom fields on WordPress anyway,

Which

Is just like fields that you can put your data in. You map those out to places on the front end. There's a pro feature in advanced custom fields called a repeater and that allows you to repeat those fields over and over again. So if we set up a somewhat flexible layout and put it in a repeater field, we can then add multiple of those flexible layouts and it only needs to be mapped out once. Very hard to explain just through voice and hand movements and stuff that has,

Hi, I'm developer, it's all in here. It makes sense in here, you can see it.

Yeah, I think all that considered though, we do generally, we might have a few debates here and there between us three, but we get there, we

Do, and the end product always works and looks perfect

And most important thing

And it's scalable.

Oh, nothing better. You enjoyed listening to that til,

Yeah. I couldn't get a word anyways. I was going to ask if there's any specific builders that you prefer to use for template and stuff like that? Not bricks.

No. Honestly, you don't know.

No, I am the user. Consider me the user, not you because I'm like the client who has to go in afterwards and add in the bits that change

You see

On the page.

But if you are doing stuff, I just like these two scratch. Yeah. So if you are doing stuff on the backend like blog posts for

Example,

Or services using advanced custom fields like we spoke about, then it doesn't make any difference. You just have the continent in the backend, the front hundreds

Already done. It looks it's far more complex than for example Divo. Yeah,

Because Because everything's nested way more powerful,

Collapsed. So in order to be able to see what you're editing, you have to uncollapse absolutely everything and find it within all of these nested tables or fields or whatever you call them. And for me as a visual person, I struggle with that.

It is visual though. You see the can see the and things they do look the same. Yeah, so

Can name them so you can't fat it out without opening every one of them and looking for them. I feel like I'm on a treasure hunt. I'm like, where has Josh hidden the information? No, is it in here? No. Is it in here?

I can definitely appreciate that. It is more complicated than Dvy. Divvy is very good and very user-friendly. It

Is, yeah,

It is nowhere near as flexible as BrickX, though. You can do so much more with BrickX and BrickX is somehow way more flexible, way more functional, and way more lightweight than d's. I think the issue really is that Dvy is putting so many features in and making them all so accessible that it is just overloaded with additional bits. Whereas Bricks is able to do all this stuff because of how little it gives you. As weird as that sounds, it gives you all the independent elements and you've got to build it up to do what you want. Yeah.

Can you explain to me as a lay person, not a developer, so probably

Not

Nice and simple, what the difference is between CMS, like WordPress and a builder like Diva and why you can sometimes just use one but sometimes use both.

Yes,

Go for it.

Okay, I'll do my best. So CMS is content management system. That's where all your content goes. So all of your blog posts, for example, all of your products, all of your pages and other post types or services or whatever you may be doing on your website, they're all stored in your CMS as separate entities.

Let's say, and you can use this is you can use the CMS on its own usually with a default theme or something like that. WordPress has a few that you can just get for free WordPress, whatever the year is theme and they'll map out a lot of that content by default for you. So if you go to your pages, your title will be in the right place and the content will be in the right place, but it'll be very basic. Adding a builder like Bricks or Divvy or making a theme of your own gives you the flexibility of creating the layouts exactly how you want them adding in global elements that can be repeated across different areas. For example, the sky's the limit with a lot of the builders because they're getting very, very good nowadays, like functionality wise, almost as good as just writing the code as it is and just coding it from scratch. So yeah, main difference, CMS and builder CMS is generally all the stuff in the back and builder is what you're seeing on the front, but you can use it without a builder and just see less good stuff on the front. Okay,

That makes sense. What about Elementor?

We don't talk about Elementor

Do

Not.

I don't mind Elemental

Like Bruno.

I've used Elementor a few times. I didn't mind it, but I preferred Divvy and I actually do like bricks, but it is probably without some, I'm sure with some training from Josh and I've had a few bits, I could start to learn to put a page together to the same level that I could in divvy, if that makes sense. If I worded that right. I think I just do appreciate now that BrickX is so much lighter. I use RTS as an example. We built that in BrickX and it's fast. It's so much faster than with the divvy builders, so that's going to make a massive difference to the client. So although I can't probably do as much dev work as I used to be able to, it doesn't really matter because that's not really my remit, it's just I'd normally step in if Josh's needed some help developing few other pages or whatever.

Yeah. One thing I will say is Brix is definitely more developer focused or developer oriented than Divvy. Divvy is there for, I'd say pretty much anyone to be able to jump in and make a change, at least basic changes anyway. Whereas BrickX, you really have to kind of understand how HTML is laid out or at least some basic level of how HTML is laid out.

Yeah, what's making me laugh is that since we switched to Bricks, I was like, oh hey brick, hey bricks. Because no one likes change though. Do at the end of the day, no

One Not bad change. No, I've never used

Brick. I've used the other two

Bricks. Can you train me because I'm really struggling with it. I can't comment on it

For you though. You are only really using the CMS though.

Yes.

So you're not using bricks, it's just Bricks is driving. I

Have to use bricks to add and change the content.

Only as an example. Going back to the service pages, only on the non templated pages. You

Should be on my side Mel. Really?

Yeah,

With the templated service pages.

I'm hearing you because you are only having to step into the CMS and update the content in the CMS.

You know what I like

Go on

Default editor, it's a plain page and you paste in the copy

Google Doc.

I can even put spaces between the paragraphs.

Oh, go on. Tell everybody what you sent to me the other day. 32

Pixel. 32 pixel between paragraphs 15 before and after an image. Do you know what

Josh could? Probably is? Don't let Josh hear that. Actually,

That's my role.

So Mel, do you know in the default editor, she adds spaces with the elements? You know how you can add elements in the default editor?

Yeah.

So when Mel adds a copy in, she had a paragraph one and two and she wants an image below that before she's got more copy, she has the spacer in, then the image spacer, then text module again in the default editor

So it can breathe.

There probably could be some code that Josh could add. Having thought about this, where that is a set rule.

Yeah. So after every image and every paragraph,

Not always. Not

Always. Okay. If

The image finishes the section and after that comes a new section, it would need a 32 pixel break after.

Right. Okay.

That's why I do I hand, this is why it takes

Long. Why 32? Is it just because it looked right front

Then I 32. Tom and you are going to dispute me this. It's because Tom's 32. No, because he told me 32 when I first

Started

You went just put in 32.

No, don't you bring,

You did

You did. Don't you bring me into this your

Mind about two years.

Oh yeah, I can remember now.

32 you said. So I've always used 32.

So what you should do really if you wanted to be futureproof and do it then no Josh, if you wanted to be futureproof and do it right, if you wanted to change that 32 pixels to 64,

Yeah.

How many times would you have to do that now?

Hundreds

Of times. So how much easier would it be if you could do it in just one

Change? Well, much easier

Be hell a lot easier. But you know what? Because she's so stubborn, she'd do it. She'd go into each one.

Sam not having this

I'd spend days.

Yeah, well, I mean you'll have to because you've already started this way, but if you were to start again from scratch, then you could add each one, give it like a class for example, and then target that class and say, this one that's below an image is always going to be 18

Or this is where you lose me, Josh, because we have this conversation so often and you'll go, well, you just put it in the class or you put it in the style sheet or you put it in this or you put it in that. And it's for a non-developer, it's making Chinese.

All you've got to think is if you add one below an image, give it something unique like image spacer. And then if it's under a paragraph spacer and if it's under a section, section spacer, and then every image spacer gets the same rule, every paragraph, and so on and so on.

And if you wanted to increase your image spacer by two pixels, you just type it into a style sheet.

What's it?

Well, sorry. No, lemme rephrase that. Josh just typed into a style sheet. You don't touch the style sheet.

I've got a question for you. So we just said there that I'm a lay person in terms of developing, so I don't know what's possible and what's not. But as a designer, I guess you have to know what's possible when you are asking Josh to do it. So you must know some,

You think a lot of,

So you must know. It's like I think I've heard you say this before and it's true, you are the architect, Josh is the builder, but an architect has to know whether something is possible

Engineer,

Engineer when they're asking them to do it, because otherwise you could potentially be wasting your time putting together a design that can't be implemented. Have you ever asked Josh to do anything he can't do or he won't do I won ever asked him to do anything that he can't do? I did the other day on Shopify and he said that's just not possible on Shopify. And I had no idea. I'm not a developer. I did you. What was that

Josh

Like

When could I not do something? Don't believe you Josh. Like crumbling. No, because you said our options for design are limited in Shopify and what we can and we cannot do, and therefore we don't have much control over how the page looks for Brads.

Yeah. So I suppose I should probably follow up with limited in terms of what we can do without

Breaking it.

No, I was going to say budget for making larger scale changes

More

Complex.

Yeah.

Realistically you can do as much as you can in WordPress. You've just got to a lot

Of spend more time.

Yeah, I spend more time. A lot of Shopify stuff. You've got to write the code for yourself if you're going to do it or get that code from somewhere

Across more bridges. So

It's not that you can't do it

Realistically speaking as well because in this particular instance, they've already got a theme that they're quite happy with. It would be a case of making new God, what do they call 'em on Shopify? I can't remember. But new modules and things like that for Shopify and setting up fields for those and mapping out the data to those fields and stuff. Whereas they've already got some that kind of fit the bill already. They just don't look as good as what we would do ourselves.

Okay.

That

Makes sense.

It makes

Sense to

Use what they've got.

I'm sorry. So anyway, Tom, is there anything you've ever asked Josh to do that he can't do?

I can't think off the top of my head now, to be fair. And his head's going to be like, ah. I think we've had a few things where he is gone. Well usually moan. He's never a designer. I haven't showed him where he is, not moan, but to be fair to him, he has a go at everything and 95% of the time, in fact I've got no argument to say why I can't say a hundred percent so far working with Josh.

What a man that

Is not been able to a reference for Josh. I really don't want to say it. I'm only joking

A hundred percent of the time,

A hundred percent mate. There might be iterations of my original design, but generally speaking we come to an agreement. Does that make sense?

Yeah.

Is that because

I suggest something that's

Better. I was just going to say I'll let you pay me for that comment later. No, generally speaking, yeah. He can develop most things that I

Design and I assume that's because you know what's possible and therefore you, that's

Because I'm a class designer,

You design within the constraints.

I think what it is, going back to something I said a bit earlier is when designers and developers work together from the beginning of a project rather than design does hours and hours of work and then throws it over to a developer, it makes the process way simpler because you can address potential issues as they arise rather than building an entire layout around something that might be an issue. And then when it gets over to me, for example, or another developer, you're like, oh yeah, that bit can't be done and therefore this other stuff can't be done. Yeah, if you're addressing stuff like that really early on in the process, it makes it a lot easier.

I will say also with regards to Marketing Labs, because we are a small team, everybody's involved in everything from the get-go. You don't get that in bugger organisations. You'll have one department do one thing, pass it onto another department, pass it back. There isn't collaboration there.

Yeah. You've also got the time differences between those departments.

It's phase of the design phase passes on to

Yeah, so you've got a few months, well maybe a month or a few months in design and then content and then devil, whatever way around it may be. And if stuff needs to go back, I mean people may have forgot what they were doing like a month before or two months before. Yeah,

Absolutely. And that's such a benefit for the client. And again, because they get to see it at stages throughout its progress, don't they? So we'll always send them a link to the staging site so that they can have a look as it's

Progressing feedback so

Any of their feedback can be incorporated before it's too far along and almost near in completion.

I feel like we've got a good phased process now when it comes to design and developing of websites. I think coming back to your question, I have got better at understanding that development process, but comes back to what you've just said is that he's literally sat next to me and I can just go, just come and have a little log gander at this, and then he goes, what do you think? No,

I often hear him say that actually from the other side of the office.

My favourite reaction from Josh is where he just goes

Silent,

Walks up in the air, doesn't say something, you can see the cogs going, and then I'll be talking him through something. He'll be looking at it and then he'll just go, just shut up taking it in. You just have to let him do his

Thing. You both have a way of working, but you compliment each other really well.

Thanks, Mel.

I'm tough. It's nice to see the two of you working together because you do compliment each other very, very well.

Dev bromance,

Shook hands.

You've spoken about staging a little bit, but is there any other testing mechanisms I suppose you could call it when you're testing out the balance between creativity and functionality?

Testing the balance?

That's a good

Question. User testing, I guess I'm not sure if that is quite the question you're asking though, but having, if you are really concerned about a change, for example, or even a brand new site and you want to know if your existing users or potential users are going to find it, okay, you can pay for user testing, which is you just get either random people or potentially get your customers, your good customers to visit your new site in a beta and give their feedback and suggestions. And if something's not quite working, you are probably going to find it with a few hundred random testers versus a small team of people. Checking

AB testing as well is always really useful for things like CTA buttons and placement of,

That's a very good one for design, actually, different design tweaks.

You can run your ads to them as well and set it up on ads, like a 50 50 test.

There's lots of things. I think user testing is quite important. We've done it a few times with different websites. Most of the time when we redesign, we don't go so far away from what their original site was that maybe a user would just go, oh, what's this? It comes back to the dbrand rebrand thing. If they're completely rebranding a business, then they might be like, oh, they have changed completely name colours, everything, layout, the completely different services, everything. But I think in most cases we'll just give it a complete refresh. Refresh is the good word for it, I think. And new lease life

Facelift. I like that.

I like that one. Nice. So user testing, staging environments, and AB testing.

Nice. Enjoyed that til, did you?

Yeah,

I did. Did you Mel?

I did.

That's all right.

I've

Had

Better.

Nice. See you in a bit then til.

See you. Bye.

Bye. Bye.

That's all for today's episode on the Creative Functional Balance in website builds a huge thank you to our guests for sharing their insights and expertise. Remember finding that delicate balance between creative vision and functional reality is key to driving success in website development. Join us next time on marketing blobs for more expert discussions and practical advice. See you next time.