Tight

Emojiscout: Designing the user experience

First things first: how will our app look and function? We need to get some sense of this before writing the first line of code.

Gjermund.65cc9064966e3ea02a8b631e147fa639Gjermund, designer
in Design & Emojiscout

Our initial design phase always focus on the overall user experience (UX). A phase where we get a shared sense of how we'll be using the app. The way it looks and functions, but in a rough state, where we don't get hung up in details. We want results quickly to get some development going, so both designer and developer can keep working at the same time.

Where do we start? To avoid being stuck, I always begin with what I know so far:

  • Today’s size of emojis are frustratingly small
  • There is no search in the current iOS experience (iOS 13)
  • Some sensible categories would be nice

We'll need a little more detail than this.

I fire up Figma and throw some decent sized emojis in there, as well as a search field. I show these to Anders (dev) at first opportunity, to get both of our brains going.

Immediately, we both get the feeling that this would be a neat tool. A great start.

We move forward with the grid concept, because:

  • It gathers a lot of emojis in one place
  • The list design offers too much real estate to label, leaving only a few emojis in the list
  • The “one result” approach is likely to fail. For instance: How would we choose between a red and green apple?

Even though the label didn't feel right, we still wanted to include the emoji name. That'll be handy to learn names down the line, and could prove useful for seeing the connection between search term and result. So we try to squeeze that in somehow.

What else? We need to include a copy feature, to bring emojis out of the app and into your messages. Some kind of alert should do.

As soon as we feel like it all makes sense, we have enough to start coding 🚀

On a typical project, we spend a few hours up to a couple of days for this very first phase, depending on the complexity and the amount of explorations. I usually force myself to "reset" and try some wildly different approaches, just to feel like I've challenged myself sufficiently and went out of my comfort zone. Sometimes this yields useful results, and we end up borrowing stuff from the crazier concepts. Other times it just reinforces your belief in the existing concept.

This is a fairly slim app, and our concept felt promising from the start, so let's just proceed! Anders rolls up his sleeves to write some code, and I go ahead fleshing out the sketches in more detail.

More on this soon!