On the 15 Feb, Paul Boag, who I respect and admire wrote
…We need to realign our thinking. Job satisfaction should come from producing design the client loves, not design we (or our peers) love.
This got me thinking.
Job Satisfaction – To love what you do as if you don’t class it as ‘work’, it’s just that thing that you love doing and that thing which you do best. At happiest, I don’t go to ‘work’, I go to a room which some people call an office to do the things that I love doing. If I roll back to previous places of work and answer these two questions;
For other people it probably depends on the type of work you’re doing. Generally your client isn’t your end user, the end user is effectively the clients client. Design is heavily subjective so designing to the personal requirements of a client is dangerous ground. I believe any good designer can research and plan and then communicate in detail to their client as to why the design need not be right for them but will be for their clients.
My thinking on this is that job satisfaction need not come from producing design the client loves, but more that you’ve created great tangible design that delivers the requirements of its purpose. It could be there to delight, to provide intrigue or as most designs are, to make money.
I think I understand where Paul is coming from, and believe if this is directed to the likes of dribbble et al, then yes, getting the most ‘likes’ isn’t effective design at all. Whilst getting feedback from your peers is recommended and I implore you to do so it doesn’t mean we should be designing for them never mind seeking our own job satisfaction to do so.
I would suggest we all take a sit back and think before we start our next piece of work and think about who we are doing it for and then go from there and communicate that effectively and enjoy what we do for the right reasons.
There’s been so much work happening over at happiest over the past month or so and transitioning my design process in to a lean environment has had it’ s challenges but also had some great successes.
Each time a child asks why and receives an answer it generally asks it again and again and each time we have to get more specific with our answer or at least make it a little more descriptive to provide more context. Sometimes we run out of answers on the 9th time but we try our best.
Surely at such an early age, children cannot treat the first answer we give them as the only answer they’d receive. Do they think we’re joking with our first answer? Probably not. Once we start answering the same question a 2nd and 3rd time the child knows we can go as far as that. Each time we make our answers longer and eventually the child will get as much context and description as they’d ever get and understand ‘why’ better than they ever could.
I’ve never stopped asking why nor I ever will. This is both a good and bad thing. To a point it’s like a slight OCD, I have to understand the why. If I can’t fathom the why, I become easily frustrated or put up barriers to the information I’m hearing. If I don’t understand something, I’ll keep asking why until I do understand as each time I ask there will be more within an answer. Understanding the why is a little easier out of conversations than in them, I can research and read my way to an answer with more context. In discussion, the people I am talking to can unfortunately become frustrated with the amount of information I require without me explaining my questioning in the first place but I feel they still need to be asked.
The reasons why should ALWAYS be known.
I often bring this in to my work as I expect rather than assume that people other than myself would like to know the reason why they should either do something or use something before doing it. This information should be available to read or see at the lowest barrier of entry, it should be a gate that can be pushed open rather than the need for a key to unlock. By that I mean that a user should not have to think about the why and should move instantly to visualising themselves doing the action.
They and we should ‘Understand The Why’.
It’s too easy for us when building a product to build it for us, to have a feature list that WE want. Unless you are very controlled it is far too easy to create an ever growing feature list the size of an aircraft carrier. This is bad when you’re wanting the product to be like streamlined submarine as we all know aircraft carriers do not fit inside of submarines.
Take more time to realise that your users and yourself are so different in reality. Just because you want to do something one way doesn’t make it the same for someone else using the product. Always act on the side of caution and focus on what a user would want to do with your product from various places and make decisions accordingly.
You can limit feature creep extremely well by remembering that what a user wants and needs are COMPLETELY different. On top of that remember that what you want in your product, a user might not need.
I’m like a kid at Christmas when I know I can get my head deep in to photoshop and start creating some visuals.
How happy I was walking, listening and thinking reminded me of New York when I was there last year.
Jen and I had walked up and down Manhattan a couple of times but on this particular day it seems to be packed. If I remember correctly we were on our way back from the Financial District and decided to criss-cross over to fifth ave. We were wandering around as tourists do, getting in everyones way when I heard a guy singing. Generally in the UK people busk so it’s not un-common to hear buskers on the street however this was closer, this was right behind me.
I looked over my shoulder to find a young guy, early twenties singing at the top of his voice dancing in and out of the people around him without a care in the world. Most people would have branded him as mad, but you know, I bet he was the happiest guy in New York on that day because he couldn’t have cared less.
He was happy in what he was doing, just like I am today with my head stuck in Photoshop.
So next time just stop and simplify.