Categories
data visualisation Greps

THINKING IN CODE

When creating or designing something new I have found it far more valuable to get right into the code (or graphic design in previous years). Typically I make the mistake of focusing way too much effort on the final concept, the ultimate feature set. Spending as little time as possible in the research and planning stage helps me realise my own or the projects boundaries and be more effective.

Now, this doesn’t mean that I’m arrogantly skipping these valuable steps, it’s simply that I do them in parallel or after an initial attempt or first draft.

There are a couple main reasons for this. Firstly if you spend a lot of time looking at similar features you will be inherently biased to do something ‘acceptable’, something ‘normal’. Secondly you can end up with something impractical. 

BORING

Whatever your views on Tesla and the new Cybertruck you can’t help but marvel at the concept. The bravery and audacity to do something new in the auto trade is now second nature for Musk and the crew but it’s impressive they can still get everyone’s attention (*1). 

I feel that if you come from the angle of usage first, functionality first, you have a better chance of creating something worth talking about. Something that appears brave or risky but in fact has sound reasoning behind it. Not something overly familiar or normal or that meets expectations. 

Currently at Greps, I’m contributing to our analytics dashboard design as a next step to implementing some of my data visualisation work. Do I really want people to feel they are in a Google Analytics page or do I want them to take notice of our product?

IMPRACTICAL

Impracticality in software implies complexity to me. 

From the developers point of view it is so complicated a design that the time to create it or the 

potential of maintaining it is impractical. No business can afford to operate in an inefficient way. 

From the users point of view it is an assualt on the senses and ends up making you feel stupid or confused. I’m pretty sure no-one ends up intending these outcomes but it happens regularly.(*2)

It’s very easy to dream about the final product (*3), especially if you are visually biased like I’ve been told. Some apps or sites are just a joy to use and it’s very tempting to think about something similar for your own work. I’ve been down this road many times (*4), but often the hard truth hits home about how vague the desire was once you start building.

DESIGN PHILOSOPHY

So what’s a good way forward? I don’t hold multiple CS degrees or an avalanche of industry experience from which to preach from, so instead I’ll merely describe my personal philosophy in a reflective sense (*5). I would hate to come across as arrogant here, so bear in mind there is a touch of idealism in my writing – reality can be a cruel mistress!

REDUCTIONISM – By striving to simplify things, you make the product easier for others to contribute on and easier for your users to comment on. Perhaps a review, a social media comment or a conversation with a friend. The weight of these overtime can really define product or feature success.

MINIMALISM – The best definition I’ve come across (*6) states that minimalism isn’t about being blindly minimal but stripping away non essentials. Simplistic can mean boring and predictable while being minimalist can result in a more effective design and better user intuition about how to use your product.

ADAPTABILITY – If you spend a long time in the planning stage it’s easy to become beset by the sunk cost fallacy (sticking with something due to time, money or emotional investment already made). It can make the design fragile as things are narrowly defined. The concept of saying what it shouldn’t do at each stage can potentially lead to more unique products and certainly force more functionality on the product. It makes it adaptable to input. (*7)

A robust process leads to a stronger product. You want every piece of feedback to strengthen your reasoning for each little piece of the product. Or to offer insight on something that hadn’t even occurred to you.

GET CODING

The end result I strive for is something where the investment of time and energy has been engaging and rewarding. Something you have a granular level of appreciation for. Another way of saying this in relation to my earlier example is that instead of just designing the shape of the Cybertruck, you understand why it has to be this way because of the material properties and the effect on the physics of movement.

I guess instead of reading all that I could have just tweeted that you should dive right into the code of your concept to see what you are really capable of! 🙂

NOTES

  1. It’s obvious they didn’t look to other trucks for ‘inspiration’, they thought about it purely from what is possible. If they hadn’t done this they would have missed out on crossover with Space X, using their materials which had a lot to do with eventual design. You could argue that it was functional first, searching for the strongest body rather than making a metal fit a finished design. It is so square because of the metal.
  2. Trying too hard to please customers and building everything they ask for is one reason. Too much democracy in the design process could potentially be another. What software do you hate?
  3. This is a black hole of visual inspiration 🙂
  4. Fom writing a Python function to writing a blog to building a graph to creating an app. I have to fight this tendency every time I start something new!
  5. Perhaps this discussion treads on the toes of an agile or lean methodology description. That is to say that there is lots to like about these approaches but they don’t align 100% with my current approach.
  6. See all of Cal Newport – I’m a fanboy!
  7. It’s my intention to write about some practical examples soon.

Leave a Reply