Sometimes it’s not about designing, it’s what we can use that design to do, no matter what viewport, what screen or what device. A design can change someone’s world. We should really remember that, we can think bigger and greater than we do.
On the 15 Feb, Paul Boag, who I respect and admire wrote this tweet.
…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;
- Do I get job satisfaction from producing design that the client loves? No.
- Do I get job satisfaction from producing design that my peers love? No.
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.
Alex and I have catalogued our discussions and packaged them in to a series of Q & A with the first being “Shaping the product’s interface.” Enjoy!
When we were learning as children, we always asked important questions. More often than not the main question was, Why? We as adults joke about children getting to that age and how they continue to ask why after the 2nd and 3rd time.
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’.
Creating a product is exciting. Building it to a stage where you have real people taking part in your own creation is phenomenal.
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 was walking to the office this morning, head phones in ears listening to a few of my favourite tracks. I began thinking about what I had to do today, what I achieved yesterday and what I’d like to achieve by the end of the week. Just to put things in perspective for the past 6 or 7 weeks I’ve been wire-framing around 4-5 different projects. They’ve been a real mix, some iPhone apps, an iPad app and two web apps. Whilst I find this highly enjoyable as it’s a huge part of my personal process, I knew that I had some iPhone app design work coming up.
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.
When designing for the web, the focus should be on the content. If it’s on anything else you’re doing it wrong.
It’s easy to pump an idea full of features when designing. A set of stages where you think to yourself “Oh that would be great!”, “We’ll need this…” when in actual fact you won’t. Next time, sit back and ask yourself to simplify it. Then simplify it again. You’ll find doing that will increase the experience for the user as well as pulling unneccesary bloat from your design, whatever that might be.
So next time just stop and simplify.