Posts tagged with ‘process’

Selling yourself


If you’ve visited my website in the last year or so, you may have found it strange that there are no case studies of my work anywhere on it. Despite being my main portal for explaining who I am and what I do, you can’t find a single example of my work.

I get weekly emails from different people in the design and dev community, asking why they can’t see my work. I’ve had it brought up in job interviews

It’s not because I have nothing of interest to show—far from it—in fact, I’m very proud of my work, and want to show it. But, I’ve always been a huge fan of long-form project explorations written by the likes of Teehan+Lax and TypeCode, so throwing a bunch of images onto the site without any copy was never going to be an option for me.

It’s not that I can’t write—I can throw together a blog post, and I regularly put together half-decent copy for my clients’ websites—it’s that I struggle to write about my work. The more I write about my process and what I did and why, the more detail I go into and the more pretentious my prose becomes. So much so, that I end up deleting it all and starting again.

To tell you the truth, there is a full case studies section of this website, designed and built in spurts over the last year and almost ready to go; but you can’t see it. There are lovingly art-directed pages with matching calls to action, integrated across the site. There are some great interactive elements and work examples, all interspersed between 74 paragraphs of text. All of this is hidden on the live site.

I’ve considered hiring a ghost writer multiple times, but while I’m not actively looking for work this seems like an unnecessary investment. And so, on a just-about-monthly basis I sit down and I write, and delete, and procrastinate, and rewrite until I’m bored and distracted and move on to other things.

One day in the future I might come up with something I’m happy with, but until then, this site will remain work-free while I continue to torture myself.

Looking out for the little guy


I am not a web designer.

I market myself as a web designer, because that’s what my clients think they want. In fact, what they want is a person who makes websites.

That’s what I am. I’m a person who makes websites. And apps too, if you’re feeling adventurous. I’m a UX designer, a UI designer, a front-end developer, a back-end developer, a hosting provider, a sysadmin, a copywriter and a marketer.

I’ve done all of the above individually, for different companies at different times, and also I’ve done all of them at the same time for a single client as part of a larger package, which I will refer to as “a website”.

Primarily, I work in front-end development. But to any client outside of “the web”, this means nothing. They don’t care about day rates, the tools I use, or the maintainability of my code; they want to give me a brief, and when the website is live, hand over a cheque for a pre-agreed amount.

There is much talk in the web community about the latest responsive trends, scalability tools and performance optimisations that should be used on the web; and much berating of those who shy away from them. This criticism is often short-sighted. Granted, the above are all important aspects in the building of a website, but they also cost money; money that the average client simply doesn’t have. But why should a lack of budget deny a client from receiving a website that employs good design principles?

The answer is in the base elements of the design; the layout and typography. Dan Donald talks about this at length in his great talk Flux and Flexibility. A well designed website could be as simple as a single column layout, with a good typographic base. Inherently responsive, a design such as this could easily catapult a small business into the modern era of web design, for very little cost.

But instead of this, too many designers concentrate on adding embellishments that add nothing more than zeroes to the price of the site. They may be eye catching, and no doubt will appeal to the client, but by placing these front and centre in mockups and prototypes, when it comes the time to remove features in order to fit a project within budget, these are the features which the client will want to keep.

But there are many aspects of web design that clients might not fully understand; responsiveness, performance optimisation, maintainability, accessibility. Why would any client choose these as features of their website, when the fancy lick of paint that masks them looks so appealing?

The answer is progressive enhancement. Not in the development sense, but in the process through which the website is designed and built. When creating mockups and agreeing quotes, start with that simple, single column layout. Explain that although such a design may not be the most modern, or the most eye catching, it is functional and inclusive across all devices, connection speeds and ability levels. Explain that embellishments cost extra, and add to a simple base, rather than removing features from an over-ambitious mockup.

If we were all to work in this way, the even the smallest of budgets could allow access to well designed, well implemented sites. Clients would not be disappointed when their users complain of lack of support for their device, or inaccessibility.

And why shouldn’t they be allowed access to good design? People laugh at clients who come to them with budgets in the range of hundreds, rather than thousands; but this is unnecessary. A website can be built in a couple of hours. It won’t win any awards, but if built properly and populated with the right content, it will be functional, and more than likely meet the clients needs.

So think about this the next time a small, local business comes to you for a quote. Spend the time to talk to them, and remember that whilst a simple website built in a couple of hours might not be up to your usual standard of work, it might just be the best thing that’s ever happened to that particular business.

First past the post


There have been two exciting new products doing the rounds recently. The first is Execute, a fantastic book by Drew Wilson and Josh Long. It is about “executing on ideas immediately when inspired rather than following the normal rules”. The second is Medium. Created by Twitter founder Ev Williams, it is an online magazine, open to contributions from the public.

I only managed to pick up Execute this week. I read it cover to cover in under two hours. I really wish this book had been written 2 years ago, when I first had the idea for a website very similiar to Medium, called The Branch.

The idea was almost the same, anybody can submit articles and assign categories to them. Readers can then subscribe to a category, an author or a group of authors, and each are presented as individual collections or “magazines” within the interface. I even had plans drawn up to give a percentage of advertising revenue back to the authors.

The interface for article creation was fairly innovative, and aimed primarily at those with no knowledge of HTML, without resorting to other languages like Markdown or Textile. You can see some screenshots of the interface on Loviv (link dead).

The problem? I wasted time. I tried to build this mammoth interface all by myself, around my daily work. I completely redesigned the site three times, as having stared at it for so long I grew bored of it. I strived to create the perfect experience, and never finished, rather than concentrating on ensuring that the product shipped.

When Medium was announced publicly and went into private beta, I immediately pulled the plug. The team at Medium managed to pull off exactly the vision I was striving towards, to allow anybody to easily create articles in a beautifully typographic way. They did it with a better design, ethos and infrastructure than I did, and with the traction and publicity that Medium has gained since being announced, there was no way that my product was going to compete.

What I should have done, as suggested in the Execute book, was put aside the time to work towards the goal I had. I should have been unafraid to ask for help, rather than trying to go it alone in secret, for fear of the idea being stolen. Had I done that two years ago, I may have been able to get the site live long before Medium came into existence. Instead, I have two years of wasted evenings, with nothing to show at the end of it.

Since the day I pulled the plug, I’ve been far more focused when I come up with an idea. I actually ended up reusing the name and domain I had for The Branch for another exciting project which I built in a little under two weeks, and am now immensely proud of and enjoy maintaining.

Since reading Execute, I now know exactly where I went wrong, and will use the approaches recommended by Drew and Josh when I next come up with a great idea.

I’d recommend this book to anyone who works on projects in their spare time, it’ll save you a whole lot of headaches. Go buy it now.