The Northern Invasion

This week on the Boagworld Show we talk applying UX principles to team collaboration, editorial calendars and northern cuisine.

Skip to the discussion or this week’s links.

This weeks show is sponsored by Proposify and Teacup Analytics.

Paul: Hello and welcome to the Boagworld show. The podcast about all aspects of digital design, development and strategy. My name is Paul Boag and joining me on this week’s show is Shahina Patel, Marcus Lillington, Ryan Taylor and Andy Clarke. Hello all.

Andy: Hello Paul

Marcus: Morning Paul

Shahina: Hiya

Paul: So Shahina you are our Sam Barnes for the day.

Shahina: Yes, I am.

Paul: I don’t know, that could have possibly been the rudest thing I have ever said to anyone. I apologise for that!

Shahina: That’s fine, we’ll see how this goes and I will decide how much offence to take by the end.

Ryan: Oh, don’t do that!

Paul: No, always take offence at the beginning. That’s how we operate.

Ryan: Absolutely, things only get worse.

Marcus: Sam is known as the sensible one so I’m not quite sure whether you’re going to be sensible. You sound like you are a bit sensible. Especially compared to Paul and Andy.

Shahina: I think most people who know me will tell you that I am really rather sensible, yeah.

Paul: Ah, no.

Marcus: Keep us in order.

Paul: That sounds… If someone said that to me it would feel like the biggest insult ever, being described as the sensible one.

Shahina: Yeah.

Paul: But I suppose if you are the sensible one that sounds like a compliment.

Marcus: Exactly.

Andy: Do I detect a bit of a northern twang there chuck?

Shahina: Me?

Marcus: Chuck?

Andy: Yes.

Shahina: Yeah, I mean what do you mean by Northern? Where are you from?

Andy: Well I’m from Lancashire.

Shahina: Aha, oh, okay right, so proper North then. Yes.

Andy: Oh yes, we’re not talking about Milton Keynes. That’s not North!

Shahina: No, well some people think anything north of Birmingham is North when obviously we know that it’s not.

Andy: No

Shahina: No, that is South. I’m from… Well currently I am hailing from Manchester but before that I was in Lancaster so just up the road. What about you?

Andy: I was born in Morecambe.

Shahina: Oh were you, ah. Sorry about that. Did you grow up… (Laughter)

Ryan: Brilliant!

Andy: Paul and Marcus have never heard of Morecambe.

Marcus: Yeah, Eric!

Andy: You’ve heard of Eric Morecambe…

Ryan: … Morecambe.

Shahina: I believe it was named after him was it not?

Andy: No, he was… Actually he named himself after Morecambe. His real name was Eric Bartholomew.

Shahina: Oh, okay.

Paul: Was it really?

Andy: It was, yeah.

Paul: I don’t know whether to believe you any more.

Andy: That was actually.

Shahina: Take it as read. Just take that fact straight down to the pub. You don’t need to check it and just tell as many people as possible.

Paul: Yeah, I like it. See, you’re not the sensible one.

Andy: So you moved south to Manchester.

Shahina: That’s right, yeah. And it’s all right you know?!

Andy: It’s not bad.

Shahina: No, they’ve got chippies with curry and gravy so you know…

Ryan: That’s the important thing, you lose that the further south you go.

Shahina: Exactly, yeah. And then I mean, it’s obviously not as good as the chippies in Lancaster because that has the best one. But, you know, they’re not far behind I will admit.

Marcus: Do you understand anything that is being said Paul?

Paul: I have no idea what is going on.

Andy: Here’s the thing, right. Shahina, what do you call a bread thing…

Shahina: It’s a barm. I know what you’re going to ask. It’s barm.

Paul: It’s what!?

Andy: It’s a barm.

Shahina: Let’s not get into this, it’s definitely a barm.

Paul: What a barm?

Shahina: You want to take this?

Marcus: How do you spell barm?

Shahina: B-a-r-m.

Andy: B-a-r-m.

Paul: Barn. A barn like you keep cows in.

Andy: No, it’s got an M on the end. Barm.

Paul: Right, so is this like…

Marcus: For Shahina’s sake seeing as she is new, hello Shahina we haven’t met…

Shahina: Hi.

Marcus: …Tell us about barms.

Shahina: So a barm is the thing that you put your chips in. So like when you have a…

Paul: What, like a wrapper?

Shahina: …Chip barm. No, no, no, no. Because you eat the barm.

Paul: A plastic container. No, no. You eat the balm.

Shahina: That’s right, yeah, it’s a bread product.

Paul: Oh, okay. A roll.

Shahina: Err, no. Well, no. You might know it as one of those but that’s slightly incorrect because it is a barm.

Paul: So it is a roll.

Shahina: It’s… It can be a roll if you want it to be a roll. If you want it…

Paul: Is it in any way different from a roll?

Shahina: Erm, yeah, I would say it is superior just from having the correct name.

Paul: Ahv, okay. But it is a roll.

Marcus: I’ve been around for so many years and I have never heard that before.

Shahina: Honestly, have you guys not come north of, I don’t know, Coventry?.

Marcus: I used to do work for Lancaster Uni but I don’t remember anybody saying that to me.

Paul: Yeah but let’s face it Marcus if we have to go North. We get in and out as quick as possible don’t we. I mean, you don’t hang around. You certainly don’t talk to northerners.

Marcus: I try not to.

Ryan: When I first met my wife she said to me, first year we were together, she said “Shall we go up ’t feast?” And I went, “What’s the feast?”

Paul: It’s t’ I’ve got a problem with. What’s t’.

Ryan: T’ feast. Did anyone know what she meant by when she said “shall we go up t’ feast?”

Paul: No.

Ryan: Up t’ fair.

Paul: Fair?!

Andy: What?

Shahina: Oh.

Marcus: What, as in funfair?

Ryan: And people who work at the fair of Feasties.

Shahina: oh, hey. By fair you don’t happen to mean Morecambe’s now shut down pleasure land do you? No, it was Blackpool’s pleasure land. What was it called, Frontierland? Do you remember that?

Andy: Frontier land? Oh, I loved that when I was a kid. I loved it. In fact I really wanted to buy one of the big fibreglass Cowboys but can’t buy them.

Paul: I feel like I’ve lost control of this podcast.

Marcus: I was about to say Paul, can you please bring this back online?

Paul: I just, I’ve had… I am so sleep deprived and so tired that none of this is making sense to me at the moment. I feel like I’m in some kind of alternate reality.

Shahina: And it’s not just the accents you mean, it’s the content as well.

Paul: Just… Well, I mean the accents are obviously a huge problem. None of you lot are as bad as… We hired, at Headscape, we hired a developer Chris Henderson and I swear…

Marcus: He’s outside now.

Paul: I swear to you when he first joined the company I didn’t understand a word he said. It was so embarrassing. I’d have to ask him about five times. Where is he from?

Marcus: He’s from Sunderland, no, yes, Sunderland way, up north, north-east. He’s probably rolling his eyes as I speak now. But a couple of weeks ago we went to Washington. Chris was the developer on the project.

Paul: Oh, that must have been funny.

Marcus: The Americans did keep looking at him strangely, and like “What did he say?” But then they talk funny as well so you know.

Shahina: They do,

Andy: Well Paul and Marcus are outnumbered this week.

Ryan: The first time ever I think.

Andy: Being soft shandy drinking southerners.

Marcus: Damn proud.

Andy: So we should basically keep using the northern colloquiulisums and they won’t know what on earth were talking about.

Paul: I had to go north. Does Bradford count as North? Is that North?

Ryan: I was born in Bradford.

Andy: Yes.

Shahina: Yeah.

Paul: I had to… I got this panicked text from my wife. She went to visit friends. This was on Friday. Saying she had dislocated her ankle.

Marcus: Ooo, ow.

Paul: I know.

Marcus: That’s proper ow.

Paul: So I had to drive or get myself to Bradford because of course she couldn’t drive home then. So I had to go north then and it was full of northern people talking. And it was really stereotypical, the further north the train went, right, I started in Bristol. By about Manchester it started filling up with progressively more drunk people. I am telling you, it is true.

Marcus: Maybe it was just later in the day? Paul.

Paul: Yes, I think that was probably it to be fair. But that’s not the point! So yeah…

Andy: Did you drive?

Paul: I couldn’t drive because she had the car. So, I had to actually sit next to northerners. It was quite distressing.

Marcus: Is she all right?

Andy: But you drove back?

Paul: Yeah. I drove back.

Andy: So you drove back in your Paul diesel car.

Paul: Yes I did. Ah, oh, you git. (Laughter) I walked right into that.

Andy: You did.

Paul: So Shahina, they’ve all decided that I look like Vin Diesel. Which I take as a huge compliment.

Ryan: No, that isn’t quite correct. You look like a…

Paul: No no no no no no no no. No, let’s just stop at that point.

Marcus: Was it the shrivelled thin Vin Diesel?

Ryan: Yeah.

Paul: I think.

Ryan: Like a shrunken Vin Diesel, that was it. Yeah, like a Vin Diesel that has been popped. (laughter)

Paul: So, yes. She dislocated her ankle and then popped it back in. Because she didn’t want to wait around for the hospital. That’s how hard core my wife is. You don’t mess with her. That’s the third time she’s done that. Not her ankle, previously it was her knee. Every time she just puts it back in herself, it sickens me.

Marcus: Yes, that would make me feel a bit, Oo, ee, or.{Transcriber note; Yes, this is making me feel sick!} I’ve seen somebody do it with their shoulder and it’s like, “Ah, no” Bleer.

Paul: Nasty, nasty, nasty.

Marcus: Touch lots of sort of fake wood that it’s not going to happen to me.

Paul: So, yes. Well, you must be at the age Marcus where it could be a hip.

Marcus: Oh, yeah, I ought to book myself in. I can’t decide whether to go for the left of the right one first. I keep forgetting Andy’s a year older than me. (Laughter)

Andy: Shh. Don’t tell Shahina that she might think that I’m young and trendy.

Paul: No, no she won’t.

Marcus: You are neither of those things Andy.

Paul: Right, okay I think we ought to actually push on with the show because this has been an intro recorded in 23 parts. As we have had such problems getting the recording working. So let’s move on and get actually do something useful. Let’s talk about Teacup analytics which is our sponsor who supported the whole season so you’ve got to give them a big loving hug.

Andy: It’s amazing.

Paul: Yeah, it’s really nice of them. So Teacup analytics is essentially reporting that is built on top of Google analytics. So it takes all the complexity of Google analytics and makes it easy to understand in a series of useful reports. It is easy to underestimate analytics and the importance of analytics because let’s be honest, as somebody who runs an agency or is a freelancer, Google analytics used right and Google analytics reporting can lead to re-occurring revenue for you. When you get good analytics reports it highlights opportunities to help you grow your client’s businesses whether through search engine optimisation or performance or mobile first design or simply making small changes to navigation or whatever. The data that you can get out of these reports highlight where things need to be improved and where effort is best focused and that of course leads to repeat business. Also those data backed decisions turn out to be more effective for clients so they see the value of the work that you are doing because as you do it you can see the results of it. Teacup analytics provides that kind of data. All of this will eventually lead to more billable hours and and happier client because they can see measurable results and a return for the investment that they have put into it. So everybody wins really. So you can find out more about Teacup analytics by going to forward slush!, slushy. I could eat a slushy, drink slushy. Do you eat or drink a slushy?

Marcus: I think you drink them Paul.

Shahina: You commit yourself to it.

Paul: You commit yourself to it!

Shahina: … I must admit.

Paul: Okay. So, Boagworld, sorry,, There you go.

Round Table Discussion

Paul: Let’s get onto some talking points for this week. Marcus you missed out last week so I thought you could go first. What have you got for us?

Marcus: Okay, I have got, this is a… A message came in from Greg Robertson and his message was this, sorry, getting distracted by people outside in the office. “Love the show…” which is a nice way to start “…been listening for years.”

Paul: I’m sorry Greg. That’s very unfortunate.

Marcus: For years. Years and years. It’s not quite as bad as having to do it for years but there you go. “I often listen while working, you guys are entertaining and informative. I get a lot of tips and news on latest design/developer tools from you all.”

Paul: Do you think he’s getting confused with another podcast?

Marcus: He might be, I’m not sure.

Andy: I think so.

Paul: Yeah, pretty sure! Anyway.

Marcus: Moving on. “I know you’ve done it in the past, or I think you have, but could you do a show on hiring employees for small businesses” well I’m not going to do a whole show but I might do five minutes.

Paul: (laughter) That’s our level of commitment!

Marcus: Yeah, we are committed here. “I have been a graphic designer for 32 years…” long time, “…and I have been designing websites for about 20. However I have pretty much been doing it on my own. I desperately need to hire someone to help, at least with the small tedious things but I can’t seem to bring myself to do it. I must be scared or just cheap, ha ha. Maybe it’s a fear of not having enough business even though I’ve been overloaded with clients for years, working crazy hours just to keep up. I could really use some help or maybe just some advice from someone who at some point has gone through what I am going through.” Okay, I wrote a few points on that last week and I just have to kind of remind myself of what they were! The first one was the comment about taking on someone to do the small tedious things. And I think that depends on what you mean. If you mean a junior to yourself then I suspect you will get what you pay for. If you want someone to do small tedious things, i.e. someone who is prepared to do small tedious things probably won’t add much to your company. However, if you mean someone to kind of help with admin-y tasks then I guess fair enough. You need to find someone who fits with your ethos. I.e. not necessarily someone who is like you but just someone who you can kind of trust and trust to get on with the job. You know, if it’s your first hire. I would suggest hiring somebody who has multiple skills rather than a specialist basically because there’s only a small number of you so if you can cover more bases then all the better I would argue. But you need to look for someone with complementary skills to yours. Chris Paul and myself were very good examples of that way back in the beginning of Headscape. Although we soon found out that we didn’t have any development skills because Paul was building CMS sites.

Paul: And I did that very well! For the time.

Marcus: You did, for the time, yes. You did. But it wasn’t your, you know, your top skill. We realised that we needed to get some help there. So yes, finding somebody complementary to yourself. But I think the big point that you want to know here, or the point that needs to be discussed is when to hire. I think the first thing you need to ask yourself is why you want the help. This might be a number of different things but it may be that…so you can take on more or more complex work. I think what you’re saying is that you need to reduce your burden. But it also might be that you just want, you’re bored of working on your own and you would like to work with some other people. When we were really small we would basically take on somebody new if we had won a big project. Which is probably… It seems a crazy thing to say even now but every time we’ve decided to do a strategic hire, “Right, we’re going to go into this field and were going to hire somebody so that we have this extra skill set and then we can, you know, grow and become great because of that.” It has never worked. It has only ever worked when we have thought, you know what, we’ve got too much work and we need to hire somebody else, you know, another designer, developer or whatever." That has always worked. So even though it sounds a bit disorganised actually it has been a good thing for us. We have always offered permanent positions. We kind of feel more comfortable doing that but offering a temporary position might give you a chance to see if this hiring people thing is going to work. But again you might not really get the person that you want if you do that. But a final point, and this is kind of a personal thing for me, which is may be potentially a bit left field but if you’re scared of taking someone on I just want to make the point that I’ve always loved the responsibility of having employees. You know, we, design agencies in general, Headscape would be a good example, we don’t really bring anything to the world that is, you know, it wouldn’t matter if we weren’t here is I suppose what I’m trying to say. So the fact that we are employing people and giving them a living feels… Is a really good feeling. So if you are worrying about maybe taking somebody on, actually it can be a good thing.

Paul: I like that. I like that, do you know I had never thought of it like that.

Andy: You have thought of it like that.

Paul: Have I?

Andy: Yes you have, because when I was agonising about four years ago about whether to take on our first employee one of the pieces of advice that you gave me was… “And it was really great that you would be giving somebody a living”

Paul: Ozh!

Marcus: It is so important in our industry I think because we don’t really do anything that is that important. We don’t save people’s lives or provide food or whatever. I’m not saying we are useless but, we provide a service, but the being able to give people employment I think, is great.

Paul: I also like that from a reassuring point of view. I certainly might have said this to you Andy, which is subtly different, which is the fact that a lot of people worry about “oh, if I take on somebody then I’ve got this responsibility for them and I have to… What if I have to fire them?” But I have the attitude “Yeah, but for however long you actually gave them a job.” Do you see what I mean? You can look at it in the negative “Oh I might have to take someone’s job away.” Or you could look at it in the positive in which case “I gave them a job for a long length of time.”

Andy: Hmmm, absolutely yeah.

Paul: That’s a good one.

Andy: It’s a great one.

Paul: Ryan, halfway through that you were going hmmm.

Ryan: I can’t remember exactly what Marcus, I didn’t think you were going to pull me in for this!

Paul: Sorry I’ve thrown you now.

Ryan: Marcus said something about…

Paul: You weren’t listening were you?

Ryan: … I was, I was. Marcus said something about not strategically hiring and hiring just when you actually need the resource. I would completely agree with that. You need, me personally and this is our experience as well, you need to have the work there to give the people to do but you’ve got to think that if you bring somebody in for a project that you got to work on you’ve increased your resource output. Depending on how you structure your business, we always keep Fridays free for internal and admin and writing blog posts and various bits and pieces so we kind of book out four days a week and then have Fridays for doing internal stuff. If you hire another employee to work on a project that you have just won you have got another employee that you have in essence got for an entire week every month to work on other things, for internal things and things like that. So you increase your internal productivity as well but you’ve got to have the work there to be able to maintain them. Work can be very fleeting, you can have so much stuff that you are like “How are we going to get all of this stuff done?” And no matter how much strategy you put in to it it doesn’t necessarily mean you’re going to find the work. So if you hire somebody without the work for them to do and then you spend three months trying to find work for them to do, then you’ve got to let go of them that is a horrible position to be in. So I was just agreeing with Marcus when I was “Hmmm hmmm humming”

Paul: Ahh, I see.

Ryan: Yes.

Paul: It was hum hum humming. I thought it was disagreeing. But you are actually agreeing.

Ryan: No, no I was agreeing.

Paul: Shahina how big is the agency that you work for?

Shahina: Well Sigma in the UK is about, I think we are about 50. We’ve got two offices in Cambridge and one up here in Macclesfield but as part of a group we are actually very small relative to the size of the larger Sigma group. It’s a Swedish company and I think that’s got around, it’s either got 2000 in the whole thing or 2000 in the division that we are in.

Paul: Wow.

Shahina: Yeah, yeah. It’s big in Sweden. I had a question about the thing that you were just talking about. Because bringing people in to plug gaps in a resourcing project, you know, if you haven’t got a very long pipeline you’ve got this short-term need and you bring someone in, what’s the… How do you judge when the best time is because in that sort of situation, and quite often we are some what at the whim of our clients really because the decision is with them to give us the work. So how do you balance bringing someone in and just hoping that they are there for the right time that the work comes in?

Marcus: Yes, that’s the biggest question, well, one of the biggest questions for running an agency is the cliff is always three or four months away. And you just have to, I going to say something crap again, but it’s a little bit of a gut feeling as to whether you think that your pipeline is going to come in or not. If your pipeline is really big and you’ve got tons of things on, at that point in the past anyway we have thought now is the time to say “Come on, we need some more help now.” Headscape we have actually, Chris and I have made a decision a year or so ago that we don’t want to expand. And we will actually turn work away rather than expand now. Although it seems… That’s what I’m saying but actually in essence if anything comes in we go “Oh yeah, we’ll fit it in!” But we have no intention of getting any bigger. We like the size we are. But in the past it was just a kind of, it wasn’t totally a gut feel but there is that gut feel based on do you think these things are going to happen or not? Because you can’t push clients into “Are you going to sign up in two months time?” Or whatever. Or you don’t know what’s just around the corner half the time as well. So you have to take a little bit of a punt on what the pipeline is going to be. But otherwise it’s like are we coping? And if you’re not, and if you’re happy with where the pipeline is but you’re not coping then it’s like well that must add up to more people are required.

Paul: It’s interesting isn’t it. The more I hear questions like that the more I realise how much you just make up as you go along.

Marcus: Oh yeah.

Paul: You know, a question like that which is a great question, it’s a very insightful very good question. But the truth is there often aren’t answers to things like that, is there. It’s like, yeah okay, you kind of just do what feels right at the time. It’s a weird one.

Marcus: And the older I get the less I am bothered about it. It is fine.

Paul: Yeah.

Marcus: You know, we’ve done all right over the years. I mean if you had asked me that question seven or eight years ago I would probably have come up with some bullshit about figures and analysis and all that kind of thing but no, actually… Yeah, you can’t just randomly hire people, you do have to think about it but really what it comes down to is is the revenue going to keep coming in? And nobody knows, who runs an agency. Is the honest answer to that, it might all dry up tomorrow. It probably won’t but… Yeah, it’s an educated guess.

Shahina: I think you are right though Paul I think a lot of this is taking a punt on a best guess.

Paul: Yeah, funny isn’t it. So Shahina what have you… You sent me through a couple of options of things that you wanted to talk about. Both of which I thought were really good. Which one did you go for or did you go for something completely different?

Shahina: I went for one of the ones that I sent to you. So the thing I want to talk about is taking the processes that we use to build products or websites or apps or whatever and actually applying those to the team itself.

Paul: Ahh, I’m glad you went for that one because this made me very curious. So what did you have in your head there, what were you thinking?

Shahina: So I was thinking you know how we invest so much time and so much of our effort into the products and the services that we make. I think we should also consider spending a bit of that time and that effort in taking ways of thinking from design practice, that we are doing anyway, but applying those to crafting great teams… I was going to say you want to hear some of the things that…

Paul: Yeah, yeah, yeah, yeah. Sorry, I keep interrupting you.

Shahina: That’s okay. So the first technique that I want to ask people to consider trying is to apply the syntax of the user story for communication between team members. Are you all familiar with user stories?

Paul: Yes.

Marcus: Yep.

Shahina: So a user story is, I think, a great way to communicate requirements because it adds a narrative that helps everybody understand the essence of what you are trying to do. And the essence is the really important thing. So there are a few different formats for writing the user story or for articulating a user story but I think that the ones that were developed by either Mike Cohn or maybe Rachel Davies I think sit best to the thing I am trying to say. So those user stories go something like this. They say “As an active role or persona I want to complete a goal so that I achieve this value.” And I’m sort of making my hands into square brackets as I reading tht out loud! (Laughter) …doesn’t work so well.

Paul: Doesn’t work well on a podcasts!

Shahina: So often in a team when you are working on a project you often say or you hear from someone else “I need this” or maybe slightly better you might hear “I need this by then.” But I feel with that kind of phrasing there often isn’t any context for any kind of urgency. Quite critically, as well, there is no shared understanding of the completeness of the task. By that I mean how do you both know when you have done it. So what I would do is I would suggest an edit to the user story syntax that I described earlier and the one that I would suggest is something like “Because I am looking for a, square bracket, particular desired outcome, square bracket, I require, square bracket, some kind of specific input or information, close square bracket, by, square bracket, a particular time or activity.” So that is, “Because I am looking for a particular desired outcome I require some kind of specific input by a particular time or activity.” I think by adapting and applying that kind of syntax to the information that you are passing between two people or even within the team it gives the context for why the person who is receiving that test needs to do something to help you. I feel it’s leaves you a bit less ambiguity for when you’d both consider that it’s done. The done bit, that goal bit of the user story is very, very important because that is when you decide that that is finished and the need is met. So, did you follow all of that?

Paul: Yes.

Shahina: What did you think about that. Because I have a few other ideas that it would be good to know what you think about it. Because I feel that communication often has a very high failure rate within teams. You know, we focus a lot, especially as project managers, you know, we always talk about getting communication right with clients et cetera but typically I, you know, my experiences, there is a high failure rate within organisations themselves. I think we all suffer from that because we are all trying to do our best outside but internally we are maybe not applying that same sort of approach. This is why I find this very interesting, we all have these techniques in our back pockets, you know, user stories, prototyping and feedback even. I think facing them inwards a little bit and spending a bit of time with our teams can help us, if you consider the team as the product, to make that better as well.

Paul: I totally agree. It is something I have talked quite a lot about, not so much with internal teams like that but with clients applying all those that we know as… All the effort that we put into understanding users we don’t put into understanding clients or colleagues. And actually it’s incredibly powerful and in the set of user experience culture cards that I have been working on recently one of the cards that I have got in their is “Take the time to create empathy maps for your colleagues.” So understanding what their pain points are, what influences them, you know, what their goals are. All of those kinds of things, what tasks they want to complete, what questions they have got because it enables you to not only work with them better but also to help them understand what you need to communicate to them. So if you think about when we do user experience design work ultimately we are trying to convince somebody of something. We are trying to convince them to complete a call to action or to purchase a product or to do whatever. But there is an element of convincing people. One of the biggest challenges that we face internally or with clients is convincing people of stuff. To do that you need to understand them so using those user experience tools that we use to understand users makes so much sense to do it with colleagues as well. I think it is brilliant. So you mentioned that you had some other things in your back pocket are there other examples of this?

Shahina: Yes actually. So I will tell you what I think about prototypes.

Paul: Yes, because I’m struggling to imagine how that one kind of fits in.

Shahina: So in my mind a prototype is to test a hypothesis. The other thing about prototypes is that they should be quick to build and quick to test as well. So in terms of teams I always consider how easy it could be to prototype a new way of working for example if, you know, your old way of working isn’t doing the job if it is failing in any way just try something different. Simply that is just the build, test, learn cycle. I think the way that it can apply to teams is firstly, when you have identified that some aspect of your teamwork could be better, so maybe the communication or feedback loops or scheduling or if there’s anything like that if you uncover a solution that all the team members have contributed to. So if you were building a prototype for example that would be “Can this be built? Does it fulfil the users needs, can we design it according to brand guidelines?” That kind of thing would always pass through all of the team members anyway for a sign off, I think. It is the same with whatever your solution is to your problem that you have identified with your team. So everybody contributes to the solution. That is the first thing. And then the second set is that you decide what that solution looks like to a degree of refinement or fidelity that is just good enough because the key there is to identify what is the problem, how do you fix it, let’s just try that. Rather than spending a very long time trying to refine a solution whilst you’ve still got that problem. And yeah, quickly and easily integrate whatever your new way of working is into your practice to determine if it is actually better. And then if it actually is you can add all of the bells and whistles that you need to. I have tried this in a previous agency, we spent a very long time determining that something needed to be fixed and we bought some software and then spent six months customising it by which time the problem had sort of gone away or it has evolved. That’s where I think prototyping is, when applied to a team, it’s can just be a mindset. Which is, “Can we do this? Yes we can, let’s make the change now, let’s see what happens.” You know, it should be very quick and getting that feedback quickly, I think is key. Because you shouldn’t be stuck with a crappy way of working if you can help it.

Paul: Yeah, that I think is a fair comment. Yes, you don’t want to be stuck with a crappy way of working. No, yes, I think you are right actually and that freedom to try new things and to constantly push to innovate in the way that you work. There is a book that I recommended a couple of weeks ago on the show called Creativity Inc which is written by one of the founders of Pixar and is about the different processes and how they work and they operate and that covers a lot of this kind of stuff as well. It’s really important. We don’t spend enough time on it.

Ryan: Do you think it becomes more of a challenge as the company gets bigger? You know, we’ve chopped and changed kind of our processes and tried different things and different approaches being a smaller agency. Do you think the bigger agencies as you get to 24 people plus it becomes more difficult to try out new processes because everybody is… Is there a scale issue or is it just a matter of just keeping your kind of group of people that you are testing things with small and then kind of filtering that out to the rest of the company? Does that become a challenge as the company gets bigger?

Shahina: I think yeah, it can potentially be because people want predictability because that means that they can feel safe and comfortable in what they are doing because things are predictable. I think especially as a project manager it is your job to create that predictable and comfortable environment so people can do the things that they are really good at without worrying about all the stuff they don’t need to. In terms of that scaling I think what can help is just reframing things. Not as “This needs to fit this process” but instead thinking of things as “Eventually we need this outcome.” How you get to that outcome can be flexible. That gives, I think, more of an opportunity to be flexible with your process because if you’ve all agreed what your outcome is going to be it doesn’t necessarily matter how you get there because you have got there within whatever parameters you have set which might be time, budget, you know, even down to using, agreeing what tools you use. If you know where you are getting to it shouldn’t necessarily matter how you get there. Everyone ought to feel comfortable but, you know, that’s where everybody contributing helps and it can help to do that on a project by project basis to get that data and to get feedback from the team before trying to roll this out. Actually I would always advise that because that’s another thing that doesn’t work is to sort of build a solution in a bit of an echo chamber where you say “I think this is right,” you know, around a boardroom table, and then applying it to everybody. It kind of hurts really. Because that doesn’t often work.

Ryan: Yeah, that’s what I was kind of thinking. You know, there might be people that don’t actually like the process and how do you make sure that everybody’s voice is heard.

Paul: Ryan. What have you bought for us today?

Ryan: I had this idea of talking about this service that I have used called APIary.

Paul: Right.

Ryan: Which is an API documenting system thing. And I thought I would talk a little bit about API’s and then I realise this could be actually such a huge talking point. So I shall try and keep it succinct. So, this kind of works on the idea of… I’m getting a bit to developer-y, but it’s documentation rather than actual coding.

Paul: So what’s… first of all what’s the… API?

Ryan: A,P,I, Arie. So, A-P-I-A-R-Y dot I-O.

Paul: Right, okay. Yes.

Ryan: Right? Now, this is a tool that allows you to basically write and document all of your API before you actually build it. So you work out all the endpoints you are going to have all the functionality, what data needs to be posted to the API and what response is going to come back. You documents all this, it is using like a, what do they call it, a description language that is kind of similar to markdown but has additional functionality. So you writing it in a kind of a markdown way but you have got additional functionality to document all of this stuff. And APIary uses one called API blueprint. There is another one out there that is very popular called Swagger. So these are two kinds of ways of documenting your API. You need to kind of decide which one you are going to use because once you have got going with it it is kind of hard to change. The nice thing about APIary is that it uses that kind of markup language, the blueprint language, and you’ve got a nice interface that then formats it into… Have you seen Stripes API documentation.

Paul: No. It’s not something I look at a lot, API documentation! I have to be honest. (Laughter)

Ryan: So one of the nicest API documentation that I have seen is really well documented and it shows really good examples of what your endpoints are what data you need to post to your endpoints and what are the results, what the responses that you get back. And APIary kind of does that for you. So you write all your… You document all your API and all your different functionality and how things relate together and all your bits and pieces and then it formats that into like a presented documentation. It looks really nice, it is really easy to work with but one of the nice things that it has got as well is that you can actually test your built API, so you do all of this before you even started building your API. And then you build your API based on what you have written in, what you have documented. So you are building to a plan. You are not just going off half cocked.

Paul: Yes.

Ryan: And what it… What you can then do is you can test your API against your documentation. So what it will do is once you have defined all your API and your documentation you can say “Right, my API is over there, run through and test and make sure you can hit all these different endpoints and make sure that these are the responses that you get back.” So you can actually test your API against what you have documented. Which is nice because if you change your API and then you break something you can either fix it or you can go back to your documentation and update your documentation to say “Right, we’ve now added this bit in” and make sure your documentation is up-to-date all the time as well.

Paul: And that is so important, the number of times that documentation don’t match what happens in reality.

Ryan: Yeah. So yeah, absolutely. It’s quite a nice tool, we used it for a system that we have been building internally and one of the nice things about taking an API kind of driven approach is that you are building your system API before you are getting into building a web interface or a mobile app or anything else. You’re just building the functionality of your system first. The advantage of that is then that you can use that API to build whatever interfaces you want. So you can build your web interface, you can build a mobile interface, you can build an interface for your TV. Whatever you want to do you have started with the core functionality before you have even got in to any markup, JavaScript or anything like that because you are just building your API which handles the processing of the data. So yeah, APIary was just a tool I wanted to bring to light today. It’s recently been brought by…

Paul: Oracle.

Ryan: … Oracle. Yes. So I don’t know where it’s going to go from here but it’s quite a nice little tool.

Paul: I like that idea of starting with the documentation. That’s an interesting way of doing it.

Ryan: Yeah, so there’s a concept in development called test driven development. The idea being that you write a test and then you code to make that test pass.

Paul: Oh, okay.

Ryan: So you write a test that fails and then you write your bit of code to make the test pass and then you re-factor your code, make it as good as it can, make sure the test still passes and then move onto the next one. The reason being is that you are building really solid code then rather than just building things half cocked that is untestable. You are building in small chunks. This is that kind of concept but this is more… It makes sure that you plan everything and you document everything and you are making sure… Because it is so important if you are building an API to have it well documented because otherwise how do you know what it does. So that is what this tool does. So I tried to keep that kind of succinct as possible but obviously there is so much you can talk about with API’s but from a conceptual point of view this is just documenting an API and then building to that documentation.

Paul: Yeah, because the whole idea of starting by building the API and then the different interfaces on top of it. That is a whole talk, book probably, in itself isn’t it?

Ryan: Absolutely, but that’s how also if you just start… If you just get into a code editor and just start coding that is how you end up with spaghetti code and tangents and all kind of stuff and it becomes this… And so many things make it to market that have been built in that way and then you are suddenly, two years have passed and version 2 is out where they have built it properly. You know, they have just started again from scratch. So I am quite keen on doing it right first time and then iterate. But this is quite a nice tool if you are building an API and you want to start off doing it properly.

Paul: Cool, you definitely you need to do us a talk for the next season, Ryan, on API’s. I would love to hear that. Even though I don’t do anything, I don’t code to this stuff, I’ve always loved the principle of API’s and the approach. So yeah, It would be good. Andy, what have you got for us?

Andy: Sorry, I was just sugru-ing my lightning cable while I was listening to that.

Paul: I don’t know what that word means.

Andy: Sugru is a…

Paul: What’s Sugru?

Andy: It’s like a little sort of putty compound that you, well it turns into rubber after about half an hour. You use it for basically fixing things. So actually I’ve been sitting there, while I was listening to Ryan’s API talk, I was just fixing a lightening cable with some Sugru.

Paul: Oh, I just looked it up on Amazon. Sugru. Oh, there you go.

Ryan: The girl that, I can’t remember her name. Do you remember who invented Sugru Andy?

Andy: No.

Ryan: She spoke at the Brighton conference, “Reasons to be creative.” She talked about the whole history of how she made Sugru. It was really interesting, really fascinating. I think everybody got their phones out and ordered some as soon as she had finished talking. Everyone went “That is cool!”

Andy: That was mailed all the way down here to Australia. Anyway, my segment, my segment. Do you remember a few weeks ago I talked about the Canadian broadcasting Corporation graphic standards manual (snoring) and Paul loved it so much that I am sure he ordered quite a few on kick starter. Anyway, it turns out that they didn’t actually hit their funding goal.

Paul: Oh, what a shocker! (Laughter)

Andy: But what they have done is they have found out that they can actually get better print, they found out cheaper costs et cetera, et cetera so they have now basically lowered the pledge. There is a mailing list to sign up for to find out about the new kick starter when it comes out. So please do that because I want to add that to my collection. There will be a link in the show notes. (CBC Graphic Standards Link) Right, onto my actual topic for the day. (Laughter) Which is not Sugru and the graphics standards manual from Canada. I’ve been working on a new style guide design here at Ansarada and I have put together a few sketches, very lo-fi in terms of what I wanted to do with this layout. I started to put it together in code earlier on today and I thought “Why am I even bothering thinking about floats or any other type of layout, I should go straight for CSS grid.” Which of course is what I did. I went from a quick sketch on a piece of A4 paper to a responsive flexible grid layout in about 45 seconds. It was amazing. Now, this is not the most complicated grid layout that I am sure anyone’s made but I tell you what, it was just brilliant. That’s it, I am sold. There have been quite a lot of people talking about grid this past week because of basically browsers catching up and I think it’s only now Edge which still just has a preview implementation of CSS grid. But it’s brilliant, what you really, really need to do is to go and learn about CSS grid. I’m not mucking about, you need to do it now. This needs to be your week… this needs to be your CSS grid week because if you are not up with the cool kids on CSS grid then you are just an old has-been like Paul. You need to learn it. Where are you going to learn it from? You are going to learn it from two great sources, I think. The first is which is a website which has been set up by Rachel Andrew and she has not only been working on the W3C to get CSS grid implemented properly but she has also been making some really, really great learning materials. Including a bunch of videos. Just before Christmas, every day for about 12 days she posted a new video about CSS grid. You can see that on, which is excellent. There is also a gallery of common layout patterns which I wish I had found before I started coding my own up today because I might have actually trimmed it down to like 25 seconds if I have just cut and pasted her code. Anyway, the other person that has been really working on presenting CSS grid stuff is Jen Simmons. She’s got some really interesting examples if you go to and something which I thought was a hell of a lot of fun was… There’s a guy called Thomas Park who is Thomas H. Park on Twitter, he’s from Philadelphia. He has put together

Paul: I’m sitting here playing with that now actually!

Andy: … A game that teaches you about CSS grid while you write your CSS code and you grow your carrot garden. It’s just 28 levels of fun CSS code that will teach you all about grid. So this has got to be your week for grid. And yeah, have at it.

Paul: I’m… This is, the great garden is strangely addictive. I can’t stop playing it.

Shahina: Yeah, me neither. This is pretty great. This is my week to grid then.

Andy: This is your week for a grid check.

Shahina: Okay. That’s fine, I’ll just send that email to my boss, okay. Done.

Paul: Yes, that’s all you had to do this week.

Shahina: Everything is rearranged, okay.

Paul: Okay, that’s good to know! The logical question is can I actually start using this yet Andy? Is this, or is this all latest browsers stuff.

Andy: Well it is all latest browsers stuff if all you care about is latest browser’s. Edge is the only issue really and I suppose IE11 is still kind of knocking around for some people. Of course, you can combine it with things like @supports so that you can write some sort of nice quarantine fullbacks. So, you know, fallback to something logical. But no I think you can… At this stage in the game I think you could be fairly aggressive and if you just drop back to 1 or 2 columns for crappy old browsers then that’s going to be all right. You know, the gains that you will make from… You will actually end up using way, way, way less media queries and breakpoints and all that kind of stuff if you just use grid and flex box. It really does simplify things a lot. And you can do some really cool layouts with it.

Paul: I’m sitting here playing the grid garden thing and it’s got some interesting, I don’t know if I fully understand what I am doing. So you’ve got… It doesn’t matter, actually, trying to describe this in an audio podcast is not going to work. And also supporting my idiocy is probably not the place to do it in the show.

Ryan: Although it could be quite entertaining.

Paul: It could, it could. Because I’m sitting here going “Hang on a minute, grid column star is five and grid column end is two. How can it be less than the star and Ahh, what’s going on.” So yeah, that’s fine.

Andy: Lots of cool stuff and of course all the books that I have been talking about for this whole season have all been about inspiration for grid, so there is a bit of method in my madness.

Paul: See, you are making it sound like you planned it all and you hadn’t, don’t give us that. (Laughter) Yeah, exactly that’s what I thought. All right, well I’ve got a quickie to wrap up with which is a tool that I use regularly. One of the things that I’ve been quite shocked at as I work with a lot of my clients, and clients that are producing large amounts of content, right? Content that goes out on social media, that goes out via email, podcasts, blog posts you name it, there’s so many different types of content on so many different channels that we put out these days. Big organisations that are putting out huge amounts of content yet have no centralised method of managing this. So one of the clients that I work with has got millions of subscribers and followers on various platforms and that kind of stuff and yet social media updates, blog posts they are all just put out whenever by different people across the organisation with no kind of coordination at all. It just blows my mind. You know, I work by myself and I still have an editorial calendar which controls what goes out when so that all this kind of stuff is coordinated. The way that I do that is using a tool called Co-schedule. Co-schedule is a great tool. I used to use lots of different tools but I have kind of now bought it all down to this one tool that does all of it. Essentially it gives you a calendar, and on that calendar… you can integrate co-schedule with everything you can possibly imagine. Worldpress, Evernote, Buffer, Twitter, Facebook. Anything, you name it. And you have this one calendar to rule them all so you can basically go in and create a blog post on your WordPress blog and you drop it into a particular date. Then you can add a link in so for me I know I have a blog post every Tuesday and I can go through and I can outline what topics I want to cover on what dates each Tuesday. Then I know I’ve got a podcast that goes out every Thursday so that goes into my calendar as well. I know that I have got a newsletter that goes out every other Friday so that goes into the calendar and I can see all of this stuff laid out. Then with each one of those items, like for example when a blog post goes out I can associate social media updates for it. So I can say that immediately as soon as my blog post goes out send out an update. But then also send it out eight hours later, okay, because, for America. Also send out another post the next day and then in a week and then in a month. And it fills all of this in in the calendar. So you’ve got this nice kind of calendar of all of these different things filled in but then what you can do on top of it is you can then have lists of other social media updates. Kind of evergreen content or whatever else. You can basically say, “Fill in the gaps with this kind of stuff.” Right? So you’ve got stuff that’s fixed then you’ve got stuff that it kind of puts in automatically. And it is just such a neat way of seeing what is going out when and stopping you kind of overwhelming people with content all at once. It even does things like analyse your headlines of your blog post to make sure they are as effective as possible. So it is a really good tool that I think whether you use co-schedule or whether you use an Excel spreadsheet I think pretty much anybody that is using social media or content marketing in any kind of professional sense needs a tool like this. So yes, that’s my suggestion for the day. Okay, that left everybody speechless.

Shahina: I love this…

Paul: What was that?

Andy: I was just flicking through.

Shahina: Yes. It sounds great because I have a terrible approach to remembering to tweet and blog. Well, I don’t blog to be honest. But tweeting stuff. The time I remember is that when I’m about to go to sleep. So I would write the treat and put it in my …. And then try and remember the next day to post it, and never do. So this sounds like it might solve some of my problems.

Paul: Well actually in your situation I would recommend a slightly different tool. This would probably be a bit of a sledgehammer to crack a nut for your situation because it is just you and it is mainly just tweets. You don’t have lots of different channels. So in your case I would suggest a tool called Buffer. Have you come across Buffer?

Shahina: Do you know what? People keep saying buffer. I should look into this.

Paul: Buffer is really good because I suffer from the same problem, I do exactly the same, I sit in bed, I know you shouldn’t do but I do, I sit in bed at night and I read all these articles and stuff or I go through Twitter and I see all these cool things that I wanted to share. Of course what happens is that you end up spamming people with loads of updates, all within about half an hour of one another. So what you do instead is you add them to Buffer and it will spread them out over a period of a day so you can put them all in one go but then it kind of pushes them out over the day. So yeah, a couple of…

Ryan: So what that basically means is that if you follow Paul he is just a robot.

Paul: Yes, I am. In terms of when you receive my updates but they are all still written by me, it’s just that something… It schedules them for me so I am being considerate and not…

Ryan: It’s diesel Bot. (Laughter)

Andy: Diesel bot! (Giggle)

Shahina: So if I reply to a scheduled tweet and there’s no reply it’s actually diesel bot that is ignoring me. Not…

Paul: Yes.

Shahina: Not… Okay. Not actually…

Paul: No, I do actually have to keep an eye on it in terms of replying to people. And I’m going “What the hell are they replying to?” Because of course I can’t remember what it was that I said in the first place but there you go. Other than that it is totally spontaneous and real. But no, it is a useful tool.

Anyway, talking of useful tools let’s quickly talk about Proposify before we wrap up this week’s show. Proposify is a simpler way of delivering proposals for your clients. So it streamlines your process and helps you to close deals faster. In fact they have worked out, I don’t know how they’ve worked this out I think they just made it up! But apparently users save over two hours for each proposal compared to using Word, Indesign or Google Docs. To be honest I can believe that actually. That does sound feasible. After using Proposify for a while it is a hell of a lot simpler than writing proposals in Word or whatever. You make sure… It also helps you make sure that your sales leads never go cold because it allows you to track those leads and see how they are performing and it puts your proposals in the hands of your clients faster because it’s got this… You can produce them so much quicker with their great editor that they have got and reusable content libraries et cetera. But most of all actually, and this is really useful, people can look at those proposals anywhere, anytime so it’s not like sending a word document where they have to wait until they are at a laptop, these are all web-based proposals which means that they can go and look at them online. They can even sign them online as well, which on average means that proposals gets signed of about 60% faster than if you send them, you know, documents that go backwards and forwards and all of that kind of stuff. So it really is a very useful tool for getting proposals to clients and getting them to sign off on them. You can find out more about it at

Marcus, please tell me you are using Bruce Lawsons joke

Marcus: I have Bruce Lawson joke ready to go.

Paul: Yes, this really made me giggle.

Marcus: I smeared some ketchup all over my eyes once. It was a bad idea in hindsight.

Paul: Heinz site. See? See?

Andy: Oh, yes!

Paul: Heinz, Heinz, sight.

Marcus: Heinz sight.

Andy: I get that one!

Paul: He did another one this morning. I’m just trying to remember what it was. Err, it was something about. Oh, I’m going to completely butcher this now because I can’t remember what his joke is. I’m going to have to actually look it up. It was just as…

Marcus: Just tried to eat a clock for breakfast, it was very time consuming.

Paul: Yes, that was it. Yes. Anyway, that is it for this week. Don’t forget lightening talks for next season. I’m getting quite excited, people have started to contact me now, we are beginning to build some momentum. People that are going to do some talks for next season on the show I hope you will be one of them. We need so many of them it is unbelievable. So, get those lightning talks coming in. You can find out more about what’s involved in doing that at Please, please check that out and submit those as soon as possible. That’s it for this week’s show, join us again next week where we are going to be doing the very last show of this season. So until then goodbye.