How I Learnt To Do UX Design

I’m an engineer by background. We don’t have a designer in my startup Futurecam. After trying a lot and not finding a suitable designer to work with, we mostly ignored UX. Having worked at a giant company, I had a rigid mindset — if we didn’t have a person whose job title is Designer, we can’t do design. So we’d launch an engineer’s UI, a UI built as part of an engineering task, which may not be the best.

One day, we had a small problem: the text wasn’t comfortable to read. It was too small. Earlier, when problems like this came up, I’d tell myself, consciously or subconsciously, “We don’t have a designer, so we can’t solve this problem.” But this time I happened to tell myself, “Let me look for a reference online. It can’t be that hard. I may not be able to do Design with a capital D, but I can surely look up a reference on what font size to use.”

So I I looked up the iOS Human Interface Guidelines, but it didn’t tell me what font size to use. I looked for other suggestions, but couldn’t find any. When looking for references didn’t work, I asked a designer friend. I was expecting a solid answer like “14pt”. Still no luck.

At this point, I thought, “Why don’t I play with different font sizes and see which I like? I may not be able to determine what size is right — that requires a Designer— but I can see which one I like.”

After doing a few experiments, I concluded that 15pt white-on-black works well for me on the iPhone [1].

Importantly, this was the right solution for our context, since we’re a camera app that is used outdoors, with sun on the screen, or crouching looking up at the phone on a tripod pointed up into the sky. So the text has to be readable in a variety of situations, not just an ideal situation of sitting in a chair comfortably, with the phone at the right distance, and without sun on the screen [2]. When you figure things out for yourself, you find the right answer for your context. When you look up a reference, you find an answer that’s right for many situations, but not necessarily yours.

I have a mild vision defect, but I could read 15pt comfortably. This is important since half of all people have imperfect vision. By determining the answer myself, I unknowingly ended up taking care of this.

I also learnt that 14pt is readable, but not comfortably. And 13pt and below isn’t readable at all. On the other hand, 16pt isn’t more comfortable to read — it’s just bigger without a benefit. Now I know how much I can push things if needed. This is extra information I wouldn’t have had if I just looked up a reference.

A month later, I did another small design task, again so circumscribed that it wasn’t scary.

Sometime later, we had to re-evaluate the overall structure and navigation of our app, what the screens are, how the user navigates from one to another, and where settings are available.

This is a bigger task than I’d done before. But I gave it a shot, inspired by my confidence from having successfully done a couple of small design tasks.

I set aside an hour or two one afternoon, and when I was done, the result was ugly. So I tried again the next day, and again came up with a useless design.

My colleague told me I’m not good enough to do UX design.

I was disheartened for a while.

Then I decided to try again, but with patience, rather than saying, “It should be done in a couple of hours.”

I tried to sketch out an idea on paper. It didn’t work out. Then I tried another. That idea turned out to be half-formed and didn’t do anywhere. Then I tried out a third. Eventually I realised that paper wasn’t working for me. It was too low-fidelity. I didn’t even know how many controls I could fit onscreen. I ended up placing more than actually fit. When I realised this, I over-corrected and placed too few. Either way, I wasn’t making progress because the medium I was using (paper) was too far away from the final medium (iPhone). It was too low fidelity.

A designer suggested printing out an iPhone screen template to get the sizes right. So I downloaded a template, printed it out several copies, and verified that they printed at the right size by putting my iPhone on top of it. The size matched exactly. This seemed promising. I tried putting two buttons in a certain area and found they didn’t fit. I concluded that there’s place for only one. After all, I was now using a template that was accurate, so that had to be the only conclusion. But I then realised that my handwriting was too big, much bigger than the font size that would actually be used, in which case the two buttons did indeed fit.

So paper wasn’t working out.

So I switched to a tool I already know as an iOS engineer: Interface Builder, which is normally used for engineering work, not design work. But I was familiar with it, so I dove into it, with a voice in the back of my mind telling me I’m doing it the wrong way. I told the voice, “That’s okay, I’ll redo it later using a ‘proper’ tool.”

I created a new “UX Design” project with no code or logic. I could now place things onscreen knowing they’ll fit. It felt closer to the real thing. I created multiple screens by copy-pasting the first one and changing what needs to be changed. This turned out to be much quicker than redesigning from scratch. It was also consistent — things that didn’t need to be changed had the exact same size and position and font and everything, as they should, which won’t be the case if you redo it for the second creen. I set it up so that pressing a button in the first screen takes you to the second one, and a back button in the second brings you back to the first. I plugged in an iPhone and ran it on, seeing the UI on the iPhone and navigating through my prototype. This brought the whole exercise a step closer to reality.

As I designed, I was conflicted about a decision and went back and forth. Eventually I realised that these are two different designs, and diverged, by copying the Xcode projet as a whole, and trying the second variant there. You can’t evaluate while generating ideas, any more than you can drive a car in both forward and reverse at once. So try out both, iterate and improve both, give each of them some time and space to develop, and then decide which is good. This is the concept of diverging and then converging. Yes, it takes time, but that’s the only way you can get a good result.

In my case, I showed it to the engineers in my team [3], including one who has a good sense of UX, and a couple of designers I know. They suggested some modifications, so I improved the two designs. But one of the suggestions we wanted to try out because we weren’t sure. So this was a further divergence, ending up with three designs.

We decided one of the three was no good, so we dumped it. In the next round of review, more interesting ideas came up, so we ended up with seven different designs. We rejected a couple, and then three more, ending up with two. I couldn’t decide between the two, so I kept this on the backburner. A week or two later, it was clear that one of them was the best one.

Don’t obsess about finding the right tool for the job. Notice that I used Interface Builder, an engineering tool, for UX design, rather than a tool that designers use, like Figma or XD. But the right tool for someone else may not be the right one for you. The right tool is the one you already know. When you’re trying out things, focusing on finding the optimal tool is premature optimisation. The tool isn’t important; what you do with it is. I even designed the UX for our Android app using Interface Builder. This runs on my iPhone, which I handed to our Android engineer and asked him to implement. I did a screen recording as I used the prototype and shared the video with him. I also wrote a spec like this:

- Font size is 16pt, except for technical info, which is 12pt.
- Text is always black on white or white on black.
- The viewfinder has the same aspect ratio as the video.
- The viewfinder is vertically centered, and aligned left.
- The fade out animation starts after 6s, and takes 1s to fade out.
- The bottom of the thumbnail aligns with the bottom of the viewfinder.
- The shutter button has no padding to its right.

The engineer told me he had Xcode installed, and asked for the Xcode project, so I shared it with him to refer to.

Keep yourself grounded when doing work in an unfamiliar area. Go with the concrete, not the abstract. Do some work, even if mediocre, as opposed to reading yet another blog post about “Design Thinking”, “User-centered design” or some other word salad that doesn’t affect your design and so is ultimately useless to you right now.

As I kept doing this, I did bigger and bigger things. I moved on from doing one small design task to doing the UX design for our app. I realised that I’d graduated to playing the role of the UX designer. I’m not as good as a professional UX designer, but I get the job done, which is the important part. This is a big step up in career growth, because you’ve gone from a person who can perform one function (engineering, say) to a person who can perform two.

I tried showing my work to some designers I know to get feedback, and some were more helpful than others. The most helpful person was a designer who started his career as an engineer. He vocalised what was going on in his mind as he navigated through our app. Some others weren’t helpful. For example, one person basically said it’s not good and I should work with a designer like him to get it to the top level, for a high fee. When I showed him two designs and asked which is better, he said, “neither”. He didn’t suggest a third design of his own, either. I didn’t waste more time talking with him.

What lessons can we learn from this?

Don’t limit yourself by your job title or background. Don’t tell yourself, “I’m an engineer so I can’t do design.”
Don’t let others tell you that, either.
To do work in a completely new area, like design if you’re an engineer, give yourself two weeks to design, without any engineering work planned for this time. You can’t switch between engineering and design like “I’ll do design from 2 to 3 PM” because they’re different ways of thinking.
Be patient. You won’t succeed immediately just because you need to. Just because you have only a limited time for something doesn’t mean it will happen in that time. It will take multiple iterations and work out the way it does based on the task.
Specific UX tasks like designing our app icon can and should be outsourced to a specialist in that area. You can’t do it in the short term, and neither is it worth spending the time to learn something that’s self-contained, without being deeply interconnected with engineering as with the core UX of the app, and for which
You need to evaluate a mobile app UX on mobile, not desktop.
Do design work at the right level of fidelity.
Ignore people who can only give vague, non-actionable criticisms. Actionable criticism like “This text is too small to read comfortably.” is helpful. Especially among designers, perfectionism is a common tendency, and one that’s useless at this stage: when you’re doing design as a non-designer, it won’t be perfect. You want concrete suggestions to improve, not naysayers. If you don’t have the right designers around you, it’s better to get feedback from fellow engineers, or users, or others, than to talk to negative people.
Diverge and converge.
Don’t worry about using the right tool. Use whatever tool you know. The outcome matters, not the tools. Obsessing about tools can increase the barrier so high you won’t be able to jump over it. Doing work outside your area of experience is hard enough.
Work as a founder, since all problems are your problems, giving you an impetus to do design.
Work in as small a company as possible. Not in a giant company: when I did, and we didn’t have a designer, and I played the role of a designer (and PM too since our PM didn’t help us), I got a bad performance rating that quarter for not writing enough code. That’s not the environment you want to work in. You want to work in one where you’re given credit for your contributions as a whole.
Have a growth mindset, not a fixed mindset. Don’t limit yourself saying “I’m an X, so I can’t do Y.” Instead tell yourself: “I can learn Y, thought it will take some time and some trial and error.”