Stop boring your social media followers

Running a social media account for a business is hard. It’s difficult to get into the habit of putting the time in and even if you are posting on a regular basis it can be tough not to just churn out a stream of boring promotional messages. Saying ‘We are the best X in the region contact us to find out more’ over and over won’t get you anywhere.

There are a few things you can do to avoid this kind of corporate banality and they range from quick and easy to time-consuming and hard. The most effective thing you could be doing, and probably the most difficult, would be creating regular high quality content on your website which will be interesting and valuable to your audience. But let’s be realistic, you probably don’t have time for that right now. Enter Buffer.

Buffer is a fantastic tool that is best known as a social media scheduler. It allows you to line up Tweets and Facebook posts (it also works with LinkedIn, Pinterest and Google+) in advance so that they’ll go out automatically over the next few hours or days. You tell it how many times a day and what time to post. After that it’s just a case of keeping your Buffer topped up. If that’s where it ended that’d be good enough but Buffer has a fantastic feature called Feeds which allows you to pull in content from almost any website of your choice and add it to your scheduled list of posts. This feature uses RSS which stands for Really Simple Syndication. The reason it’s so useful is because it allows you to log in to a single place, quickly scan articles from several sources and share them with your followers very simply. With a few clicks you can have enough content lined up for a few days meaning you get to avoid that nagging feeling that you need to ‘do something about the Twitter’. Aside from the time this will save you this has the added benefit that your company social pages will become much more diverse and interesting to potential followers. You’ll also likely get noticed and retweeted by some of the authors of the content you’re sharing which is a great bonus.

I’m gonna assume you’re sold on this plan because it’s great. So, if you don’t already have one, go and sign up for a Buffer account now. There’s a free option but you’ll need to be on the Awesome Plan to take advantage of the Feeds tool but at $10 a month (about £7) it’s well worth the money. And there’s no minimum contract. All set? Ok, let’s do this.

After logging in to Buffer you’ll want to click your profile icon on the left, then choose the Content tab and finally click RSS Feeds.

Now you have two options. First you can type a search term into the box and Buffer will display a list of suggested sites. If any of these take your fancy just click the name. If you already have a website in mind to add to your list you can copy and paste its URL in the search box. As long as the website uses RSS, which virtually all blogs and news sites do, Buffer should now display the name of the site under the search box. Click that and a few seconds later you should see a list of the latest posts from your chosen feed fill the screen.

From here you can click through to the article to give it a read, click Add to place the article in your list of upcoming posts or dismiss the article if it’s not right for your followers.

When you want to add another feed simply click the Add & Remove Feeds button and repeat the process above. To get the most out of this feature you should aim to have a few different sources in your Feeds list. Think about your audience on social media, or the kind of audience you want to build, and figure out the kind of sites that will be of interest to them. You can experiment with your chosen Feeds too as Buffer lets you know which of your shares are the most popular. Over time you’ll be able to tailor your Feeds for maximum value.

And that’s it! You now have the facility to keep your Facebook, Twitter and other social media topped up with interesting content for minimal effort on your part.


Paper Prototypes: What are they and why use them?

Website design is ever-changing and, consequently, the way that website designers work project-to-project changes as we learn better ways to do things, embrace new technologies, methodologies and processes.

We’ve been making and working on websites for many years, and have experimented with different ways to get clients to engage with the wireframing stage of the process. We have sketched out really rough wireframes with clients and used online wireframing tools such as Balsamic and InVision to present them. This way of showing wireframes to clients has been fine but we’ve felt like we’ve not quite been able to get people connecting with the functionality of the design. We felt it was important to wireframe most of the website with our client so they knew they had full input into the design but we didn’t need to do every page and certain pages such as a blog overview or contact page were so simple that they didn’t really need to spend that time with us.

Wireframes are the blueprints of the website and it’s important to make sure that the content and functionality is right before the website is built. But because we’re all visual creatures, it’s still hard to see past what font has been used, whether the navigation is on a light or dark background, should the buttons have rounded or square corners? etc. It’s easy to ask people to not worry about those things at this stage but we can’t help being drawn to the visual, even if it’s just monotone and basic. Our clients naturally want to skip ahead to the visual design stage where the colours, nice fonts, photos and illustrations live. Wireframes are not the sexy part of the web design process and grey boxes and buttons are, to be honest, a bit of a turn off.

A better way to engage with wireframes

So what can we do to get our clients more engaged with wireframes? Draw them! For our latest project, we rough sketched some of the important pages on the site with our clients to make sure we had everything we needed on the page and then rough sketched out the remaining page templates as a team to get all the elements in place. Then I drew every page template out on quadrille paper, both desktop and mobile versions. I also had separate cut outs of recurring elements, such as the header and footer so these could be placed over the page templates.

So why draw pages? There are several reasons that we decided to work this way in this project. One of the main reasons for drawing out the pages was because they are drawn by hand, there are no styles to be districted by. No fonts, no shades of grey, no corner radiuses. We and our clients could concentrate on the content and functionality of each page template.

The act of drawing out each element meant that I thought extra carefully about the elements going on a page template. It’s easy to copy and paste elements using design software but because each element was inked in, it was considered. Sometimes, we realised that we were missing something, a call to action or similar and I simply drew it and taped it into the design. The designs were modular and amended easily without having to save and update pdfs.

As well as there being no visual design distractions, presenting the wireframes actually worked really well by them being on paper. They could be picked up and examined, mobile pages could be held in our hands and scrolled by pulling the paper down, customer journeys around the website could be followed by placing the pages next to each other and checking that the journeys made sense. When our clients had suggestions, I simply drew them on, no waiting until I was back at a computer to make the changes. And because changes could be suggested and instantly implemented, our clients knew that this stage was a discussion for them to get involved with, not something finished that they had to approve.

But paper? In web design?

But the website isn’t printed, it will be used on computers and phones, shouldn’t you show them on those devices? We’re not going to go from paper prototype to finished website, there are a couple more stages between these. The paper prototype is important to check that the functionality and content of the website is right and to engage our clients but we will show the prototype on screen too. The next stage is to build a HTML prototype which will act the same as the finished website but we know that by testing out the pages on paper first that the processes have been well-developed. That’s not to say that things won’t change at the HTML prototype stage, but we are confident that we haven’t overlooked anything before proceeding. We had a fantastic meeting showing our clients the paper prototypes and getting them excited about the project. Visual design might always be the bombshell of the process but paper prototypes are, at least, charming.

This article was originally posted at


How to run more efficient meetings

I used to think that I didn’t enjoy client meetings. I always felt that they were a waste of time and that I could achieve far more by simply communicating with clients over email. I included phone calls in my definition of meetings too by the way. I felt like email was a much more effective way of communicating as they contained everything that needed to be said and could be referred back to at any point in the future. But let’s be honest, no one reads emails. And just because you have a world-class folder structure in your Gmail doesn’t mean you client does. Email is also terrible for conveying nuance and as for brain-storming ideas? Forget it. So I would begrudgingly go along to meetings but always feel they were an inefficient drain on my time. And they were, because I didn’t know how to plan or structure them properly. But over time I learned how to run more efficient meetings.

It’s no real surprise I was bad at meetings as I was never taught how to run them, but I’m ashamed to say it took rather longer than it should have to start making meetings work for me. I think this was partly because I read something antagonistic about meetings being a waste of time. Anyway, if you’re crap at running meetings like I was I hope the following advice may be of some use to you.

Before the meeting

  • Decide on the finish time of the meeting as well as the start time
  • Decide on a few clear things (ideally less than five) you want to achieve in the meeting
  • Send a clear agenda to everyone who will be in attendance at least one day before the meeting
  • Ask for additions to the agenda when you send it. Resend the agenda to everyone if there are updates
  • State who will be leading the meeting when you send the agenda

At the meeting

  • Have a timekeeper who can move things along if needed. This will often be the meeting leader but not always.
  • Only write down the most important points. Record the meeting audio rather than trying to take copious hand-written notes. As a courtesy ask if anyone minds you doing this (they won’t).
  • End the meeting by agreeing on what the next steps for the project are and who is responsible.

After the meeting

  • Write up conclusions, questions that arose and next steps and email this to everyone who attended the meeting. Offer to send the meeting audio to anyone if they want it (they won’t).

So now you’ve leaned how to run more efficient meetings you’ll be amazed by how useful they can be. Good ideas will come up, questions will be answered, problems will be avoided and you will look like you really know what you’re doing. As long as there is a clear purpose and you stay on track meetings can be very worthwhile indeed.


Moz 804 SSL Crawl Error

I’ve been tracking our company website in a Moz Pro campaign for a few months and found it quite useful. Everything was going great until I moved the site to Amazon’s CloudFront CDN. Every week Moz emails me with a list of any potential SEO issues to fix on the site and the first of these reports that came through after the move contained a big one, an 804 SSL Crawl Error to be precise.

Error Code 804: HTTPS (SSL) Error Encountered

We were unable to access your homepage, which prevented us from crawling the rest of your site. It is likely that other browsers as well as search engines may encounter this problem and abort their sessions. This could be a temporary outage, but we recommend making sure your network and server are working correctly.

This was obviously not good news. My first thought was that I must’ve made a mistake when setting things up on the CDN. But after a little digging I found the problem: Moz simply does not support SSL certificates served from a CDN such as CloudFront or CloudFlair.

This response was posted by James Kaiser, a Moz Inc employee, on a Moz forum:

Hey there – sorry if there was a miscommunication but we do in fact support SSL, however at this time we do not support SNI (Server Name Identification) which is a technology used to host multiple SSL certificates from a single IP address. If you are currently leveraging CloudFlare or CloudFront we will not be able to crawl your site. If you are using a standard SSL from it’s own IP we can most likely crawl that page.

This is a major disappointment to me as I was enjoying using Moz Pro and am now weighing up whether to keep shelling out the monthly subscription. Moz has said they are working on a fix but that ‘an ETA is not available quite yet’. That was back in July and as far as I’m aware there have been no other announcements.

So if you are facing the same issue what can you do? It seems to me that there are few options:

  1. Live with the fact that you will no longer get SEO errors reported despite paying for this feature.
  2. Ditch the SSL certificate on your site (Bad option in my opinion)
  3. Ditch the CDN (Very bad option)
  4. Cancel Moz Pro

I think I’m going to go with option 1 for the time being as there are plenty of other useful features included in the Moz Pro subscription but if they don’t provide a fix in the next 2-3 months I may well start looking around at other options.


Why we moved to CloudFront Content Delivery Network

A couple of months back I broke our website. I didn’t mean to, and I should’ve know better, but one quiet Thursday evening I broke our website. It’s what’s known as a success disaster. Apparently.

All I did was write a short blog post about the new Raspberry Pi Zero which had just been announced that morning. In case you don’t know the Pi Zero is a computer that fits in the palm of your hand and it was being given away free with a magazine — and the regular price for the Zero is just £4! This is obviously very cool so I wrote a short post, stuck it on our company website and tweeted the following:

Then the magazine retweeted it (despite me getting their Twitter handle wrong, it’s actually @TheMagP1) and a few folk clicked through. Nice! Then the Raspberry Pi foundation retweeted it. They’ve got about 250,000 followers. My phone was buzzing every few seconds to announce further retweets and likes. And hundreds of people clicked the link to read my blog post! I was really pleased until I realised our website had gone down.

Which lead to…


I was completely unprepared for such an influx of traffic despite warning clients of such a possibility in the past. To be honest, I never really expect people to read my blog posts. I mean people do, but usually we’re talking tens of people not hundreds. And certainly not hundreds within the space of a a couple of minutes. At first I couldn’t figure out what to do. I thought about asking Raspberry Pi to delete the tweet but this felt like my moment of Twitter fame (silly I know) and I wanted to cling onto it. Then I realised, I had also put the blog on Medium. If I could just send the traffic there instead everything would go back to normal. I set up a redirect from our website and breathed a sigh of relief as our little server perked right up again. Everyone who now clicked the link was able to read the post on Medium but this was traffic that could’ve been on our website and I’d lost it.

What could I have done to prevent this?

There are a few things I could’ve done to save myself from this problem.

Option 1: Not write the post in the first place

Nothing would’ve gone wrong but (and this is for those of you who like Bible references) I would’ve been like the servant that buried the money that time. I wouldn’t have lost anything but I wouldn’t have gained anything either.

Option 2: Used a custom URL shortener

A custom URL shortener is a simple little webapp that redirects people from one URL to another. Media outlets use these a lot to ‘brand’ links on social media. So you might see a link like this: but when you click it you actually end up here:

Short links like this can also hide tags which provide extra info for analytics tracking (e.g. ‘smid=tw-nytimes’ in the example above). Had I included a redirected link in my original tweet I could have easily changed the destination URL to alter where people ended up after clicking it. This is similar to what I actually did here but it would’ve been easier for me to put things right quickly. There are various pros and cons to link shorteners which I may explore in a future post.

Option 3: Use a Content Delivery Network

This is what I actually should have done in the first place. A Content Delivery Network (abbreviated to CDN) is basically a service which copies all the files from your website and distributes them to several servers across the world. This means that no single server ever gets hit with too much traffic. It also means that your site will load much faster for various reasons including the fact that users get the copy of your site stored closest to them geographically. Using a CDN really is the best option for most websites (perhaps all sites?) and I’ve now set this up for ours. Why hadn’t I just done this as standard? Honestly I thought it would be complicated and time consuming. And it was a bit the first time. But so is trying to figure out what to do when your website gets knocked offline by people actually reading the damn thing. I’ve set up a few sites on the CloudFront CDN now and it’s pretty straightforward once you get used to it. And it’s so worth it. I no longer have to worry about our website going down at random times.

Most importantly of all I should have believed more in the content I wrote. Well over 600 people clicked the link to my post and my original tweet got loads of retweets and likes. I wrote that blog post because I was seriously impressed with what Raspberry Pi are doing. It’s not the greatest blog post but I guess that’s the point: It doesn’t have to be.

So here’s my lesson to myself: Don’t worry about ‘writing great content’ just write something real that you care about. You probably won’t get hundreds of readers but you should definitely have a good web hosting and move your site to a Content Delivery Network just in case.