Dear UI/UX designers, here’s how to test apps you designed

BACK

June 1st, 2022, posted in learning
by Adelina

Your design is done, and your development team coded most of it. As a designer, you have a chance to test it and find any possible issues. It’s best you get to do this in the first stages of testing. You’ll be making sure your design was implemented properly, that you didn’t miss corner cases or certain useful features. 

 

The real question is, how do you look for them? How do you find things you missed while designing? How can you find broken or nonsensical user flows?

 

Your advantage as a designer is that you already know what it’s supposed to look like, and you’ve already envisioned the user flows. What’s left to do is to find possible edge cases, test all possible flows, and find any issues that can make the user experience difficult.

 

So in this article, we’re giving you some technical and less technical tips on how to test your designs once they’ve been coded. 

 

Getting started and staying on top of things.

Picture this: you designed an app in October. Now it’s February, and the app has been coded and is ready to be tested by your team, until it goes to the client or goes live. You’ve been asked to test it, so what do you do? First of all, not everyone has a stellar memory, and don’t beat yourself up if you don’t. Go back to your designs and go through each page, to know what you’re supposed to see.

 

Second of all, talk to your development team. Here are a few things you should ask them:

 

  • Did you change anything about the design intentionally, for technical reasons? For instance, they might have chosen a different icon pack because it worked better. It’s good to know this before you point it out as a bug.
  • Are there any flows that you changed from the design? Whether for technical reasons or due to the client changing their mind, some flows get changed. And it’s best that you keep track of those changes along the way, so you don’t forget them while testing - and report non bugs as bugs.
  • Are there any known bugs? If there are, you won’t end up reporting things twice. They’re most likely working on them already.
  • Are there any pages or features that you took out entirely? Pretty self explanatory.

 

Next, ask your team to give you access to their Jira or ClickUp board (or whatever they use for managing tasks), ask them where you should report bugs and where to find tasks that can be tested by you. Make a Google Doc, Notion file, or whatever you choose, and write down useful data for testing.

 

Here’s what you should write down:

 

  • Login credentials for each user type (if there are multiple)
  • Login credentials for new accounts you make as you test
  • Any credentials for other apps integrated into yours (like Mailtrap, Postman, and so on)
  • Any kind of activation codes or links that are relevant to the app
  • A table that shows what each user type can do (if needed or if you don’t remember yourself)
  • The app’s user stories. You can use these as a reference for what the app can or cannot do.
  • Anything else relevant to your app: for instance, test credit card data (depends on what the development team used)

 

As an additional tip, to keep track of all login credentials, use a password management tool like Dashlane or Keeper.

 

The technical side of testing. Or making the “Inspect” tool your bestie.

Let’s begin with what you’ll definitely be able to test: the UI. When you begin testing, the way everything looks will be the first thing you notice. Especially since you designed it. But you might end up looking at some elements and thinking - that’s the wrong font weight, but what should it actually be? Just telling the developers “the font weight is wrong” isn’t enough. 

 

Here’s where your browser’s Inspect tool comes into place. Right click on the exact element you’re looking at and click “Inspect”. You’ll get a new window that shows all the code that goes into that page. In this window, look for info about the font size, weight, color and line height. These often go together. Here you’ll be able to see exactly what the developers used, and if it fits what you used in your design.

 

 

But how do you check if it matches your design? In Figma, you can select the item in question and go on the Inspect tab from the right-side panel. There, look for the section referring to the characteristic in question. In the screenshot below, I hovered over the font weight, which is what I used as an example.

 

 

As you can see, these two in our example match - and that’s because everything was tested and checked before launch. But if you’re testing an app and it seems to you that the font weight is different than what you used, you can use this method to find out if your hunch is right. In rare cases, you might see that they match, despite looking different to you. In that case, talk to your dev team and check with them.

 

Keep in mind, sometimes you’ll be testing a specific task in an app, and it’ll seem that nothing changed. In those cases, it’s most likely that a pull request or a merge wasn’t fully done. However, before you message your development team, clear your cache. If you still see no changes, contact the devs and they’ll handle it.

 

True Detective, but make it more techy.

Now it’s onto the UX. And since you’re the designer, you should be pretty well-versed in how the app should work. But let’s say you’re not 100% there and you might need some assistance. So here are some of our tips.

 

Make a list of all possible user flows that you’ll need to test. Simply put, write down what kind of goals users might want to achieve in the app. Here’s an example: If you’re testing an e-commerce, start with creating an account, logging in, editing profile info, order placing, looking at product reviews, making a review, checking out your order status, and so on.

 

Once you’ve made a list of everything you have to test, it’s much easier. You have a clear map in mind of what you need to do. And most of all, you can write checks or x’s by each goal/user flows, to keep track of what worked and what didn’t.

 

It’s also a good idea to take screenshots of any issues you see, right as they happen. You probably do that already, so here’s an extra tip: name them by the place you found them and the bug you’re trying to report. For instance, “order_page_shipping_calculated_wrong”. Same applies for screen recordings. If you’re looking for a program that allows you to make both screenshots and screen recordings, we recommend Nimbus. Alternatively, if you’re using a Windows device, you can go old school and press the PrtSc key on your keyboard, open MS Paint and press Ctrl+V.

 

If you’re writing things down already, feel free to write down the bugs you find as well. And later on add them all to your team’s ClickUp or Jira board. It might seem impractical to write them twice, but if you usually write things down on paper, it’ll help you stay on track with the flows you’re testing. Otherwise, you’d be interrupting yourself every time.

 

Alternatively, if you’re opposed to pen & paper and prefer to make everything digitized, make a Sheets document. Create a column for:

 

  • “Goal”, the main thing the user should do
  • “Flow” what they need to do to achieve the goal
  • “Did it work?” where you’d write a yes or no
  • “Device or browser where tested”, in case you test on both mobile & desktop and/or multiple browsers
  • “Attachments” where you can leave links, photos, videos, whatever can help your development team.

 

Figuring out what you’re looking at

Once you’ve passed a project onto your development team, things might change in terms of design and flows. This is why it’s good to keep up with how the project progresses, especially if you know you’ll be part of the testing team.

 

Join weekly meetings like sprint reviews, stay in group chats, and check the project Clickup/Jira board from time to time. Or you can do what we mentioned at the beginning: have a conversation with your team and ask them if they made any big changes, what you should be on the lookout for, what’s missing, and what you’ll need to test (like login credentials). Don’t go in blind - you might end up reporting bugs that aren’t really bugs or looking at incomplete features.

 

There you have it, these are our tips on how to test your own designs, as UI/UX designers. Overall, good communication practices and attention to detail can go a long way. And don’t be afraid to ask questions and report bugs. You’re not giving them “too much” work - you’re helping them improve their work.

 

 

If you’re looking for a development team, designers, testers or all of the above, contact us and let’s see what we can do for you.

 

Banner about UPDIVISION's UI/UX design framework, UFOs


About the author

Adelina

Artsy kid navigating the world of tech for the first time and trying to learn as much as possible about it. My biggest passions are video making, writing, and TV shows I can cry to at 2AM. I also really love IKEA.

See more articles by Adelina