Still pretending to be a designer
Part 3
Design in the mind
In Part 2 we had a crack at designing our furlough pay calculator.
After thinking that we had something that wasn’t that much worse than the other furlough calculators out there but still quite bad, I messaged Chris Basha once more to chat about what we might do to improve it.
He was super generous to pair on the designs with me using Figma. The simultaneous editing feature on it is super slick. Bouncing ideas off each other by drawing them out was a doddle.
Here are two great tips he shared:
Rely on prior art
Chris helped identify the problems in Part 2 and come up with solutions that I hadn’t considered.
One thing that became apparent was that I was a bit lost for ideas, despite being someone who usually finds it quite natural to come up with them.
It seemed that I didn’t have a toolbox of options to choose from when encountered with a design problem. Despite having used apps and the internet for years, I couldn’t bring the different patterns I’d encountered to mind on the spot.
Two tools he recommended for building up a bank of solutions to common design problems were Dribbble and Mobbin. These two sites display a variety of works by different designers, filterable by keywords and categories.
To me, Dribbble seemed like designers flexing at each other, while Mobbin had examples of battle-tested products. The latter was much more useful for my purposes.
Just as I’d tried to lean on Gov.uk, we’d try to lean on a bunch of other products out there.
Look with fresh eyes, question everything
It’s so easy to forget that you didn’t always know what you know now.
As a result, there’s so much you start taking for granted once you’ve stared at a design for a certain amount of time.
I found it very analogous to music production, where you have to try and reset your ears after a session in order to hear your track for what it really is.
Chris asked a bunch of simple questions when he first saw my designs, things I’d taken for granted that were obvious (“is that my monthly salary?…which one is the final amount?”).
Attempt 3
After trying our best to look at the site as newborn babies and having a snoop around Gov.uk, the Monzo app, Splitwise, and a few others on Mobbin, we arrived at this:
Tactics
It didn’t take long to put most of it into code, choosing to leave out a few parts to see if we’d started solving problems that our users didn’t have.
I’ve found leaving bits out to be a useful tactic when you’re 50–90% confident in that bit.
There’s little cost in leaving it out of your first iteration and waiting to hear if your users ask for it. If they do, then you can be way more confident in the feature.
Conversely, if you put it in beforehand your users are much less likely to comment on its redundancy. In this scenario, you’ll never really know if you needed that bit or not. You might end up with useless features and a bloated product.
Also because I’m a lazy developer with the patience of a squirrel.
First version
After slipping on my coding mittens (every developer has a pair), here’s how our live site looked:
You can see the styling’s pretty off because I’ve rushed it (for example, we wanted the numbers in the input box to be aligned with the label on the left). We’ve tactically left out “max amount”, “per month”, and “£x less than non-furlough”.
Believe it or not, it was a conscious decision to leave the styling in this state. The goal here is “good enough to test”, rather than fiddling all day to make the build pitch-perfect.
Being one person (my co-conspirator is busy this weekend) choosing to spend time on styling is a direct trade-off with everything else.
We’ll polish up after a round of feedback, rather than prematurely polishing things we might not need 🧹
Tomorrow it’s Part 4, where we’ll do some bad user research and some better user research.
If you read past the tapir, chances are you read the whole thing. If you dig it, give us a few claps. It’ll help others find this too.
