You should be like your client

Do you have a problem with how implement the feature? What it should be? I have it a lot, but I found a solution for this. I must change my mind, but it is not easy. Such as topic says, You should be like your client. The best is when you are a client.

Why?

I often didn't think about UX for my feature. When you have that approach the implementation is easy. Why? Because we implement the easier solution, but what with UX/UD? After one of the trainings I understand that is more important than working full solution. A lot of clients don't use a program, because they don't know how use it. That program can have a lot of features, but when the client doesn't know how use that feature it is only something that bothers you. The problem is bigger. We spend a lot of time for implementing these features, but they are unfriendly. That time we should invest in creating easier and better solutions for our clients.

How?

The topic is very wide, but I have my solutions for it, which I use.

A lot of time I prepare a full use case for the process. This lets me think about missing blocks. Sometimes, when use case is more complicated, I see that we need to change something. How I prepare it? I use an easy strategy. I start by defining the user. Who it be, what it want, why it uses my program? This is the question for me. After the answer I try to be that person and I try to understand what is good or what is bad. Sometimes is hard to define users, but after it I have changed mind about feature. This is a very cool experiment, which I recommend.

The second solutions is being a client. Sometimes I change my role. I try to use my program like I don't know how it works. During this action, I am looking for some tips, I am looking what happened when I click the button. I use that program like I use other programs on my computer. Of course I have a goal on it. I want to create, for example, a new connection to the database. This is very hard to pretend that we don't know how our program works, but practice makes perfect. I see that I do it easier now than on my start.

The third way is for back-end developers. When you have a problem which some feature take a look or imagine how it will look on UI and what happened when it use your feature. This is like writing tests first, but only for clients. A lot of functionality, which we can do in one step should be separated. I think about the wizards, which are very good for the user. For me too, because we feel a authorities, when we can click next or we can analyze what happened when I click next. I don't like automatic install on my computer. I don't like going to pay, before I verify my data. This is good, when we think about back-end with imagine our user interfaces.

If you have a way to be a client of your application, you should do it. The first reason why is that you are feeling more responsibility for your application, because if you do something wrong, you don't do your work. The second reason why is that you are getting a knowledge what clients want and if your features is useful and user friendly. A lot of application let you do it, so I think you should benefit.

Summary

I think the UX/UD topic will be more popular. We have a lot of frameworks for creating the applications, we can do it faster and faster. Now, we have another problem, we need to create application user friendly, we must to fight about clients. I always use a program, which is easy to use. Sometimes, when I get more experience about what I want, I look for other solutions, but for the first time I look for a program which it will carry me by the hand on my journey. I wanted to show you how UX can help you in your development process, but the UX has more benefit than I can show you.

Comments

Popular posts from this blog

Why TDD is bad practice?

How correctly imitate dependencies?

Software development using Angular 5 with Spring Boot