We (designers and developers alike), are constantly looking for the perfect platform, the perfect framework, the perfect workflow. Although we know that’s a myth. It simply doesn’t exist. We know that, we even admit it to ourselves, we simply won’t say it out loud, we might whisper it, but that’s as far as we dare to go.
The ideal case study
A new client comes to you, knows what she wants, has a good understanding of technology and knows what a web developer does. She also recognises the importance of design, user experience, but best of all: trusts your knowledge.
Then you both agree on a timeline with deadlines and roles. You both equally commit to it.
The project starts. Everything goes as planned. Marvellous. Then you wake up. It was just a dream.
Dream’s over, Frodo.*
* But you can still travel from Middle Earth to everywhere, meet awesome people and learn new things.
I’ve been dreaming of setting up my own (re-usable) templates, both for quoting and for designing, but despite trying for years and with the exception of some small modules, I haven’t found a solution: every new project has its own life, with repeatable patterns. I’m now focusing on these.
- Writing up a contract
- Presenting conceptual ideas
- Developing design
- Front-end development (I hardly do any proper back-end stuff)
- Soft launch (then go to no. 5)
- Final launch
- …and repeat.
1, 2 and 8 require a lot of writing. I have templates to start from, mostly headlines to highlight sections I need to remember to look (at, up, after), but then it’s a lot of blank space to fill in with thoughts, ideas and questions. It requires time, it’s needed, it’s a good exercise and doesn’t get too messy, so that’s okay.
3 and 4 are generally where most of my time goes. When that is true for no. 5 I know something went wrong in no. 2.
Now, designing and developing are also my favourite parts of any project, so that shouldn’t be too difficult to go through. Wrong.
I’ve now identified few issues with my workflow that directly affect these otherwise very enjoyable aspects of my job:
First of all I tend to distance myself from the client while designing. This is okay when the process starts, as I need to actually materialise the concepts the client and I agreed on. An easy mistake is to underestimate how much difference early feedback can make. This is not to say that you should show your client that piece of paper with coffee stains, where you scribbled on during lunch break because of the inspirational moment that happened between your slice of pizza and a sip of elderflower tea. The client won’t get it, you won’t be able to explain it, it’s all in your head. Allow it to settle, then do a proper job: prototype.
Finding the right balance of design and tech functionalities is, at this stage, fundamental: you don’t want to spend too much time developing something you might end up not using at all, but you want the client to get the idea. Don’t leave too much to their imagination. Don’t give them a fully functional website either!
Identify the key objects, make sure you understand your client’s identity, find the exceptions, stress your design on them. If you take care of the tricky parts first, you’re more likely to have less issues afterwards.
These are worth spending time on.
Get feedback. Defend your design and its strengths, but learn to accept criticism in a productive way. Explain why you picked a specific colour or font type, listen to why they don’t like it.
Iterations are important. If you get it right your design will benefit from your client’s feedback rather than suffer from it!
Communication between you, the developer, and your client is the key. Don’t forget that you are the project manager in their eyes. I’ve learnt the hard way (who hasn’t?). Still worth it.