Are you confident you have the right design workflow?

Paul Boag

On this episode of the Boagworld Show, we look at how we approach the design process. Are we designing in the right way to ensure the best user interface possible?

This weeks show is sponsored by Balsamiq and FullStory.


Paul: On this episode of the Boagworld show we look at how to approach the design process. Are we designing in the right way to ensure the best user interface is possible?

This season of the podcast is sponsored by Balsamiq and Fullstory.

Hello and welcome to the Boagworld show, the podcast about all aspects of digital design, development and strategy. My name is Paul Boag. Joining me on this week's show is usability, user-interface, UX expert Jason Pamental.

Hello. How are you?

Jason: Good, how are you doing?

Paul: Did you like my introduction? I thought I'd big you up.

Jason: Oh, it was … I'm sure you could've stuffed a few more words in there. But it sounded pretty good. It's made sound very impressive.

Paul: Well, I think my main aim was to big you up so I could then say, "Oh, and Leigh's on the show, who is a technological Luddite and can't even work out to how to log in to Skype."

Leigh: So I've had a little bit of a problem, yes, I admit it.

Jason: So I'm just your foil. Okay.

Paul: Basically, yes. But obviously every word I said, Jason, I meant 100%.

It's so good to talk to you again. It's been a while. How's life?

Jason: Things are going well, thank you very much.

Paul: What are you up to these days?

Jason: I am running the design and strategy and development team at a company called Isovera, just outside Boston. So I've been doing that for almost two years now. And then still doing lots of talks and workshops and writing about Web typography. More recently with variable fonts. I've been booked up quite a lot this year. I'll be speaking at An Event Apart and TYPO Labs in Berlin and Smashing Conference in Freiburg.

Paul: Wow.

Jason: So yes, it's gonna be a busy year.

Paul: Well, variable fonts are the cool trendy thing, aren't they, at the moment?

Jason: Well I will stand by my claim that they are going to be the biggest thing since responsive design itself. [crosstalk 00:02:20] big deal.

Paul: Now go on, you've got to back up. Go on, why? I mean surely we're just talking about fonts a bit bigger or a bit smaller. I mean what's the big deal?

Jason: Okay.

Paul: You're gonna get the picture now, I can tell.

There was a big breath and then, "Okay."

Go on, go on then.

Jason: Alright, so I don't wanna derail the whole show about it but-

Paul: No, that's fine.

Jason: So there's three ways I think that they're going to be really transformative.

One is that it gives us a design vocabulary that we haven't had on the Web. In all the axes of variation from width to weight to slant, optical size, all different manner of permutations of the typeface itself all within a single file, which leads us to the performance gain that you get from that.

Paul: Oh, yeah, of course.

Jason: So you'll have no penalty to have that greater design vocabulary. So we can be more expressive in our design and be more performant and have all that with only one or two font requests. And it's all animatable and variable within CSS.

And then the third aspect of this is what I think really transforms what we think of as good typography itself, really at its core. Because we can tailor the type to the context in which it's being viewed. So we could make the type slightly narrower on a small screen to fit more characters per line.

Paul: Ah!

Jason: And we can also react to things like ambient light. So the Web API doesn't work that well but in a native app you could increase the grade of the text when the light level is lower.

Paul: Oh, that's cool.

Jason: Yeah. And think of how that, as an accessibility aid, if you enable that through the UI for someone with low vision.

Paul: That's just brilliant.

Jason: And so text grade … The difference between that and weight is that it doesn't reflow the text. So your design system remains intact. It doesn't reflow anything, it just slightly increases the stroke weight all around to give it slightly more contrast from foreground and background to make it easier to read.

Paul: Wow, that sounds very cool.

Leigh: Cool.

Jason: Yeah.

Paul: Leigh, have you do anything? Have you looked at variable fonts yet?

Leigh: I played with a code pen, sort of a demo example, and I was quite surprised just how many different things you can kind of interact with. I was expecting weight but I wasn't expecting, like, adjustable x-height of characters or these other little things.

And you can make a single font look very kind of different and customized. I didn't know whether that was a bad thing or a good thing.

Paul: It's like anything.

Leigh: I liked it.

Paul: It's dangerous if it's in wrong hands, isn't it?

Leigh: Yeah, exactly.

Jason: Right.

But I think that's always been true of every design iteration.

Leigh: Yeah. [crosstalk 00:05:28]

Jason: But the x-height, along with that is the height of the ascenders and descenders.

So one of the little demos that I was working on for one of the type companies is like a really big headline that you might want to set the line height really close together to create a big, solid sort of unit. But then the ascenders and descenders might collide. You can have a variation axis that makes those descenders slightly shorter.

Paul: Yeah. Awesome.

Jason: So the bottom portion of a "g" you could like bring up just a tiny little bit so that you could still get like a really nice typographic impact with that headline without having the characters bump into each other.

Paul: But if I was a type designer I would be spinning in my proverbial grave at this point because-

Jason: But that's just it though. It's only what the type designer allows. It's not something that you're forcing. It's only what the type designer chooses to exposes as an axis of variation.

Paul: Oh! Right. So they could say, "You can't mess with the x-height," for example.

Leigh: So it's like-

Jason: Exactly.

Paul: Oh, okay.

Leigh: Yeah. I suppose your fonts are becoming responsive like, "We didn't expect our designs to start becoming a single column and breaking up but now it's part of what is expected of a design." So I guess if you're designing variable fonts you define what you can vary.

Paul: Yes.

Leigh: Well I did wonder what kind of effect it will have on browser performance. Because all this new maths is now being expected of the browser. I'm not quite sure-

Jason: I haven't seen any issues with that so far. And I mean I've been with working with them pretty much since they were introduced, for about a year now. And it's not really any different than rendering any other type.

Leigh: Okay. So the maths is happening kind of as it's displaying them and then it's all done and that's it?

Jason: Yeah, yeah.

Leigh: I suppose it wouldn't be do anything [inaudible 00:07:23] pages.

Jason: And all the stuff that we do to animate it is really for showing people what's happening.

Paul: Yeah, that's true.

"So what's the browser support like?" is the obvious question.

Jason: It's remarkably good for something that's only been around for a year. Full support shipped in Safari and iOS across the board in September with High Sierra and iOS 11. It's also shipped in October in Chrome on Mac and Windows. And it's in active development in Edge and Firefox, slated to ship this spring, probably May timeframe.

Paul: Good. And I imagine the fallback isn't too painful. Presumably you don't do anything ridiculously radical with the fonts you're using. Yeah.

Jason: Yeah. It does make that a little bit trickier but also, to keep in mind, that's also going to change because they've built support into the OS.

Paul: Right.

Jason: So it's quite likely we'll see variable fonts shipping in the OS. Well actually they already are. Windows has one called Bahnschrift that just has a weight axis, but it's there. And technically San Francisco on the Mac essentially is a variable font. That incorporates a lot of the same technology ideas. It's not exposed in the same way. But that's … You know, pretty soon though we'll have fallbacks that are actually also variable.

Paul: Oh, I like it.

Leigh: Yeah, me too.

Paul: This all sounds very exciting.

Leigh: Excellent.

Jason: Yeah, it's gotten me quite excited this year. And what I love is the reaction that I get from designers and developers and brand owners is equally enthusiastic. Because there's something there for everyone.

Paul: Yeah, that's very true. I hadn't thought of that. We all win from it. Because I mean … The bit, if I'm honest, and this is probably a sad reflection of me losing my design heritage, but the bit I'm most excited about is the idea of the performance benefits of not having to have lots of different versions of the same font effectively being downloaded. That's brilliant.

Leigh: It seems so wasteful.

Paul: Yeah, absolutely.

Jason: Yeah. Well it lets us-

Leigh: Having to decide which weights you need as well. I don't like having to decide.

Jason: Yeah, and that's something that … In print design it would be pretty normal for you to say, "At some mid-level headline I kind of like the medium weight. I don't really want the bold."

And it lets you fine tune all of those things to get just the right kind of hierarchy. And Mark Bolton I think was the one lamenting whether or not art direction is a thing on the Web. And I think it could be, bringing tools like this back in.

And you can even build a lot of that into the content management system. Actually create like expert design ability to typeset a headline rather than just flow the text in.

Paul: I mean the other thing that I like about it is, again, I think the more tools we get typographically the better. Because so many websites kind of crowbar in imagery just to add some visual interest when they don't actually add any value to the design itself. So if you've got really good quality typographic tools then that enables you to do much more. It's good.

Jason: I totally agree.

Paul: Okay. So I mean none of that is what we're supposed to be talking about. But that's actually a lot more interesting than what we are going to talk about. And that said, the entire season is supposed to be about the fundamentals of user interface design and you can't get much more fundamental than something like this, really. So there we go. So it does have a purpose of some description. We're gonna go with that.


What we are gonna be talking about on this show is we're gonna be talking about workflows. And how we go about the process that we use to design these days. How we go about doing design, what's involved in it, etc., etc.

So with that in mind I thought it would be quite cool … I'm quite interested in what tools you guys use these days. Right? Because obviously things have changed a lot since my day. And so what do the cool kids use these days? I mean obviously we've got things like Sketch and InVision. Even I use those. But what else?

Jason: Adobe XD has come a long way.

Paul: Really?

Jason: Yeah, it's really turning into quite a good tool, and in a pretty short amount of time. Now it's gaining a lot of the similar features that Sketch has but it also has some really neat things about creating repeating elements. So you kind of mock up a card and then you can sort of click and drag and just make multiples of it in a grid.

Paul: Oh, almost a bit like you get from using Craft in Sketch.

Jason: Yes. And it sort of predated that. So they kind of scooped them on that feature a little bit. And now they both have the ability to tie in pretty easily with tools like Zeplin, which are really great for creating that bridge between design and development. It can sort of create effectively a style guide out of the main source file.

Paul: Ah, that's quite useful.

Jason: Yeah, it makes it for really good hand-offs between design and development, to really create that quick documentation of the design that you've been working on.

Paul: Also it has the benefit of ensuring design consistency if you're using multiple teams, etc.

Jason: Yeah. And it exposes things that you missed pretty quickly. So if you used slightly different styles in different areas are gonna show up as totally separate objects. And you'll start to see where you might have missed something and set a headline slightly differently from one page to the next or something like that.

Paul: Yeah.

Jason: Figma's looking pretty cool too. That's an entirely online one. Have you looked at that, Leigh?

Leigh: Yeah, I've looked at that. It's pretty much Sketch in the browser, apart from a few little things it hasn't got. And it's got a few little extra bits and bobs which … Yeah, very, very promising. But for something … I know you can download a kind of offline version, something a bit browsery which I'm not quite comfortable with at the moment.

But I regularly seem to do every project in a new tool. I'm just a kind of natural explorer of utils.

Yeah, I've tried Figma, I've tried Sketch, I've tried XD. Is Reflow still a thing? But then I always come back to this underlying, you know, just use HTML and CSS. And I'm still looking for the ultimate tool that can take the power of HTML and CSS and do it in a way that is more designery. But it hasn't happened just yet.

Paul: So what do you normally work in, Leigh? Are you mainly working in HTML and CSS straight away?

Leigh: Well it depends, as with everything else.

It depends how much you've got to kind of show up front or try to get in the browser as quickly as possible, because certain things can be quicker. But then trying to get a look and feel across is far quicker in a classic design tool.

And Sketch has been the go-to recently. Probably because of all the plugins that are available to fill the gaps. So if you need to prototype you can plug it in and do things that Sketch wasn't designed to do originally.

Jason: Yeah, those are some of the things that we found pretty interesting. We've played around with most of these things in the office. And we ended up trying to standardize as much as possible on Sketch so that we could share things. And one of the designers started working on sort of a starting point file for wireframes, and then also for comps that sort of had a lot of our … the basic things that we would want built in. Sort of like starting with pattern [inaudible 00:16:17].

Leigh: Pattern library.

Jason: Yeah, exactly.

And we work with Pattern Lab a lot, specifically in the development process. So that's kind of our path is going from …

Well we start with information architecture, content modeling, wireframes. And once we've worked those things out then we usually get started into style tiles, which could really be done in anything. It doesn't really matter. But usually Sketch because we've got some templates to start with there.

And then once we get to an interior page mock-up from there, and we get approval on one of those as we work our way up the website towards the home page, we can actually start breaking that down into patterns and pulling it into code. So that way we can very quickly start to see how these things behave in the browser.

Leigh: Absolutely, yeah, yeah.

So a similar approach with us. Kind of simultaneously doing wireframes, either static or interactive, and developing the kind of aesthetic side separately but simultaneously with mood boards, style tiles, that kind of thing. Yeah, Sketch.

But trying to get that kind of componentized aspect as quickly as possible, and if possible, in the browser.

Paul: Talking of the componentized aspect of it and when you're doing that in Sketch. Are there any plugins on tools or that kind of thing that make creating those pattern libraries within Sketch and then sharing those library elements between designers? Is there anything like that?

Jason: Well the notion of symbols is pretty central in Sketch.

Paul: Yeah. That's true, you could use that.

Jason: So that's what we've been using quite a bit. But then there's … Craft is really helpful for starting to create some of these things and give them a little bit more life so that you can try them with different sets of content and that kind of thing.

Paul: I gotta say. I mean these days the tools are just so good. You know, it's actually making me wish I was doing design again. I do bits and pieces of like prototyping and wireframing, is about as designy as I ever get. So I'm doing stuff in Sketch. And it just pulls you in. And all of these tools and creating the animations you can do and stuff like that, it makes me hanker for the days that I was a UI designer and I just sat in front of it all day. Because it's just so easy. Young people today don't know they're born.

Jason: Boy it didn't really take as long to devolve into the old-man-shakes-fist-at-sky mentality.

Paul: If I'm involved it happens very quickly. But it's true. They've got … There's such great tools these days. It's really cool.

Jason: Oh, it's-

Leigh: Oh, no, I've been trying to tell Ed in this office about Sketch. He's a Photoshop user. He won't come out of Photoshop. He was opening … and I go, "Yeah, that's great. Sketch looks fantastic." Did he use it? No, no.

Paul: See, he's stuck in the past. The only thing that saves him is he's such a-

Leigh: [crosstalk 00:19:39] he's like 15 years younger than me.

Paul: Sorry?

Leigh: And he's like 15 years younger than me.

Paul: I know.

Leigh: He's a Luddite. It's too soon.

Jason: I think-

Paul: But the only thing that saves him is he's such a damn good designer so you could give him-

Leigh: Well exactly. I can't-

Paul: … crayons and he'd produce a great design.

Leigh: Absolutely.

Jason: I think one of the things, one of the little notes, that you had in the show prep was about whether or not the tools matter. And I got to thinking about that. I think it's really relevant to what we've talking about.

Now there's sort of two criteria that I tend to consider them by. And one is whatever your tool is it shouldn't slow down your thinking. You know you've gotta be comfortable enough in it to sort of sketch freely. For me Illustrator is probably the one that I'm most comfortable in. Because I've been using Illustrator and Photoshop since like versions 2 and 3. And so they're very much in my sort of DNA.

But then the second half of that is it has to improve the communication of ideas between the designer and the client and the developer. And that's where the tension comes in. Because you might be really great in Photoshop, or InDesign for that matter, and maybe you're really comfortable working that way. But if it's not a smooth transition between you and the person that has to be put it together then that just creates inefficiency that's pretty hard to get over sometimes, or wastes a lot of time.

Paul: Communication is absolutely vital with these tools.

Which actually transitions me very nicely into talking about our sponsor, or our first sponsor, which is Balsamiq, which is one of the tools that we've been talking about.

Basically it's a tool for wireframing in particular. So the very early parts of the process where you just want to quickly and easily create and show off possible directions. It's like sketching but electronically and faster basically.

Now it does have a desktop app and you could go buy the desktop app. But the real interesting stuff is their cloud-based app that they use now because it's great for that collaboration. It's great for ensuring a communication between various team members talking about ideas, working on something together.

It was interesting. I was working with a client recently and they were talking about having a meeting, and the minute any client talks about having a meeting I get depressed, where they were talking about bringing all of the various stakeholders together into a room to work out what they needed to do and what this thing needed to do.

And they would have gone round and round in circles and everybody would have gone away with a slightly different impression of what was agreed and what was gonna be built and all the rest of it.

So instead I suggested why don't you do it as a workshop exercise and get people creating different possible approaches to the interface using Balsamiq? And that's exactly what they did and it went incredibly well because Balsamiq is so easy. You know, anybody can pick it up and have a go at it which makes it great for that kind of collaboration and experimentation. So you could try-

Jason: [inaudible 00:23:13]

Paul: Sorry, go on?

Jason: Well, I was gonna say, I've been a huge fan of it since it launched. I think I used it while it still in beta. I'm gonna pronounce it correctly.

Paul: Yeah, well done.

Jason: But the thing that I love about it is … This had come up … I think this have might been Jared Spool recently, about that fidelity conundrum. And like working in Balsamiq is like working with a sharpy. And you just can't get any more high-fidelity than that. And that's perfect, it keeps you from wasting your time making something that looks like a comp.

Paul: Yep, absolutely. And I fall that into all the time when I prototype. It ends up looking too good and then people don't know what they're looking at. Are they looking at a sketch or are they looking at a final design? What's this thing meant to be?

And it's funny, every single guest that we've had on every week that we talked about Balsamiq have gone, "Oh, yeah, yeah, we use that, we use that."

So if you're not one of the three people in the world … I don't know why they're bothering basically being a sponsor. I think everybody already uses it. But if you're not one of the three people in the world that's using Balsamiq then you can get a 30-day free trial anyway.

But if you go and sign up for that 30-day free trial and then go in to the billing part when you create a free account, and you enter the code into that, which is "BALSAMIQBOAG," all one word, you'll actually get three months instead of one month. And you can get that by going to So there you go.

Well I mean we've kind of already kicked off the discussion portion of the show and done some of the questions. But that's kind of cool and good.

But what we wanna look at is more broadly this issue of collaborating, working, how the workflow should operate. So as we were talking about wireframes and with Balsamiq why don't we continue on that vein?

I'm really interested in when you guys choose to jump into Sketch and when you choose to wireframe something and when you choose to prototype it, and when you choose to do it in HTML. I mean how do you make those kinds of choices of which tool to use at which time?

Jason: At Isovera we were primarily a Drupal development shop. So that's kind of a natural part of the stuff that we work with.

So we often will have some wireframes of key flows early on. But pretty quickly after we have identified the main kinds of content and what the fields are and everything we actually start working right in Drupal. And a lot of the prototyping happens there. So it's the fastest way …

You know, we use InVision for more static prototypes where you've made a few different screens in Sketch or Balsamiq or whatever and you just wanna test some kinds of interaction. And it's great for creating that common conversation between you and the client in particular.

But then once we've figured out the kinds of content we just go right … The starting point that we created for Drupal is sort of black, white and gray, kind of wireframey. And so it's a good starting point for us to build out the content model in the CMS, build out the basic navigation. Now you can start to click through it and maybe do some usability tests.

And then also work with the client right away to see if they can actually the content that they need. Because the biggest downfall that we've seen is until you have the client actually in there creating content you will miss things.

You'll miss connections, you'll miss fields, you'll miss opportunities. And once you can sit them down and say, "Okay, let's see if you really can put your press release in, if you can put your product information in the way you expect and do all those things," then the actual build process is gonna get delayed.

And you can spend all this time prototyping and designing and it's all gonna be wrong because you don't have the right fields or relationships built into it.

Paul: I actually take exactly the same approach.

The sooner you can start putting stuff into a content management system the better. Even if all you're doing to begin with is just blank pages with some navigation that links between them. Because that's enough to take an information architecture.

And then you can start introducing bits of layout, just as Leigh was talking about, of doing some design in the browser. You start adding typography, a bit of layout, a bit of color, that kind of thing. Meanwhile the content people can be in there just putting bullet points in to begin with, or questions that they want to answer on different pages.

And you can kind of increase the fidelity both in terms of design and content within the actual thing you're building, within the actual CMS. And it seems to work very well especially on very content-heavy sites. And maybe doesn't work so well if you're looking at something like a Web app. But certainly in the content-heavy stuff.

Jason: Yeah. It also cuts down on training with the client later on. Because that way they're working in the system from the very early stages.

Paul: Yeah, absolutely.

Jason: I have been doing this … and you could really do it with any CMS. I mean I've been doing it with Drupal-based sites with different teams like this for six or seven years.

And it I think allows us to build a much stronger bond with the client because we're working so closely with them at every stage rather than, "Come in for a workshop, then go away and do a bunch of work, and then come back, and then go away again." It keeps those points of interaction happening all the time.

Paul: Leigh, does that mean that, you know, design comps are dead? Do you still ever produce design comps?

Leigh: Oh yeah, definitely. Because it's that speed to creativity, sitting in front of a code editor-

Paul: No.

Leigh: … isn't a very sort of inspirational way of getting started. It can depend on so many things, timescales, budget. But that …

Really interested in hearing about prototyping inside Drupal. Because we did it twice with Drupal 7, because we're mainly Drupal based here. I can't think why we stopped. I think it may have been just a lack of knowledge of building content types and views, all the Drupal collateral from mine and front-end developers who aren't necessarily Drupal developers to set all that up. So then that involved a lot of developer time doing things. But whether … I mean Drupal 8's improved a lot of things. It might probably be worth trying again at that. Because I tend to use this other CMS called Grav-

Paul: Oh, I know, yeah.

Leigh: … which is just a file-based system. And it's really easy, you don't have to mess around with databases.

But it's not Drupal so you're not working within the constraints, you're not doing all the things you just mentioned about getting the client in there early and identifying what's working them and what isn't. So yeah, I think, definitely, that's just made me think we should try it again. I should try it again.

Jason: Well one of the things that we've found that's central to making that work is exposing the different people in different roles to Drupal in different ways.

So the designers who are doing some of the UX and IA work need to have enough familiarity with Drupal to understand what a content type is, how do you add fields and relationships and that sort of thing. So I have them work with a developer on a content model document. And that helps increase their level of familiarity with it.

And then similarly doing the front-end themeing part has to understand enough about how Drupal content types work. And views, which is basically like database queries for content.

And having that familiarity with what's next to you, in that next job over, really helps everybody communicate better.

And we create these central points of … First it's a content model document and then it's actually going into the admin and trying it out. Does this flow nicely? Should we reorganize it?

One of the nice things with Drupal 8, and again I don't want this to be a Drupal advertisement, but it allows you to customize the admin ordering of things as well as what comes out on the visual side of it once you publish it. So you can tweak the editorial workflow quite easily. And that's really helpful.

Paul: I think that's a really important thing to do. And it's often in my opinion heavily neglected-

Jason: Yes.

Paul: … to think the client's experience, the content producer's experience, which is just as important especially when it comes to teaching them best practice about writing for the Web and that kind of thing.

All of that should be baked into the content management system so that when they sit down to write in the content management system they're actually getting good advice about how to do so.

I mean going back to what you were saying about exposing different people to each other's roles. I mean there's no doubt to get the kind of approach that you're talking about working you have to work very closely with the developers. So I'm kind of quite interested in how both of you achieve that working relationship.

So, Jason, from your perspective, because obviously you're the head of the design and UX and UI side of things, so how do you work with developers?

Jason: Well, one of the reasons why I was interested in actually joining Isovera is I'm in charge of all of it. And I like that.

Paul: Yeah. It-

Jason: So I actually manage both the design and development team. And I do my best to really think of it as one team.

There's only one point in time where I've worked for an agency where design and development were both done within the same company. And I found that be really kind of unnatural.

Paul: Oh, really?

Jason: Yeah. So I'm a much bigger fan of that taking place within a single company.

Paul: Oh, right.

Jason: It just there aren't that many that do both of those things really well.

Paul: Oh, okay. I thought you were saying you found it unnatural that those things did happen in the same company.

Jason: I'm-

Paul: But I totally agree.

Jason: Yeah, yeah.

Paul: I think, you know, it creates a barrier when you're outsourcing development elsewhere.

Jason: Obviously you can do it. I mean lots of companies do.

But I think that it's much more successful when the designers and developers are in the same meetings, they're in the same Slack channels, they're sitting nearby if they're in the office. And that leaning over and asking a question can become really natural.

So there's no trying to figure out what somebody meant. It cuts down on the time it takes. Because if you have to hand something off you've got to be so much more detailed and document everything and write up every other possible way you could interpret what you mean by this. And then someone's still get it wrong, still misunderstand. And they'll have their own vision of what that means when they read it. But when you sit down together and then you know, like [inaudible 00:35:46] when it's in code you're both really both looking at the same thing. And only then do you really know like how it's actually gonna work.

Paul: I remember a great … sorry to interrupt to you-

Jason: Oh, that's okay.

Paul: … a great example of that kind of looking-over-the-shoulder-type thing where I was sitting in a bar with Joe Stump and Daniel Burka who both worked at Digg back in the day when Digg was a huge …

And Joe was telling this story about Daniel was, I dunno, making some change or other to the Digg badge where it said how many people had dug it. And because Joe was in the room … I don't think he was in the room. But he came into the room and walked past Daniel's desk and saw what Daniel was doing and leaned over and said something along the lines of, "If you do that it's gonna take about 200 extra servers." You know. And you don't get that, you don't get that. So what-

Jason: Yeah. You know what that was? I remember that.

Paul: Oh really?

Jason: That was a designer and developer panel at Future of Web Design.

Paul: Oh, was it?

Jason: And I think that might have been when I met you for the very first time.

Paul: Ah.

Jason: And I talk about that conversation with people all the time, about the importance of having that common language between design and development. And they used the word "expensive." And that was their way of saying, "Okay, what you're trying to achieve is gonna … that's gonna take like a couple hundred extra physical servers." You know, this virtual silly stuff, but like physical hardware that we had to go install in racks.

And then being to able to work back and forth to get at the design intent. They wanted to convey reputation and they wanted it to be somewhat realtime. But it didn't have to be absolutely realtime. And so that's how they ended up arriving at a solution. But, yeah, that has stuck with me now for 10 years.

Paul: Yeah. I mean it's a really good story, that summarizes how closely designers and developers are linked with one another. And how often we just kind of ignore that.

And the problem is what then happens is the designer goes off and designs something that's impractical, shows it to the client, the client then signs it off and so as far as everyone's concerned that's what's going to be built, and only then is it shown to the developer who suddenly becomes the bad guy. Which, you know …

Leigh: Well … guilty.

Paul: Yeah, you've got a habit of doing things like that, Leigh.

Jason: Yeah, well, even if-

Paul: You're in quite an interesting position there, Leigh, that you're not sitting side-by-side with a developer. So I'm quite interested in how you deal with this problem.

Leigh: Well, we tend to have weekly calls with clients, and developers are always in on those calls at all stages.

Sometimes you don't really know hard things are until you try it in Drupal. And the more experience you get the more things are … it's more obvious what's going to be tricky.

But sometimes it doesn't really work itself out until a developer really puts their head into and they go, "Hang on, this is gonna be really quite difficult in Drupal, or anything." So it's one of those things we still battle with and I am guilty, as I say, of designing things which …

And I'm trying to keep it in my minds at all times, you know, "Run things past people." But I have created things which have been an absolute pain for backend developers to integrate. But they get there. I like to think of it as a challenge for them. Stretching their skills.

Paul: I mean it is difficult isn't it? Because on one hand why should you have to compromise the user experience based on the technology?

Leigh: Yes. And I can hear you saying that so I'm doing it.

Paul: Which is true on one hand but we live in the real world as well with budgets and timescales and things, so …

Jason: I think it's important to have a balance there. Because I think when you … And so this is … Oh, gosh, this is like the age-old thing, should designers code? Like then we can really go off the rails.

But the argument that people place against designers understanding code or the CMS or anything else is that it would constrain their thinking.

And then the flip side of that is you design something dumb that can't be built or whatever.

There has to be a middle ground because then without that we don't make progress, we don't try something new. And everything all looks the same. So I think it's a matter of needing to know enough to guide but not let that be a limiter. And if you come back and say, "You know, it's really important for us to be able to do something individualized with this H1, because of these reasons. And, yes, I get that's gonna be a little complicated but let's invest a little bit here because it can then pay a dividend across the whole site, versus spending time on this one-off feature over here, maybe we could do that more simply."

So then you have to have the conversation and find the trade-offs to see where it's worth it for that extra effort because you get a much bigger payoff over time.

Paul: As you say it's all about having the conversation and discussing.

Which brings me nicely onto the other player in this little game that we do of designing user interfaces which is the stakeholders, the client, whoever it is, whether internal or an external client.

I mean it always strikes me that we're a bit shit at dealing with these people. And that we tend to treat them a little bit like the enemy. I mean both of you guys have been doing this for a long time. I'm kind of interested in what you've learned about dealing with clients … Well even the word "dealing" has got the right kind of tone to it. Collaborating, working with clients.

Jason: I've written about that in the past. I think language is hugely important. And I really work very hard to avoid that confrontational, sort of antagonistic stance, saying that you're "defending a design" or "dealing with clients."

I think all of those, I think those words are important because they say something to ourselves in how we're thinking about it. So I think the first step in thinking about it differently is teaching yourself to use different words. You need to "educate someone about it." Or you need to "find that alignment of interest." What is it that will motivate that stakeholder to go along with this design direction? It has to accomplish a goal for them as well as it accomplishes a goal for the user.

So by thinking about why this would be a good answer if somebody is in sales how is this going to help increase sales and [inaudible 00:43:16] conversion? If somebody's in marketing how is it going to make this content more shareable?

And I think you have to do your homework in educating yourself about those stakeholders and those clients to understand their motivation and pain points better.

Paul: Do you think there's also, Leigh, do you think there's a degree whereby we don't show work early enough as designers to clients and stakeholders? Because it strikes me that we can get very, very precious about the design we've produced because we're poured hours and hours into them so that makes us defensive when people criticize. But maybe if we showed stuff earlier that would deal with that problem?

Leigh: Oh absolutely. I mean that's why the sort of workflow that it sounds like both Headscape and Jason's company do, of creating the kind of mood, the styles and … That takes away some of this kind of preciousness because you're going in the right direction and they're kind of signing off on that direction.

Then you gotta weigh that up against them actually getting it. So, yeah, trying to show quick page workups but making it clear that this is very quick. So trying to show them a calendar timescale that's very quick, like the next day, this is just a quick … this is the kind of direction we're going in. But making them understand that this isn't a finished product in any way and don't expect it to be all glossy. We're just trying to get the direction right.

Paul: And I see-

Jason: I think that is … No, sorry, go ahead, Paul.

Paul: I was just gonna say I've seen you actually do that in the room with them, Leigh, which seems to have worked quite well, where you're exploring ideas there and then. Because then that does lower their expectations.

Leigh: Well I found myself on conference calls, you know, designing things. What they might think of a big decision is often a simple decision and vice-versa. What they think is easy quite often isn't. "You just change all the spacing." If you're doing that in a static-

Leigh: … design tool that could take a little while. But if you're doing it in code it's quite quick. But changing the colors might be quick in both approaches.

So quite often on calls I am showing … If they say, "I don't know about that color." "Well, look, I've changed it." And refresh, and "Oh, right, yeah." That could have saved a lot of toing and froing and they can kind of be … they feel like they're more involved in the process. So I do a lot of the designing on conference calls.

Jason: I think that's really one of the keys. I mean it's something that … it just sort of in developing our own process, work really hard to teach clients about this way of working so that we're used to answering small questions.

And so let's focus in on these few details and work on those together.

And now we're gonna go to the next iteration and that's going to try and solve a few things building on these early decision that we made.

And the hardest part to navigate, just in my experience so far, is when you have this great relationship with the stakeholders that are in the room, bringing them along, but we haven't had the ultimately responsible and signatory stakeholder. You know, the one who's ultimately gonna sign the check has not been in the room, they haven't been brought along on that journey, that education and that participation. All they're looking at is whatever's been put in front of them at that time. And sometimes it's without you even knowing it. And that's where things can go off the rails.

Paul: So what do you do about that?

Jason: I try and approach it from two directions.

One is to try and emulate Mike Monteiro just a little bit and be very clear at the very beginning about how's going to say no or yes to this ultimately, and make sure that we've identified who the ultimate approving party is, and talk with our immediate stakeholder, if it's not them, at what points do we bring things to these people so that we can be sure that we're moving ahead in the right way. And so that takes a little bit of effort to get the clients to understand that this is really critical and not really all that negotiable, that we have to identify who those people are. Or simple have it noted that if you decide, client stakeholder, that you would prefer not take this to your CEO until the very last minute that that's fine, but if they say they wanna start over again that is on your bill.

And as long as that's clear I don't care how many times you want us to redo it. That's okay. It's not efficient, it's not gonna be pleasant for you or for us really but we'll get there. Just know that we foresee this as a stumbling block.

And the other side of that is to be more emphatic about being present when things are presented so you can have the chance to talk them through a little bit of the backstory and hear what their objections may be firsthand. Because if you can't hear what they're saying it's very hard to get to the why of the objection.

Paul: And that's so true. I mean because what often happens in my experience in that scenario is that they might say something like, "Oh, I'm not very keen on the blue." And so then a) you don't know why. What's with the problem with the blue? What's the underlying issue there? As you say. But b) also, your client, the person you're with, comes back and instead of saying they weren't very keen on the blue they come back and say, "Change the blue," which is a very different to what they actually said. There was a conversation to be had there and you just weren't involved in it.

So yeah, I totally agree with that. One thing I do like is a methodology that Headscape uses in those presentations which, Leigh, you do a lot of, which is creating videos and presenting stuff in video format where they can't look at it without hearing some of the backstory.

Jason: Right, yeah, that's a really good idea.

Leigh: Absolutely, yeah. They can't just look at the design. You're leading them through into the design with the video. Well, I suppose they could skip-

Paul: Yeah, they could. You know …

Leigh: [inaudible 00:50:02] they can't do that [crosstalk 00:50:04].

Paul: And of course the other thing is when they then hand that around to other people those other people get the back story as well, which is another advantage.

Jason: No, that's a good idea. Actually my friend Steve Cross actually talked about doing that while ago. I think he started doing that on some of his own projects and had really good luck with it.

Paul: Well what made me think of it is I've just literally done it today. That's what I've been doing earlier today. So it was front and center in my mind.

Anyway, we could go on forever because actually this is really interesting but Jason is a busy man, he's got other things to do. And to be honest, so have you, dear listener.

But we'll talk about Fullstory and then do a little of wrapping up.

Fullstory is our other sponsor and is basically the best session recorder that you will get out there. So it actually enables you to watch and see how people interact with your products and services. So you can have all kinds of scenarios where that's gonna be absolutely invaluable.

So for example there was one company that had a problem. In their free product they had a large banner encouraging people to upgrade but they continued to get isolated feedback from customers that they couldn't figure out how to upgrade despite this big banner. So they had no context to really understand how people were missing this banner that seemed so obvious to them.

So they set up Fullstory's filter to review users on that page with the intent of upgrading. And upon viewing those various user sessions they realized that experienced users went through to the upgrade, that the experience of doing that upgrade wasn't as straightforward as simply clicking on the banner, there was also many steps for them to go through before they got as far as clicking on the banner.

And so Fullstory kind of helped reveal this whole problem that they just weren't seeing the entirety of. They were just getting a snapshot of fragmented user feedback. So they were able to change the way they operated and that massively increased the number of upgrades they had. So there's lots of stories like that.

Jason: That's great.

Paul: I mean it's a great tool. If you've never used it give it a go. You can sign up and get one month for their pro account for free. No need to enter a credit card. And after that one month it'll continue to work. It'll just only record a thousand sessions per month instead of all of them. It's a tool I've used a lot personally which is why I'm really pleased they're on the show. So to get that deal go to, B-O-A-G.

Alright. I just wanted to share a couple of things for you to check out related to today's podcast. I always try and give you a bit of further reading to go with it.

So the two articles I've picked out today is "How to adopt an iterative approach to user Interface UI design," which outlines many of Jason's points about building in Drupal and that kind of thing, but also that idea of iterating design and content side-by-side within a content management system or suchlike. So to find out more about you can go to

There's another article that I've found which I really enjoyed on the subject is "Why having a UI/UX workflow is awesome and how to build yours." Unfortunately it's got a ridiculously long URL, it's a Medium URL, so I couldn't be bother to shorten it. I don't care that much about this show, I'm not that professional. So just check out the show notes by going to You should find them on the home page or you can easily look in the podcast section. And you'll find a link to that article. It's really worth reading. Really great advice about how to create a better workflow and I recommend checking out.

So hopefully you've found this week's show useful. I'd encourage you to take some next steps with this, to actually take some time to step back from the way that you work, the way that you operate, and ask yourself, are you working in the most efficient way possible. Are there improvements you can make? How can you make, for example, we didn't even touch on this, how can you make usability testing more integrated every step of the way as you work? And maybe what we were saying about stakeholders as well, of how can you introduce them to the process and involve them and educate them through it. So lots to think about it.

Go on, Jason, yeah?

Jason: I wanted to add to that because one of the things that we found very helpful when introducing style tiles is that we created a document about what style tiles are and how to work with them. And we would give that to the client before we presented the style tiles. So like a day or two ahead of time we would give them this thing to read that sort of gave them an idea of what to expect. And that really helped bring them along.

And I think that just this notion of from the very first meeting setting up expectations really goes a long way to keeping people in the loop. And you really want this sort of success by a thousand yeses. You just want to keep building that trust. So that way if you have a misstep along the way you've had all of these successful interactions to fall back on to know that you're not really that far off, you just have to go back one or two steps and to where it was really working and then kind of find out where things kind of diverged a bit.

Leigh: And again, that explanation of what is a style tile, mood board, etc. That's the kind of thing that I try and put into a video so they have to go through that preamble before they get to seeing the thing, and they don't have to read anything. So again a video might-

Jason: That's a really great idea, I like that.

Leigh: … get that kind of thing across.

Paul: Because what you can do is you can do things like, well, on the video, before you show the design you first of all reiterate the journey that you've been on. These were the success criteria that we agreed, this was the style tile we agreed on, this was the wireframing and the visual hierarchy and the user audience, and see how these things all build one on another, to, ta-da, this design that reflects everything that we've been talking about so far.

And of course the great is that educates people. But at the same time as well as educating them it's also saying, "Look, this is just the next natural step." That yes by a thousand … oh, sorry, proven by a thousand yeses, is absolutely spot on.

Anyway we're starting a whole conversation again. Jason, that's fault.

Jason: Sorry.

Paul: As punishment for kicking off the conversation again you've got to be Marcus and tell a joke. Do you have a joke?

Jason: I do!

Paul: Oh!

Jason: This is the best part of the show, and that and sort of diverting you into talking about Web fonts at the beginning.

Paul: Yeah, that was good.

Jason: I feel like I'm succeeded on all marks today.

Paul: Very good, well done. Distraction and jokes.

Jason: Okay.

Why did Spanish explorer Ponce de Leon never find the Font of Youth when he was exploring America for the first time in 1513?

Paul: See, immediately, this is a lot more intellectual than any joke we would ever get from Marcus.

Leigh: It's got dates in it and everything.

Paul: Go on, why was that?

Jason: Because Comic Sans wasn't designed until 1995.

Paul: I don't get it.

Jason: The font of youth.

Paul: Font of youth!

Leigh: Yeah.

Paul: Oh, I see!

Jason: At least Leigh got it. I had a little bit of satisfaction there.

Leigh: Well I was gonna tell you a joke about Sean Connery's brother's newborn daughter.

Paul: Oh go on then.

Leigh: But it's a little niche.

Paul: Oh, no.

Leigh: You probably had to have a Scottish accent. Sean Connery and [crosstalk 00:58:01]

Paul: You should have done the whole thing in a Scottish accent.

Leigh: I didn't have time to practice that.

Paul: No, you were caught off-guard.

Leigh: That was stolen from Bruce Lawson by the way.

Paul: I never thought I would say this but I think it's a good job Marcus is back next week.

It's been a pleasure to have you both on the show. It's good to have actual real designers and people that know what they're talking about rather than Marcus, who I still don't know what he does.

Leigh: Oh he says he's a designer now.

Paul: Oh does he? Oh will someone please knock that out of him. That isn't allowed.

So if you fancy joining in and continuing the conversation about what we've talked about today and indeed a whole lot more then join our Slack channel. I'm really enjoying our Slack channel. It keeps me entertained. You can go to and you too can waste the majority of your working day.

Next week we've got Ed, that we were talking about, the designer that can't leave Photoshop. That's such a horrible way to describe him. And Dan, both of which from Headscape are joining us next week and we're gonna get into responsive design. And it's kind of gone off the boilers, the cool the trendy topic to talk about, but there's a still a lot we can learn about responsive design. Just because you can make a site that rescales doesn't necessarily mean it's responsive. But we'll get into that next week.

But for now, thank you, Jason, thank you, Leigh, and thank you for listening. Bye-bye.