My front end responsive workflow
Front end development has come a long way from the days of Photoshop comps that were sliced into little bits and sprite-sheeted for rounded corners, boxes that broke grids and drop-shadows.
I started out on the web like most front-end devs: fiddling around. The web is beautiful because the front-end is open source by default–take any web page, and with a browser and notepad, you can take it apart and rebuild it. That captured my imagination is such a big way, it became central to how I saw the world.
I then studied, graphic design, interaction and game development, even taking art classes now and again. I painted, I drew, I 3D modelled, rigged and animated, I programmed visual effects, designed sound environments, even shot and edited video. My courses were most defintely driven by art, but my understanding of all of it was from taking it apart and rebuilding. It wasn’t self expression, it was problem solving.
I may get shot for saying this, but contrary to popular beliefs about design and ‘creativity’, design is not subjective. There is right and there is wrong. It exists to solve a problem, and a successful design does just that.
Often subjectivity arises because of the vocabulary we use: we talk about impressions and feeling, user comfort and pleasure; we discuss people’s cultural histories and the intonation of language, but we use all this information to make informed choices about visual things that get confused with art. Behind all the colour and form, there is always a core goal: to sell more product, to streamline a process, to enable comfortable reading, to build a following.
It is often very hard to decide on a metric for success, but it is the single most important decision you will make. So pick one and measure. Even a subjective measure is a number: percentage of people who like it, number of smiles it generates, time spent on a page. Then measure, change & repeat.
Artists don’t work this way, engineers do.