Design your first app

Lately, I had to design a new app from the scratch. In the past I’ve conducted some UX evaluations of existing applications and websites, so I’m not completely green - but designing something from the very beginning? It was definitely a challenging task.

As it was a totally new field for me, I dug through many, many websites about design and UX (like Smashed), and tried to learn as much as possible. However, the proof of the pudding is in the eating. Not everything I’ve learned was applicable in my case, and I’ve encountered some issues which were not mentioned or intentionally omitted as something obvious. That’s why I’ve written down some (very general!) rules which helped me in the process.


Design is more thinking than doing

https://media.giphy.com/media/MsWnkCVSXz73i/giphy.gif

It might surprise you, but you’ll spend more time thinking about an app or a website than actually designing it. First, you have to identify the main problem, and then smaller ones - what’s causing them? Why they occur? When? How often? Then you have to think about solutions. What’s the best approach? Should it solve one problem at a time, or few or all of them at once? How your competitors solved them? How much time you have - do you have to use an already existing solution, or can you design something totally new?

And when you finally sit at your desk with a pencil and a sheet of paper in your hand you realize that 4 of 5 days you had, have already passed. But don’t panic - it’s better to thoroughly plan your design than to have to start over and over again.

‘Paper (or whiteboard), fool!’

https://media.giphy.com/media/rf7ZeWf5GxXKU/giphy.gif

Sketch, sketch, and sketch, all the time. And then sketch some more. Try to visualize even the most ridiculous idea that popped in your mind. Why, you ask? Usually I did that to convince myself that this idea is not the best one - once it’s ‘alive’ it’s easier to decide NOT to pursue this particular solution. But from time to time, something what I have already labelled as ‘nah, stupid’ in my mind turns out to be something brilliant.

It’s better to sacrifice few more post-its than the best solution.

Ask for opinions & validate your ideas

https://media.giphy.com/media/SoQAR4a0mIj4Y/giphy.gif

And because we are on sketching stage: ‘Wow, it looks awesome! That’s how it MUST be done!’ - know that feeling when you have drawn something? Me too. I also know the feeling when I show my idea to my colleague and hear ‘Erm… Sorry, but it doesn’t make any sense’.

And you have to get used to that. All the connections in your project might be obvious for you, but not necessarily for the user. It’s called User Experience (not Designer Experience) for a reason - so it’s a good idea to think over solutions that trouble others. Don’t marry the idea, this approach may lead you to an UX minefield.

Solve the problem, don’t focus on being pixel-perfect

https://media.giphy.com/media/JWF7fOo3XyLgA/giphy.gif

It’s your design. You want it to be as close to perfection as possible. You will spend a massive amount of time to create and deliver an ideal, smooth, beautiful app (or website). But here comes the hard truth: No one cares - your users won’t pause when using your app just to admire this one particular screen. It is mostly about functionality. Users use your app/website to do something and achieve certain goals in the shortest time possible requiring minimal effort. It’s ok if your app shines among others - but focus on the functionality first. Nobody will use your product just because this one perfectly designed screen.

Be technical literate

https://media.giphy.com/media/srbiWWa0VW2YM/giphy.gif

It’s an ambiguous issue - at least it was at the beginning. ‘Is it really an advantage?’, I’ve asked myself. As a developer I have my habits, likes, dislikes, and so on, and that might shape the flow in some way. But on the other hand I know how to translate the design to code, and it’s a big plus. How not to be biased against certain solutions and find some sort of equilibrium?

Sadly there is no straightforward strategy and you have to find a way of doing things that suits you. For me it is as follows:

  1. When sketching, I have my developer’s knowledge somewhere in the back of my mind but I don’t let it tame my imagination and flow.
  2. Later, when some screens are finished, I let them ‘cool’ for some time and switch to other tasks I have to do (or just take a short break).
  3. After that I evaluate them from the coder’s perspective to check if the flow makes sense or if it can be improved in some way (usually it can, and it should -- even if it means that I have to re-do all of them).

And I repeat this cycle until I feel that the job is done.

Clear your mind from time to time & just relax

https://media.giphy.com/media/l3E6MlCQSxa7HZY0E/giphy.gif

Being constantly focused on a limited set of things is extremely tiring. And a tired mind tends to zone out. It might lead to skipping over some issues and solutions that are crucial for your project. That’s why you should take a break from time to time even if you don’t feel that you need that. Go for a walk, make a dinner with your friends, play table football with your colleagues, or take a nap (you can also check our post how to relax at work). You will soon see that you are more committed and have more energy to work!


Bear in mind that these are only suggestions - something that works for me. It took me some time to figure out how I should work to do it efficiently and be satisfied with it. Try to find your own optimal way to work and do not be discouraged by any setbacks you will encounter!

Photo from Unsplash.com by William Iven

Gifs from Giphy.com