UI/UX Process—How I Get Things Done
Things are not that quick and straightaway pretty like those Daily UI challenge posts you see on Dribbble. But yeah, you can refer to Dribbble to seek inspirations; we all do that to feed our brains tho. My solid principle: beautiful UI mobile app, SaaS or even web design is a disgrace without a beautiful seamless UX.
Currently, I am working for a digital agency, where the project's pace is a bit different from working in-house (I also got 2 years of experience working in-house, okay!). The clients usually don't have the idea of a proper UI/UX process and they want to achieve product completion fast, but for sure they demand some kind of standard they want to grasp. To comply with this, things are quite rushed most of the time. We work in an agile environment where the beginning of project kick-off, sprints, beta phase until the project launch feels like a challenging triathlon, but more enjoyable and fulfilling than the real one.
IRL, I'm known as an impulsive and spontaneous person, but I am really a different person while working something out.
UI/UX process might vary depends on the organization, company or personal preferences. Nevertheless, here is my personal system/process of getting a product design done.
1. Product Research
This is 80% UX, 20% UI. At this phase, I need to reimagine myself as a product owner and the product user. What the product is about, how the system works, how their API looks like, market study... usually, this is the time that I need to know a lot; so I will ask a lot until I can understand what this product is about and how it works. Don't forget to do the SWOT analysis ah! I also need to know what the requirements, what the client wants on this product (most of the time, they know what they want but not what they need). And record the heck out of it, for reference.
Being inarticulate, I don't think I will write long stuff here, because this is the basic thing people should do. Key activities here; Product background study – what, why, when, who, how, Market research – competitor, user, SWOT analysis. Requirement listing – remember requirements ≠ features.
2. User Journey Mapping
This is 70% UX, 30% UI. When I got all the details about the requirements and features the client wants, it's time to list them down–collaboratively in Google Docs. I usually will start listing out requirements and features based on the sections. Actually, writing is hard, lemme explain thru images.
And next, this is the fancy part, mapping the UJM. Grabbing my pen/marker guys, I need to do some hands-on job. Let's map the screens of the user story!
Key activities here; Convert requirements and features into user stories – Develop UJM, screen mappings from the user stories.
3. Lo-fi Wireframing / Prototyping
This is 50% UX, 50% UI. And also my favorite part. I can spend hours doing this while listening to lo-fi chill pop songs. The faster I do this, and the faster I can get project manager and devs response to my wireframed flows, the quicker the project manager can show to the project owner for sign-off. Then, I'll have more time focussing on the details when the hi-fi screens available later on.
After 5 years of working in this industry, I noticed that this part is basically what stakeholders anticipate; like looking at their idea slowly visualized into reality. Sometimes, contemplating which UI/UX to be used in a screen can be quite difficult. When this happens, I will make 2 screens with different interfaces and just ask others what is their opinion (during the design workshop).
Once I've finished wireframing the crucial screens that allow the task to be completed by the future user, we will make a design workshop, this workshop will be attended by fellow designers, PM and devs. Sometimes, the big boss and the client also will join.
After the workshop is done, and I get all the feedbacks, critics and useful opinions, I will then amend the screens that needed UI/UX fine-tuning. After that, I will start to do the most hassle part—Compiling all the wireframes together into its flow.
What I like about doing mobile apps, the overall wireframe compilations won't be more than 50 flows. But, if you are designing the UI/UX flow for SaaS of software, the flows can be more than 100 and they're normally freaking a lot!
Key activities here; Start thinking about how the app/SaaS would behave, function and feel like. To convey your ideas, do a lot of wireframe sketches and make it into flows, and learn the soft-skill on how to communicate and present your wireframes.
4. Hi-fi Wireframing / Interactive Prototyping
90% UI, 10% implementing the UX. This is actually what you guys will see in Dribbble and Pinterest—Probably the epitome of the term 'App Design'. During this process, I will always remind myself, to not become enslaved by the design, because it belongs to the product owner. Nevertheless, try your best to fight for it, when you love it.
Working in this agency, I need to do all sorts of UI/UX works although my original core and passion were solemnly dedicated to mobile app design – specifically Android app. But it's okay, every project teaches me something and upgrades me to a higher level.
The next thing that I'll do is upload and compile all the screens to be viewed online by the stakeholders. By right, the clients can see the screens and give comments on them.
With the correct prototyping tool, you can compile and do interactive prototyping together at the same time, this is very beneficial for me, to do user testing and shadowing on how the potential user interacts with the app prototype. I sometimes, put an extra effort to make animated gifs on how the interaction happens between the screens, so the dev can just look at it during their busy days, to quicker the implementation process.
The main objective of hi-fi prototyping is to get the idea of how screens interact with one another to achieve the intended task. So, feel free to explore whatever prototyping tools out there.
After done with the prototyping, then we'll be having second design workshop, this time with the devs. We need to listen to their insights, like; this thing can't be done, if that's so, how can we mitigate the restriction... etc.
Key activities here; Compile screens, upload them to only collaborative prototyping sites, Let people comment on individual screens. Make an interactive prototype. Let people interact with it, see if some users cannot get thru the screens and get things done.
5. Developer Handoff
Hard works pay off. My life is getting easier when I'm reaching this phase. It is the time to hand off the design to the dev. I will upload the screens to my tool of choice and send the link to the dev. Now, it's their responsibility to implement the design and giving them the virtual life the screens deserve.
A tool is just a tool. What important are your skills in using them. Nevertheless, this is my fav tool, Zeplin. Why? Although it doesn't support interactive prototyping, it offers dark mode (Predictable Aan).
After the dev finished with implementing the screens, designers, devs and the QA will have a session together to check the design conformance and quality control of the implemented app/SaaS. Once the implemented output reached a satisfactory level, we will call the PM to get them signed off.
//Actually for mobile app, there's another thing that needa be done. Which is creating the app icon, marketing collaterals for Apple App Store and Google Play. But I bet you know the drills yourself.
OK. Fuhhhh. It took me almost a month to complete this blog post, as I'm not binge writing them in one go. Welp, writing is not my forte. Okay, see you next time.
Clickbait-ish intro. The Parasite's vibe. |
IRL, I'm known as an impulsive and spontaneous person, but I am really a different person while working something out.
You need to strategize, adapt to the given time, do things systematically, efficiently and outsmart whatever possible — so that you can afford to chill & swag when nearing the deadlines.
UI/UX process might vary depends on the organization, company or personal preferences. Nevertheless, here is my personal system/process of getting a product design done.
1. Product Research
This is 80% UX, 20% UI. At this phase, I need to reimagine myself as a product owner and the product user. What the product is about, how the system works, how their API looks like, market study... usually, this is the time that I need to know a lot; so I will ask a lot until I can understand what this product is about and how it works. Don't forget to do the SWOT analysis ah! I also need to know what the requirements, what the client wants on this product (most of the time, they know what they want but not what they need). And record the heck out of it, for reference.
Being inarticulate, I don't think I will write long stuff here, because this is the basic thing people should do. Key activities here; Product background study – what, why, when, who, how, Market research – competitor, user, SWOT analysis. Requirement listing – remember requirements ≠ features.
2. User Journey Mapping
This is 70% UX, 30% UI. When I got all the details about the requirements and features the client wants, it's time to list them down–collaboratively in Google Docs. I usually will start listing out requirements and features based on the sections. Actually, writing is hard, lemme explain thru images.
Clear up all the uncertainties. It is our job to solve the problems.
And next, this is the fancy part, mapping the UJM. Grabbing my pen/marker guys, I need to do some hands-on job. Let's map the screens of the user story!
For best practice, stick with complexity level 1, because quality guys! |
Key activities here; Convert requirements and features into user stories – Develop UJM, screen mappings from the user stories.
3. Lo-fi Wireframing / Prototyping
This is 50% UX, 50% UI. And also my favorite part. I can spend hours doing this while listening to lo-fi chill pop songs. The faster I do this, and the faster I can get project manager and devs response to my wireframed flows, the quicker the project manager can show to the project owner for sign-off. Then, I'll have more time focussing on the details when the hi-fi screens available later on.
After 5 years of working in this industry, I noticed that this part is basically what stakeholders anticipate; like looking at their idea slowly visualized into reality. Sometimes, contemplating which UI/UX to be used in a screen can be quite difficult. When this happens, I will make 2 screens with different interfaces and just ask others what is their opinion (during the design workshop).
This is the fatass me, troubleshooting what is the most suitable UI/UX that can compromise the allocated purpose of this screen. |
Once I've finished wireframing the crucial screens that allow the task to be completed by the future user, we will make a design workshop, this workshop will be attended by fellow designers, PM and devs. Sometimes, the big boss and the client also will join.
After the workshop is done, and I get all the feedbacks, critics and useful opinions, I will then amend the screens that needed UI/UX fine-tuning. After that, I will start to do the most hassle part—Compiling all the wireframes together into its flow.
What I like about doing mobile apps, the overall wireframe compilations won't be more than 50 flows. But, if you are designing the UI/UX flow for SaaS of software, the flows can be more than 100 and they're normally freaking a lot!
Flows of half the requested requirements. HUGE |
Key activities here; Start thinking about how the app/SaaS would behave, function and feel like. To convey your ideas, do a lot of wireframe sketches and make it into flows, and learn the soft-skill on how to communicate and present your wireframes.
4. Hi-fi Wireframing / Interactive Prototyping
90% UI, 10% implementing the UX. This is actually what you guys will see in Dribbble and Pinterest—Probably the epitome of the term 'App Design'. During this process, I will always remind myself, to not become enslaved by the design, because it belongs to the product owner. Nevertheless, try your best to fight for it, when you love it.
The next thing that I'll do is upload and compile all the screens to be viewed online by the stakeholders. By right, the clients can see the screens and give comments on them.
Me, in the process of compiling screens, before uploading them online. |
With the correct prototyping tool, you can compile and do interactive prototyping together at the same time, this is very beneficial for me, to do user testing and shadowing on how the potential user interacts with the app prototype. I sometimes, put an extra effort to make animated gifs on how the interaction happens between the screens, so the dev can just look at it during their busy days, to quicker the implementation process.
Showing the UX and the navigation between screens. |
The main objective of hi-fi prototyping is to get the idea of how screens interact with one another to achieve the intended task. So, feel free to explore whatever prototyping tools out there.
Showing the dev how we want the drawer behaves. |
After done with the prototyping, then we'll be having second design workshop, this time with the devs. We need to listen to their insights, like; this thing can't be done, if that's so, how can we mitigate the restriction... etc.
Key activities here; Compile screens, upload them to only collaborative prototyping sites, Let people comment on individual screens. Make an interactive prototype. Let people interact with it, see if some users cannot get thru the screens and get things done.
5. Developer Handoff
Hard works pay off. My life is getting easier when I'm reaching this phase. It is the time to hand off the design to the dev. I will upload the screens to my tool of choice and send the link to the dev. Now, it's their responsibility to implement the design and giving them the virtual life the screens deserve.
A tool is just a tool. What important are your skills in using them. Nevertheless, this is my fav tool, Zeplin. Why? Although it doesn't support interactive prototyping, it offers dark mode (Predictable Aan).
Zeplin |
Marvel |
After the dev finished with implementing the screens, designers, devs and the QA will have a session together to check the design conformance and quality control of the implemented app/SaaS. Once the implemented output reached a satisfactory level, we will call the PM to get them signed off.
//Actually for mobile app, there's another thing that needa be done. Which is creating the app icon, marketing collaterals for Apple App Store and Google Play. But I bet you know the drills yourself.
OK. Fuhhhh. It took me almost a month to complete this blog post, as I'm not binge writing them in one go. Welp, writing is not my forte. Okay, see you next time.