Some people are interested to find out how does it feel to be a UX Designer. Not because UX Designer is such a special role. But because people are curious, at least some of them!
I mean, I am also curious how is it like to be a biochemist, an astronaut, or a salesperson.
In this article, I am letting you take a full look into my life as a UX Designer! I will be describing what I do every day, what kind of stuff I deal with, what kind of contents I am consuming, what is usually the thought process in solving some problems, the full detail!
A little bit about me : I work in an app/ website development agency for 1 year now. Before that, I also have worked on few freelance works for different clients. I have also worked as an in-house Graphic/UI/UX Designer for 1 year as well. So in total, I have worked for 2 years as a UX Designer.
Just a disclaimer, this might not be what usually UX Designer does. Each and every person has a different way in life and every company has different SOP. So this is in no way, a guideline.
My typical day :
Research and look at many websites/ web apps/mobile apps
Screenshot UIs
Accessing the staging/dev version of the product
Reading into the requirements
Reading articles/papers about the industry of the product
Writing/Drawing on papers/whiteboards
Making wireframes on Sketch or Balsamiq
Revising design on Sketch
Writing documents
Organizing the Google Drive folder
Organizing the Marvel
Check with the copywriter or make UX copy myself
Talking to other designers and the developers
Presenting idea or design to the PM or my company's CEO, sometimes the client
Asking questions, all the time!
..and thinking.
So here is my rough schedule, they are not accurate and vary day to day :
8:00 Woke up (OK sometimes I snoozed the alarm for 10mins lol)
9:20 Start going to the workplace. I usually take public transport so it takes about 30mins total-including waiting, transporting, and walking.
9:50 Reach the office, immediately open Slack to check for any messages.
-I then open the company email inbox and Basecamp right away.
-Open the design file and continue whatever I am doing the working day before.
11:00 there is a daily review/stand up on the project I am working on at the moment, but generally, most projects will have standup around this time (before lunchtime). At the moment and with the project I worked on before, I usually present the design to my other team members such as the PM, the developers, and other designers.
12:00 Usually the standup is done at this time. It really depends, sometimes when there are a lot of designs to review, then it might take a long time. When a product's design is done and in development, then maybe designers don't even have to attend this meeting. So once the meeting's done, I would start working on the required changes.
13:00 LUNCHTIME! I usually go and have lunch with my co-workers. Sometimes I still go alone because I have some stuff to do or I just feel like having alone time 😬
14:00 Lunchtime is over so I'm back at the office, continue whatever I'm doing earlier.
19:00 It's time to go home! I usually go home at this time, but it really depends on the time I got into the office. If I came in at 9:30 then I would go home around 18:30. It also depends on the work I am doing. If they are heavy work that really requires a lot of time, then I would stay back and continue work.
19:30 I arrived at the bus stop to go home
20:00 usually I reached home at this time
22:00 time to sleep!
That is my rough schedule. Now let's look into what happens between 9:50 to 19:00!
Here is what I do when there is a new project :
Project kick-off meeting, usually this is the time I got the brief.
Learn and do research about the client, the project I am going to do, and overall about the industry. If the client is from the F&B industry, then I research the F&B industry, what's their competitor, their users, simple as that!
It also depends if the client requires UI work or UI and UX work. Some clients might have the UX ready but they just want us to make it into reality by making good UI. But nevertheless, we still have to start from the wireframe and describe the user journey as clearly as possible. Any high level and major scenario, we have to draw it in the wireframe. The wireframe also has to be as clear as possible as the client usually has to check if the contents make sense. I'll further talk about it in my next post on how to create a wireframe!
So once the wireframe is completed and confirmed, we can now move on to the UI. For the UI, I would come up with different concepts and present them to the client. It usually takes many rounds of presentation to get it right unless the client is very clear on what they want.
Based on the approved concept, I then develop the design system. Some clients don't have branding yet, so I do a quick branding, then only proceed to the design system. When a client has a strong branding guideline, it is easier usually to make the design system.
When the design system is done, then we only create the screens after that. To do that, I have to refer to the approved wireframe including the contents. While creating these screens, I have to take note of some components, padding, margins, and the mechanism in accomplishing certain tasks and then put it into the design system.
Once all design seems to be all good, the developers can start. But usually, the developers will start even before the design is done, so at least we got all the contents there, the rest is just adjusting UI.
While developers are developing the product, it is important to keep track of the product quality as well. So I would check the UI and usability of each function and then list them in a document or a designated platform (depends on the project).
Also while the development is in process, some UI components might take a long time to develop, to speed up the process I would change the design to make it easier to develop but still does the job. So I would research documentation on how other people create certain components, such as a dropdown for example, and then communicate with the developer(s) if this is a preferred solution for them. If they approved, then I will proceed on change the design and update the Marvel. It's important to update the design because this will affect the QA later on.
At the same time, you might have to export assets for the product such as icons, images, fonts, etc.
Occasionally we will present the development update to the client and get their feedback. Sometimes the feedback is UI and UX wise, so the design should be updated as well. Sometimes the feedback is about the usability (example: when I click the link, nothing happens). The feedback really can be anything. It is also possible that a client does not like the branding or would like a complete change of the whole UI concept.
Usually, towards the later part of the project, the QA team will start testing the product. The goal is to identify even the smallest issue and fixes them. It is not ideal for our clients (and worse, users!) to find issues in the product unless the issue is something much deeper that only user can feel it. Sometimes QA team is not the user, although they will act as similar to the user as much as possible.
At this time also, we start to do the User Acceptance Test (UAT), not sure what does this called in other companies. Basically we have several documents describing all the user journeys and clients, as well as the QA team, has to formally test and approve it. So when something is not approved, we can call the UAT to be failed. Here, there is no negotiation or reasoning. If our user can't accomplish a task for whatever reason, they mark it as failed, so we can go back the next time and do it again. Ideally, developers or PM can't negotiate and say "ah this take some time to fix, please mark it as a pass-first!" or "I have changed the code, this should work!". These kinds of conversations might happen in feedback sessions, but not in UAT. As a UX Designer, UAT can be a really good way to know how your user will interact in real life.
So when UAT is done, then the project is handed over to the client! Sometimes, we can publish the site live and do some beta testing. When the project is not meant for the public (say, some engineers, or admins) to use, we can release this earlier compared to when a product is meant for public use.
So that is roughly the process of completing a project. It can also differ from every client and every product. Some clients might even have a much more complicated SOP for product testing, etc. For some clients, we are not allowed to speak directly to so this might cost some time in getting feedback. If you work as in-house designer, the process can be different as well. So, yeah the process is very contextual!
What happens after feedbacks?
Usually, the feedback is about "this solution does not seem to work" or "this type of UI does not look good". I mean we are doing UI and UX, so this is why the feedback is around that. Which, in my opinion, is pretty straightforward so I can continue with either of these 2 options : (a) to research more and come up with a better mechanism, or (b) research more and come up with better looking UI, and then, later on, talk to other designers or other team members.
So as you can see, research is the big key in solving problems here. I used to create solutions without doing research and it is a really bad move to do so because most of the time, your opinion will be quickly dismissed, unless if you unknowingly create the right solution that most other big platforms do it. But even if you do, other people might not notice how things are being done usually. So it is still a good idea to present your solution with concrete data to back it up.
The problem usually arises when after doing research, it turns out that the problem requires heavily customized solutions that rarely found in web apps or mobile apps. This is a problem because it is unclear if our solution might work and it requires a lot of time and money to test and perfect it. This is why, most of the time, I and my teammates refer to big companies' products, see how they did it, and try not to reinvent the wheel.
Usually reinventing the wheel might work on big companies with big funding and has the time, people, and energy to do so.
I never expect my solution proposal to be accepted in the first round. So it is important for me to manage my expectation because the users' needs might be different. I might propose something completely out of the topic, unknowingly.
Take feedback as something valuable. I think no feedback is worse than negative feedback!
Also, in the process of doing the project, I have to be very organized. It is easy to be disorganized, it is also likely possible to forgot where things are or get confused. So I am glad that in the process of design and development, we are actually required to be organized. I learned in this company to have a naming system for everything. The assets, the images, the file, the folder name, even every screen in the wireframe (although one could argue that it's just a wireframe), it is still important to have them named according to the system.
Well, that's all, folks!
This is my life and my routine as a UX Designer! I hope whatever I wrote here can help you better in shaping your career and to know better what to do.
If you have more questions about being a UX Designer, just email me or chat with me right here in this website. I'd be more than happy to answer!
Leni
Comments