By John Surdakowski,
Dec 10, 2013

The web community with a grain of salt

The web community with a grain of salt

websalt

This is going to be my first article in a series on Freelance Web Design Advice. Every week I’m going to be posting a new article about freelancing and the web community. Some might be advice. Some might just be rants.. Like this one below. Enjoy.

I read a lot of blogs. A lot… Most of us in the web community do, especially freelancers trying to further their craft and business. We read everything that our mobile devices and tablets can hold. We have our favorite reader apps, filled with tutorials, tips, tricks and advice. Whether it’s Flipboard or Feedly. Pulse or Pocket. There are tons of articles and publications to fill them all. And this is great! In our industry, we need to be continuously learning and advancing our craft. Both on the implementation side as well as the business side. Many of these tips are useful. Some are even necessary to ensure our survival in the ever growing ocean of freelancers and web professionals. But which of these “tips” should we apply? How do we sort through the pile and select the proper approach for our projects? What may work great for one project or company, may not work at all for another.

The web is changing every day. New advances are causing us to alter our approach to how we design and develop. This is also changing our process and how we pitch to clients. Gone are the days of putting together a wireframe, designing a bunch of pixel perfect, beautifully crafted PSDs, shooting them over to the client and converting them into working web pages. Ever since the mobile device explosion and Responsive Web Design, we’ve been treating projects differently. Some of us have a different approach to each project. Maybe we design in the browser, maybe we use Style Tiles to start the design process. Perhaps a Mobile First approach. These ideas are just some of the many different approaches suggested by the web community. Are they right? Which one is the best approach? The answer… None of them and all of them.

In the past, I found myself reading articles about how to approach a project. Let’s say it explained how to go about charging a client for a web design project, by “bucketing hours” into each phase. I read this article, and when I was done, I felt like I had all the answers. “Wow, this is great! I now have a new approach to charging clients which will change my entire business. Eureka!!!” (I wouldn’t really scream eureka…no one does.) While some of these suggested approaches worked, others did not. Do you know how hard it is to explain to a client that they are going to pay you a 30% deposit for a project, only to realize that there is a set amount of hours allocated to the first phase? Or that they are only receiving a certain amount of revisions? An approach like this takes time, experience, trust and a solid background to be able to prove you can complete the project, without gouging the client for extra fees.

What about “designing in the browser?” Many web professionals are screaming that this is the best approach to a project, and sometimes it is. Personally, I’ve worked on a few projects where this went over quite smoothly. The client LOVED the fact that they can see their website working in the browser, on mobile, on their tablet. (Great success!) Other times? Well, let’s just say we ended up doing a lot more work than we anticipated. Now, couple this process with an hourly approach, and you’ve got some explaining to do. If the client has past experiences seeing Photoshop Mockups, before coding, and you show them a coded website (which you spent billable hours working on), that they’re not happy with… The conversation might get awkward.

I’m not saying we should ignore all advice from the community. We should absolutely try to learn from our peers. Tweaking our approach and process, until we, as well as our clients, are comfortable. But not every project is the same. Just because you read an article about how a large agency or a niche design studio approached a project, does not mean it will undoubtedly work for you and your team. Sure, you can try out different techniques and processes, but don’t treat them like the holy grail just because you read about it on the web.

Whatever process you create that works for you, your client and the project, is the process you should go with. If the client does’t understand the process, it is our job to make them understand. Read your blogs, advance your knowledge, but remember every project is not the same.

Let m know what you think in the comments.

Thanks
John