Building satisfying and marketable products with Eleftheria Batsou
===

[00:00:00] Hi there, and welcome to PodRocket. A web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it for free at logrocket. com today. My name is Paul and joined with us is Eleftheria Baciu. She is the community manager over at Crab Nebula and we're going to be going and digging into her latest talk called Beyond Buttons, Crafting Satisfying and Marketable Products, which means we're going to be digging into UI, UX, and like cracking open some nuts and bolts about what make a great user experience.

Welcome to the show Eleftheria.

Hi, I'm really grateful to be here.

Yeah, we're grateful to have you because in your talk, you kind of dig into some details that maybe sometimes we forget about that are still ever so important in our lives. And before we get into some of these rules, we could call them heuristics that you talk about in your talk. How did [00:01:00] you get into UI and UX?

What brought you here?

That's a great question. So, I started with computer science. So my background is I'm a freelance developer and I do a lot of web development. So my first couple of jobs were with front end development and app development. But I was working at startup companies and usually they didn't have a designer or a researcher.

So a lot of times our managers were asking us, the front end developers, to do. The designers work or the researchers work, and I wanted to be good at my job and the final product, and I knew that I'm not so good with design, so I decided to do a master's in design, and I did that master's but While I was doing it, I realized that the problem is not only in the design, but the problem is one step back is in the research is that [00:02:00] a lot of times we don't do research.

We will only code or we will have a design and then we will call, but we don't have the research and we never speak with our final users. So that's how I actually started digging more and more into UX.

Gotcha. So you mentioned you were in the front end space. Yeah. Yeah. Then you get tasked with saying, Hey make us a user interface. And I feel like that's a very common thing that happens the front end people. Oh yeah. , they do the design. But obviously there's a lot more depth to this conversation.

What do you think was one of the missing things? When you were only scoped to front end, that really elevated you to be able to push out good designs later.

I think it was the part that we were missing the research and we were missing the part that we didn't talk with our final users. Sometimes our [00:03:00] managers would Ask us, okay, can you be the user? Can you test the product? Yes, of course, me and my team, we could test the product, but we are also the developers.

We have built this product. So it's not the same for us. And I say that in general, it's not the same for the developers to be also the users. Yes. They may use the product, but because they are attached with it, they cannot be the real users.

Now, everybody listening probably has heard of UI and UX, they're different. We're speaking to a web developer body here on this podcast. But in, in your words, Eleftherio, what is the defining line between these two things? What really makes UX the beast that it is?

So I will start with UI. So I feel that UI is more with what we see, what we tap on or click on, what we browse and this kind of stuff. Whereas UX is how we feel [00:04:00] when we use a product and the whole experience is localized. Physical in our bodies. For example, I may have in my hand, my mobile phone, maybe I am scrolling in an app, if you see me smiling, you will probably think that this is a good app.

Something good is happening, but if you see my face frustrated, or I'm moving a lot with my hands, maybe you will realize, okay, this is not a good app. Something is happening. So yes, this is a big difference, but I also feel that from the user's perspective. There is a big difference, so one thing is what and the other thing is what you feel.

But from the developers and the designers perspective, things can be a little bit more complicated. And I feel that you cannot have UI if you don't have UX. These two things go together.

And I, I can certainly think of things that make a bad user experience. There's so many apps [00:05:00] out today that we're all stressed. If we look at graphic design, it looks good. It's noise, like having things not be perfect. So I'm sure everybody can think of some things they don't want to see in a UX from your perspective, being so deep in this field, what are some things that maybe you don't see people think about that make a bad.

UX that you want to look out for.

Yeah there are a few things, and... Sometimes as developers, we are very attached with our products and we think that everything is super fast or we can do things fast and easily. But it's not like that. For example, give your product, your app, your service, give it to a real user. Or as I like to say, give Your product to someone that you know, they don't like you because they will say the hard truth about your product.

So I don't know give it to your ex partner or your mother in law or something like that and they will [00:06:00] Tell you that the truth about your product So, and to answer your question, some of the things that I see quite often is, for example, people using too many colors in their website. But usually I'm going to their website as a user because I want just to see some information.

I don't want to see all those colors. Maybe they look. Good and cool, but that's not what I want to see when I'm there or a lot of times people are using very small font sizes so I cannot read or the font families and the typographies are With calligraphy or I don't know, they are quite weird. And again, maybe they're beautiful, but the point isn't always to have something beautiful.

The point is to have something that will give the user satisfaction. And if I have heart. time to read something. This will not give me satisfaction. I want [00:07:00] something that it's easy and probably fast.

I remember watching the YouTube video. I'm sure everybody's heard of Gary from the design course on YouTube. He does a lot of videos and he was talking about these websites where you scroll and the whole image changes. And his takeaway from that is it's great. UI, terrible UX. It's you don't know where you are on the page when you're scrolling and stuff, and I think colors can bleed into that too, just from my user perspective, like too many colors.

It's confusing. Do you consider colors more up in that UI category and more in the UX, or is it healthily in both and why?

They could probably be in both, but I feel that the final decision will be the one from the UI designer. And if you have a good UI designer in your team, probably you will not have problems with your website. But I know that a lot of people are building their own products, which is. Really [00:08:00] cool. Or I know that a lot of startups doesn't don't have UI designers.

So in those cases, I would strongly suggest to keep it simple.

And that's a great rule too, because it's a simple rule. Just keep it simple. You didn't come out with a color palette or anything. You just keep it simple. And. In your talk, so you're mentioning like 10 usability heuristics by somebody that's very famous that if you go to some design school, you heard of.

So Jacob Nielsen who is this guy? Why do we want to listen to him?

yeah, so we have two very important people is Jacob Nilsson and Don Norman. These two people manifested ten rules and we are using these ten rules even today. So maybe... Of these two people, like they are extremely important, but maybe the most important of these two is Don Norman because he's an engineer, or at least he used to be an engineer at Apple and.

He's the [00:09:00] pioneer of UX. He's the father of UX. He, as I said, he started as an engineer, but then he studied psychology. And what he did differently than everyone else is that he observed how people interact with technological products. And he was the first one that really observed people up until this point.

Maybe, yes, the engineers were asking, okay, how are you using our products? But they didn't. Observed how real users are testing or are using these products. So, yeah, I think this answers your question.

He did the research.

Yeah,

Yeah. He did the real research. What type of sorry, please go ahead.

He did the research and he observed the people and then he went back at Apple. And now we have Apple as we know it with the design that we know it.

Apple's like a steadfast North Star in [00:10:00] design for a lot of groups. It's like the pinnacle for usability in a lot of scenarios.

Off of his research that Norman did, what are some of the ways that he measured? People's responsiveness and their interactivity with UI that could maybe help shed some light on Changing the way that we as engineers might think about the way we build UI.

I'm not sure how he measured those things, but I know that he created some rules in order to help us, the designers, to create better products, and I also know that a lot of people a lot of researchers

And then we also try to Jacob Nelson and Don Norman, because they are the easiest for us, the developers to put them in real action. For example as we mentioned, we have those. [00:11:00] I know other people they created more than 1, 000 tools. So 1, 000 tools are really a lot. Yeah. I can understand that people don't have the time for that.

So when we have just 10 rules and they are rules that you can have them even to a new product, or even if you already have a product, you can go back and check these rules. So I feel that everyone can benefit from this rules.

Just to name drop do you happen to know one of these 1, 000 rule systems?

I'm sorry, I don't know

them. 

but they're out there

Yeah, they're out there.

We should definitely hop to some of these 10 simple rules right before we do I podcast is brought to you by log rocket So if you're building a website or an app and you want to make it the best it can be not only in the UI In the UX but also in the back end and all the processes that happen in the front end You can spend less time in [00:12:00] your console and debugging and spend more time actually building your app and refining your UI I knew your UX with log rocket so you can use AI powered features to Bring light to other sorts of trends that you might not have noticed.

There's heat maps and all sorts of other great features to really bring the metadata of your app to life. So head over to log rocket. com today and check it out for free. So hopping into. These 10 rules from Norman and Nielsen. What's probably your number one favorite? Maybe it's not the most common one, but the one that spoke to you the most when you got introduced to this method of thought,

Yeah I kinda already talked about it, so I will tell you my favorite, and then I can talk a little bit more about some other rules that I really like. So, my favorite one is the aesthetic and minimal design. So about the minimal design, I think [00:13:00] I already spoke a little bit by saying that You don't have to have too many colors.

You don't have to have some crazy typographies. You can have a minimal design. Sometimes people ask me, Hey I am a designer. I want to show my work. So in my personal website, I will have some animations and stuff like that. Yeah, that's. Cool, but you don't have to have these crazy animations in your personal website.

You can have in your website projects that show these animations and that would be really nice and really interesting because you will also show some real case scenarios. So yeah, I feel that the minimal design is one of my favorite things, but I also have one more thing that I really like and it's about Consistency and standards.

This is the fourth rule, consistency and standards. I've [00:14:00] seen in a lot of products that sometimes the designer or. I don't know, the developer will have an action, for example, delete, which is something very common. Yeah, that's okay. But sometimes they have delete, sometimes they have erase, sometimes they will only have an icon with a bin.

Sometimes they will have another icon when they should have the same icon. And I see those things quite often, which for me... The standard thing would be to have only one word, for example, for delete, use always the same word, delete, or have always the same icon. And sometimes people are updating their apps or their products and they will forget that now they have a new design and they should go back and change everything.

So it's quite common when you're updating your product that will forget. some stuff but try to test your app a lot of times before [00:15:00] you make it live. And the same goes with standards. So if something always work in a certain way, don't try to change it. 97 percent of the users of our users will Use the product in a certain way.

So you don't want to change that thing. For example if you have a Windows machine, copy paste, it works everywhere. It's the same in all of the products and all of the services. Copy paste is always the same. You don't want to change some things that the users know how to use them. And they are fast with them and it's easy for them.

So this is also one of my favorite rules.

what number rule is the minimalism or taking things out

It's the seventh rule. Sorry, not, sorry, not sorry, not the 7th, it's the 8th rule, the 8th.

Eighth. Okay, so we got number four and number eight.[00:16:00] Let's bring it back to the start. What's rule number one? What did they think was rule number one?

Rule number 1 is visibility of system status, and this is about showing to the users the things that they are supposed to see. So, again, I can give you an example. When we take out our phones from our pockets the first thing like the screen will light. Okay, now in that screen we can see the date, the time, some notifications, maybe we can see the weather and this type of things.

Now imagine someone taking all those things away from you. You would feel naked, right? You wouldn't have anything. Now this shows us two things. The first one is that we need the important things. For example, the time, the notifications are quite important, but we don't need everything. Maybe in my phone, I have 20, 30 apps.

I don't need to see [00:17:00] everything at the same time. When I actually want something, I will. Scroll, I don't know, I will tap and I will go in that particular app. So I feel again that this is quite important because sometimes people, they are very passionate about their products, which again is really cool, but because they are very passionate about it, they will try to show everything at once.

So they will try to put everything at the front page, which is. Not that cool. Let your users browse your app. If they are really interested about your product, they will have the time to dig into it.

Do you find that the most productive way for people to find that happy medium about everything you want to show versus everything you should show? Does that come from, in your experience, like people developing less and then incrementally adding more? Or does it come from them putting everything they think should be there?

And then talking to people and telling them what's wrong [00:18:00] and taking it out.

Yeah, I think that they should start from having fewer things. And this goes also because Now, maybe I'm getting into details, but I'm quite confident that most people already know that first we should start with with a phone's design and then moving to a web's design. So a browser's design, something like that.

So when we are starting from the phone's design from a mobile design, then we have less information and that's a good thing. So you should focus first on having less information and then maybe we can have a bit more stuff.

That is the most less information, the phone and starting from as little as possible. You must really have to go through this mental exercise of thinking about every pixel that you're utilizing. What's rule number two?

So rule number two is match between the system and the real world and [00:19:00] this goes back. It all started with the iconography design. For example we have in our products a compass, a folder or the clock or the calendar. This is because people, when we started using technological products, they didn't know how to name those things or they didn't know how to have I don't know, an image about that, so they thought, okay, what's the easiest way?

We can show them as they are in the real world, like a compass is a compass, so I will have that icon. Now, of course, people know how to use products, but if you're having something that you feel people may not recognize or if you have something that It's difficult to describe it, but there is in the real world.

Maybe it's cool to have an icon. So again, I feel that this is a good rule.

And what about rule number three? 

So rule number three is [00:20:00] user control and freedom. This is about. Always giving your users a way to go back or do something again, or as I like to call it, you should always have an emergency exit button. This can be a button. This can be a refresh page. This. Can be a redo action, something like that, because either we want to or not, our users will make mistakes or errors.

And that's okay. Maybe they are in a hurry. Maybe they didn't treat something well. So you should always provide them a way to go back, redo something, exit from something. Yeah, I think that's it.

Nothing is worse than being on a website and clicking in the upper left logo and having it do nothing like that. That has driven me crazy sometimes. So we got rule number four already out of the way. What is rule number five?

Rule number [00:21:00] five is error prevention. So as I mentioned earlier, our users will make mistakes, will make errors, either we want to or not. Now there are two kinds of errors. We have the sleeps and the mistakes. The slips, it's the easiest part because it means that yes, our users will make mistakes, but as we mentioned in rule number three, we will have the emergency exit so people can go back, redo something, that's okay.

Now, the problem is with the actual mistakes, because this means that we as developers or researchers, we didn't do our research. So, well, and that's why people don't understand how they should use our products and that's why they are doing mistakes and this is a bit harder to fix it, but if you notice that in your product, then you should go back with your team, discuss again, how you can fix that.

[00:22:00] And this means, as I said, that the problem is that developers or the researchers and not the users.

Rule number six is recognition rather than recall. We have, again, two types of memory. One is recognition and one is recall. We always want to have the recognition. Recognition is when we see something and we don't really have to think about it. It's It is just in our mind. And in websites, for example, we can easily do that.

If we have, if we want our users to search for something, maybe we can give them some options, maybe we can show them some images, maybe we can have a menu. So instead of. Type in something they can just click on the menu or in the drop down list or something like that. So we should always aim to that, whereas recall is when they actually have to think about something.

If we ask them [00:23:00] the year that something big happened, maybe they don't remember the year, but if we give them some options, which is recognition, it will be much easier for them to give us the correct answer.

You want to? Would it be fair to say you want to think as much as possible for the customer?

Yes, 

and that's a good way to move forward? Okay. 

this is the role of the designer and the developer. They should think so the user don't have to think they don't, they doesn't have to think.

And we got it. Rule eight already, which is arguably one of your favorite rules. What about rule number nine?

So rule number nine is help users recognize, diagnose and recover from errors. And I think I can explain that a little bit better with an example. So, let's say that we have a product and in that product, we accept images. So, and the user can upload an image. [00:24:00] Now, the user maybe will upload a PNG image, but our system only accepts JPEG images.

So, it will be cool to say, hey, we cannot accept PNG, we only accept that type of images. So, this is a recognition and this is a way also to recover from an error, because we give... the solution. Now there is one more step that maybe we can, we could have in that upload field, maybe we could also have that, we accept this type of images.

So the user won't even do that mistake with uploading an image that we can't accept.

It's that immediate feedback

right? Okay, gotcha. And before we just hop into a few commentaries about these rules, what is number 10, the last one on the list?

Number ten is help and documentation. We should always strive to have the perfect product, but of [00:25:00] course that's not always doable. So we should have some kind of help and documentation. When I say that, sometimes people imagine of a big document with a lot of text, but that's not what I mean. We should not be focusing on the important things on our products, so we should have some text, and that text shouldn't be very technical, even if we have a technical product, because we hope that our product will be used by everyone, so we should use simple language with not very weird terms, and because we, a lot of times our product is for everyone, so Not for native English speakers.

So again, we should strive to have a simple language and there are some services like I don't know, Trello, Coursera, they're doing a really nice job. They don't have a big documentation. [00:26:00] They just have some pop ups and people can understand how to use them. Yeah. I think this is also a really nice rule to, to have a good.

documentation and not big documentation. So you have to be very specific. Yeah.

People don't want to read a lot of stuff. They just want to get done what they want to get done. So I, and I know you mean in Trello, they have a great walkthrough, 

Yeah. 

you're like, wow, I know how to use it all. So everything that we just talked about in your experience and successful teams that come out with something really great, does this happen in the ideation phase in a room with UI and UX people?

Does it happen around the big table where. The front end back end people are there. Does it happen throughout with customer use case studies? Like how does this get practiced effectively in your experience?

I think that it should start from the UX part or the [00:27:00] UX department, but of course, the UX researchers, they are not alone. They are surrounded with UI designers and later with developers. Sometimes people will say, but okay, I am in a small company, so my company cannot invest that much on the UX part. And I get that, but it's actually quite the opposite.

They should focus more on UX because it's the first phase. So if you have a good UX, then it's much more likely that you will have a good product. And even if you have the perfect code and everything is very well optimized, the user will not check your code. The user will most probably check the UX.

Which is the satisfaction and how easy it's the product and how fast they can do stuff. They will definitely not look at your code.

Yeah. Imagine what a world that [00:28:00] would be if everything was treated like open source. That arguably Linux is a better operating system, but we have other people triumphing over it because it has just better usability. Everybody just wants to create a doc, right? Or PowerPoint and write what they want to write.

When do you think is the best time to start actually prototyping that code? That people won't read right behind

Yeah, I think as soon as possible. But of course after you have done your research. So after everything is done. Then you should start prototyping. And of course much later, you should start coding. And I have another point here that again, sometimes people will say, but okay, I don't have the money I work at the startup company, so I cannot prototype too much.

And I cannot test with users. No, you still can do that, even if you [00:29:00] don't know how to use Figma, even if you don't know how to use Sketch. Take some pen and paper. Do something and then go to the user and ask them like if I If you see this piece of paper and if there are two buttons, will you click this or that and why?

So this is a very simple form of testing but it's testing with no money and with real users Which is exactly what you're asking or it's exactly what your managers will tell you can't do but you can a piece of paper Is free You can ask the user and that's it.

Well, Eleutheria, we are running up on time here. Before we go into more stuff about you to close out. I have one last question, which is. Do you find that, in your opinion, because this is like a computer centric field, we're developer centric, that UI in every case, or generally, is thrown under the rug [00:30:00] a little bit, and that we need a global reprioritization of this stuff?

Do you feel that way?

Ah, to be honest, yeah, I feel that and especially now that we have the rise of AI, sometimes we feel that things are easy and we don't have to think about that because we have an AI that will do stuff for us, but in reality it's not like that and I really believe that we should go a step back and be a little bit more careful with our UI designs and our research.

Yeah, I really appreciate the AI comment. Just makes it easier to gloss over some stuff. So, definitely, yeah, the human element still remains the same. If people wanted to find more about your research. And the in depth writings and talks that you're doing into this ever changing field. Where can they find you?

I'm quite active on Twitter, they can find me at Batu Elef [00:31:00] or they can find me on my YouTube channel which is my full name Eleftheria Batu and Yeah, I'm really open if some of our listeners have questions or anything, they can always find me on Twitter or YouTube and I will happily try to help them.

Awesome. Eleuterija, thank you so much for your time. It's been a great conversation digging into some of the less immediately code facing elements that make our apps great.

Thank you very much. Yeah, it was amazing being here.