In August I launched 12in12: The Side Project Project with the aim of completing a new side project every month for a year to coincide with my year working as a UX designer at Puppet. Now the first month-long side project is in the books (plus my first full month at the new job) and it all… actually kind of worked out? I’ll be honest, not what I was expecting. Let’s break it down:
What? Refactoring my portfolio site to add maximum value without a full redesign, preferably with all learnings and additions applicable in future even when the site is redone.
Unfortunately didn’t make it to any of the Icing (extra items, stretch goals, call them what you will) like animated page transitions or writing original articles rather than porting old ones but the core objectives were achieved.
What this really made me realise, especially while adding the embarrassingly rough blog index + post layout, is how inadequate my portfolio is for my current needs. Ideally the whole thing will be ripped apart and rebuilt from the ground up. Part of the reason for attempting this project was to kick the tires of the site to see if it really needs the redesign I thought (spoiler: it does) while also adding value that will transfer to any redesign. However, while I am far from satisfied with the design I’m happy to finally have new content in place.
Design really meets practicality when maintainability issues rise. At some point the rubber hits the road and those tires better last and not give me headaches every time they need some extra air.
Dealing with how to implement and maintain simple components and case studies/posts on my portfolio was enough of a headache at the start of all this, now just imagine that same issue at scale. It really put the practical constraints in perspective and made me appreciate the developer pushbacks against certain designs. Design in the real world means a lot more about feasibility and constraints.
It’s not just what’s the best solution, it’s what the best solution for the current context that can actually be made and delivered in the assigned time.
However, all that said it’s still important to balance development concerns with the design perspective and understand why you’re pushing for change (even if it can’t be achieved immediately). In particular, an issue arose around a progress bar component which is going to be used that means certain design elements can’t be used but if enough key indicators are dropped, is the progress bar really meaningful to the user anymore? Know why you’re doing/adding everything so you’re never just implementing a component because it’s there and easy to add + maintain.
That’s what they tell you, then they set you loose in the wild world of tech with lots of jargon you don’t understand and while arguing on twitter about learning all you can vs finding your niche, programming unicorns vs designers shouldn’t code, and so on. My take? You don’t have to do it, but you should learn it. After all, isn’t part of your job to be curious and willing to learn?
Designing for an extremely technical software for extremely technical people can be challenging but I decided on day one to absorb as much as I can. I’m not going to become a sys admin (nor do I need to), but learning the language and understanding what my teammates are talking about half the time is important to me. Thanks to helpful coworkers and healthy heaping of googling, I’m now set up with docker, several local software builds, and can spin up a virtual machine to test out different versions whenever necessary. Perhaps it’s nothing special to others but I appreciate being able to understand more of what is reported each stand up.
Inspired by that ‘hey, all this command line stuff really isn’t so bad’ feeling, I implemented the Grunt task manager (with help from this great old Chris Coyier article), jazzed up an iTerm with pretty colours, and dabbled in more non-Git related terminal activity than I’ve indulged in quite a while.
There’s a temptation with design to make the thing, set it out in the wild, and then dust your hands and call it a job done. I admit, I was a bit nervous sticking wireframes up in the hallways for everyone to vote on when I was still learning names and faces around the office so actually taping them to the wall was as far ahead as I’d thought. It wasn’t until a mystery coworker (thank you kind sir/madam!) stuck up a note in bright red to attract those passing by that I realised my mistake.
Post research in the hall? Ping everyone in the office chat about it. Talk about it at stand up, lunch, and everywhere else. I’m sure by the end of it everyone was sick of my reminders but that’s the thing: what’s the good of research if no one participates? Just like what’s the point of building that website if no one ever sees it?
Prepare for the tweets. And more or less what I’m doing now with this blog. It’s scary announcing intentions to the inter webs (or the one or two people on it who are reading this) and revealing all the mistakes and potential failures along the way. But hey, we’re all learning something.
As there should be.
Month 2 begins now! In September we’re mixing it up a bit and going to be learning something completely new and totally unrelated to my day to day work. But hey, that’s what side projects are for! Stay tuned.
Made to the Sound of BTS - Love Yourself Answer