Things I learnt as a designer learning to program (Part 2)
In part 1 I covered “Code”, TDD, MVP and naming things but there are a couple other things I feel designers could draw lessons from based on my experience of learning about programming at Makers Academy.
When it comes to solving problems good developers timebox things to make sure they don’t spend too much time going down a rabbit hole. On the course I ended up burning 2 days time on a project trying to hack a library to do what I wanted rather than deciding 20 minutes in that it was looking too hard.
More experience will help make better decisions, but one approach that our coach Dan shared was to split our day into time slots, using a pomodoro technique or something similar you can start tackling a problem and if you aren’t getting somewhere after 20 mins it’s time to try something else.
I’ve done this myself in design work, early on in the process I’ll dedicate too much time to one particular idea rather than experiment with a few options and assess which route to go down. Timeboxing things can help to maximise design time and break down problems into smaller chunks. This is more important early on when you want to get a range of ways to solve the problem without overcommitting to one particular way. Maybe there’s a need to redesign the site navigation or product listing page. Being disciplined with timeboxing conceptual work early on will mean rather than having one overly designed idea at the end of the day you can have a few diverging concepts to assess.
The big one. Most importantly good developers understand that shipping is winning. Something shipped is something valuable (whether it’s a success or failure you can learn something of value). Designers, by nature want to perfect each aspect of the experience and rather than playing down the importance of this (and putting myself out of a job!) the point here is more about learning when to draw a line for the sake of getting something shipped and in peoples hands.
A good designer needs to think of their deliverables as not just wireframes and clickable prototypes but live features. A sketch file full of amazing interaction and navigation patterns isn’t immediately valuable in and of itself. A shipped feature being used by customers (with room to improve from a design perspective in the next sprint) is valuable.
I’m not advocating half-baked scrappy designs but a few times I’ve seen teams miss a delivery of a key feature due to a few extra design requirements they felt were really important but were not absolutely essential to the feature.
Everyone will have their own idea of when design work is good enough to roll out, but that’s where understanding hypotheses, MVP and defining “done” comes to play. The (hard) question to ask is “is this experience good enough to put out?”. All things can be improved to varying degrees but is this good enough right now to get out and start learning from?
I’m still new to programming and keep trying to build small things as I go along in my job as a UX designer. Hit me up with your experience of learning to program from a non computer science background. I’m always interested in knowing more about how designers are using more code in their work.