Just incase a few of our readers haven’t come across your name before perhaps you could tell us a little about how you got started, your history and how you ended up where you are today?
Daniel: Of course! Ever since I was a kid, I knew I wanted to do something artistic. I used to draw all the time, so I figured I would go to school to be a 3D animator. Once I went to school, I quickly realised that I wasn’t very good at 3D animation, but I did very much enjoy combining graphic design, interaction design, and motion—a perfect fit for what the web was in those days. The rest is history.
(For those curious, I tell the full story in my interview with The Great Discontent.)
You have RIF as one of your clients and you are also writing an on going story about how your are approaching the project (thank you for that by the way… amazing). There seems to be a lot of back and forth communication with the client throughout the project process and tonnes of iterations. While I know that *is* what is needed for a successful responsive project I’ve also found that it is biggest concern and the question that I am asked the most by agencies – “How are you able to successfully price the RWD process without either quoting stupid amounts of money or taking a loss on the project?”
Daniel: There’s a lot that goes into pricing projects. Most people and agencies that I’ve come across charge for their time, so naturally it’s a risk to do something new where you can’t quantify your time as definitively. That’s not exclusive to responsive web design; the same time happened in our industry when designers and developers were moving from table-based layouts to CSS-based layouts.
I’ve found that my projects tend more to consist of things I don’t know how to do than things I do know how to do. (Shh! Don’t tell my clients!) Rather than billing by time, I try to charge by value for the entire project. Part of that value pricing means leaving enough margin to experiment, which means time to do work and re-do work without any penalty to my client’s business or my own business.
I talk a lot about these kinds of things on The Businessology Show, a podcast about the business of design and the design of business.
Moodpik was another client you’ve got who went with a desktop and mobile design, but not all the way to responsive. With web app sites like weatherrr.net and forecast.io now making some traction do you think there’s an argument for responsive web apps?
Daniel: I think there’s always an argument to be made for building flexible solutions, whether responsive or otherwise. For me, responsive isn’t a goal; it’s a strategy we can use to accomplish our goals. It’s a way to future-proof.
I love the design work that you personally produce! Can you explain your workflow when approaching a redesign and how, if at all, you have had to change that approach when you are designing responsively?
Daniel: Thanks! Yes, my process has changed almost entirely. Before responsive web design came along, I think I took for granted that clients understood the process of a redesign. I could send over a picture of a website and they’d get what it meant with minimal explanation.
Because responsive web design is so relatively new, I find myself over-communicating with clients, not in a patronizing way but spending more time in explaining a concept that may be foreign to them. Not surprisingly, the projects where I’m doing the most education are the most smooth. As a result, I’m actually being more and more intentional about sending over “deliverables” that can’t easily be understood without an accompanying conversation. I’m almost forcing myself to have to communicate, and I think that’s a good thing.
So that’s the end of the “Dan” specific questions. The last two questions are the same for everyone.
What is your favourite implementation of responsive design?
If someone is beginning their new responsive site next week what is one piece of advice you would give them?
Daniel: Prototype, prototype, prototype. I learn so many things through bouncing back and forth quickly between Photoshop and Sublime Text. I’d recommend ditching a waterfall process with testing smaller concepts. For example, let’s say you have an idea for how navigation could work across multiple screen sizes. Before going any further, code that small piece to see if your assumptions are correct. I promise you’ll discover small surprises that you hadn’t anticipated when you actually see it in action.
Thanks again for being a part of the series Dan! How can people hire you or find out more information?