Usable had an open mic
and we talked about a lot of things
For our June meetup, we decided to open it up to members of the community to talk about burning issues. The conversation started with the greatly debated question of “should designers code?” which moved into specialization versus generalization, job titles and role descriptions, and what is required of UI designers and UX designers (especially) in the Nigerian ecosystem.
Someone wanted to know the difference between UI/UX designers and UI/UX developers (an actual job posting). Answer: there is no such thing as a UI/UX developer.
update: apparently, there is such a thing as a UX Developer.
We also talked about selling yourself as a designer, selling the importance of design to organisations, and why designers should document their work process. We talked about user research. A major concern in this area was on how to recruit users for research. Other question were on how to carry out research, how many testers you need for a usability test, whether to give incentives or not, how to sift user feedback (how to decide what to use and what to ignore).
Should designers code?
This would have gone on for the whole meetup, but we had to stem the conversation at a point. Some people thought that designers should absolutely learn how to code (HTML and CSS) while others were of the opinion that they had no business with it.
Team designers-should-learn-how-to-code said that it helped with their value in the Nigerian market where most organisations can’t afford to or just don’t want to pay two people to do the two jobs. Also, an understanding of code will help them design products that can actually be coded by front end developers. They don’t necessarily have to do the actual coding, they should just understand what can be achieved with code.
People against the motion hammered on specialization, 10,000 hours of practice etc etc. UI design, UX design, graphic design, and front end development require different skills and involve different processes, so organisations should not expect one person to possess all those skills.
P.s. I personally think that “jack of all trades, master of none” is not true, and the correct thing should be “jack of all trades, master of one”. Or two. Or three.
Job titles and role descriptions
If you’re in any of the design communities, you’re probably familiar with job postings with titles such as UI/UX designer, with requirements including HTML, CSS, Javascript etc. There was a question of: “is it that people don’t understand that these are different jobs?” or “is it that they know that they’re different but don’t want to or can’t afford to pay two different people to do them?”
Someone said that the problem is that designers haven’t been able to sell themselves (not individually, but as a whole) and demonstrate their importance in the way that developers have. Which is why organisations are more willing to spend a lot of money to recruit developers, but want one person to occupy three roles as long as there’s designer at the end of the job title.
We also talked about packaging. So for example, It is not enough to say that creating a logo is an expensive and time intensive process, you must show it too. The way you present your work can influence people’s perception of the worth of your work.
User research
The first and most important thing to note is that you shouldn’t do research for research sake. Not just to say “oh, we do user research here”. It is important to identify research goals and objectives before you begin. What do you want to find out from carrying out this research? What is the best method to get what you want to know? How many people do you need to talk to or to test your product?
In recruiting participants, it is important to schedule tests, interviews, and focus groups around times that are convenient for them. Also, you don’t have to always wait for the users to come to you. You can go to them where they are.
There is the concern that giving incentives will make people give you only positive feedback because of the rule of reciprocity. It is important to let research participants know that you value their honest feedback and the reward/gift/incentive isn’t dependent on the type of feedback they give.
Regarding number of users, the rule of thumb is 5 users for usability tests. When it comes to surveys, you’d need a much larger sample size.
Concerning sifting feedback, once you’ve identified your research purpose, you’ll know how to prioritize feedback. Also, during the course of your research, you may stumble on things that you didn’t set out to find. In these cases, you should still keep your focus on your original purpose, but watch out for these new findings and think of how to deal with them at a later time. This might give you a new direction for further research.
If you want to be notified of the next meetup, subscribe to our newsletter here.
