Written by Jotham Oakley
Nov 18, 2015

Three UX/UI Beginner Tips

Here are three things I wish I’d known when I first started out in UX/UI design

UX/UI time travel

If I were to go back in time I’d most likely either indulge my childhood self and enter into the Jurassic age (were T-Rex’s arms really that small?) or I’d head back to the 1970s and embrace my inner glam rocker, sequins and all.

However, probably the best use of my new time travelling gift would be to head back a year and spend a day tutoring myself on UX/UI design.

You see, when I first started here at Brightec I had little experience in mobile design. The majority of my previous design work was in print. I’d made the occasional foray into designing for web but the art of mobile app design was quite unfamiliar to me.

After a year in the saddle I’d relish the opportunity to give me old self a few UX tips, but alas my fluxcapacitor is kaput. So instead, I’ll have to pass on this info to you.

I clearly can’t cover everything in one blog post, but here’s three things I wish I’d known when I started out in UX/UI design.

1. States

In many design situations, there only needs to be one version of your design.

Printed design material doesn’t need to change once its been printed, a book can’t change the contents page after it’s published, and an album cover will always have the same lyrics in it once it’s released.

Mobile design must adapt

Mobile design needs to adapt to a seemingly infinite amount of different scenarios.

Sure you can come up with the perfect visual, but in reality the real world isn’t perfect. What happens to your screen when things go wrong? 

What if the phone has a poor connection and it takes ages to load your content? Do you leave the user hanging or help them to feel like it’ll be worth the wait?

What if the user makes a mistake entering their details in your contact form? Does your form simply not work or do you gently point them to where they went wrong and kindly explain how to get it right? 

What if the user who fills out your perfectly designed profile screen isn’t actually called ‘Joe Bloggs’ and he doesn’t enter the words ‘Lorem ipsum’ as his description? What a shame that James Bloggs (Joe’s younger brother) can’t fit his name in the 10 character space you’ve allowed. 

And so on and so on…

"mobile design needs to adapt to a seemingly infinite amount of different scenarios"

Don't be overwhelmed

I’d not thought about this until I started here, and at first it can be overwhelming, but it doesn’t need to be. 

Once you’re aware of the concept of states it actually opens up a whole realm of ways you can boost your apps overall design impact. Scott Hurff puts it much better in this must read article.

A checklist

To help any budding UXers, here’s our current questionnaire/checklist that we ask ourselves when we begin to solve a design at Brightec. Feel free to use it if you find it helpful.

2. Device size variation

Building on the last point, one of the most obvious things I’ve had to learn is that whenever you’re designing an app, it’s almost never going to be seen on one single type of device.

Most apps have to work on all iPhone devices and all Android devices, sometimes with tablets and smartwatches thrown in the mix, just to spice it up a bit. 

It’s a pretty simple point really, not everyone has the latest phone model. It’s pretty important that your design looks just as great to an iPhone 4 user, as it does to an iPhone 6 Plus user. That’s a tasty little challenge in itself. 

Apple's size class concept

Beware of falling into the trap of stopping there. Whilst it is important to acknowledge all these different devices, (I’m really talking about the iOS world now) it is actually more useful that we don’t label our designs as ‘an iPhone 5 design’ or ‘an iPhone 6 design’.

Instead it will be much more helpful for the developers who will build the design, is if we start using Apple’s size class concept. Read about size classes here.

Rather than making a version of the design for each device, make a version for each size class. It’s less design work and makes more sense in code.

Getting your head around that will be a big help to design and development teams alike. 

3. Exporting assets

This sounds pretty basic, but when I started I didn’t have a clue what I was doing as I gave my design elements to the development team. So here’s a quick guide to how we currently export assets at Brightec.

Our method

Firstly, I’ll ensure that the assets are named correctly for iOS & Android. We currently use; ‘SettingsIcon’ for iOS and ‘ic_settingsicon’ for Android. It is not helpful for anyone to name your music streaming app’s play icon ‘Triangle copy 4.png’

After finishing and naming my icons in Sketch, I’ll export all iOS assets at; 1x, @2x & @3x sizes, using the built in export feature of Sketch.

If the elements are intended for Android, I use this handy Sketch plugin to instantly give me the; mdpi, hdpi, xhdpi, xxhdpi & xxxhdpi versions that the developers need. 

Assuming all your icons are vectors, this method is incredible at speeding up your flow. 

In conclusion

I hope these three simple tips are useful for new or budding UX/UI designers out there. 

Read more of our articles relating to app design here.

/ Design