[UX] How to make Persona and User journey map practical in the design process
When I talked about Persona analysis and User journey map, I felt tired of thinking of the goal from this work to the design process in the final stage. I can understand why we need this process to understand our potential users and their needs. However, I am just wondering what is related to the design process for high fidelity design or working prototype from these.
1. Prologue
I love to listen to the VOC, the voice of customers, which is kind of raw needs, and also like to guess what they need when they use the product.
Persona analysis and user journey map show what users’ characters are and how they use the product, when we design the product at the very early stage,
I could understand why we need this process, but I still have a practical question.
‘What is related to the product design in the final stage from this output?, and how can I approach this process more quantitatively, practically, or scientifically for the design process in the final stage?’
Of course, in some cases, I know I can clearly apply the design from them. For example, if I need to consider accessibility for elderly people, it is so clear to apply the design like big typography and loosen layout without any thought.
Actually, the answer of the question is in my brain. I instinctively know what I can do since I have repeatedly done this work for a long time.
However, doing what I can do and explaining what I can do are not the same, so I I tried to make sure how I approached and explained this process more practically in the specific and agile case, “Sign in” feature.
2. Persona analysis
I defined the persona who cares about the security when he uses the IT product. He is friendly with technology as an engineer.
He thinks security is the most important thing in the product while using that, and he expects the product to keep his sensitive and personal data safely.
3. Needs analysis
In the process, I wanted to find out what personality can be related to the needs, so I picked a feature, “Sign in”, and I could focus on the relations between the personality and the specifications of the feature.
Specifications can be defined as the attributions of the feature of the product. It means I can quantify the feature in detail with the design alternatives.
In the above image, I defined Text fields, Button, Policy, Feedback, and Masking password as the specifications.
This is the key point to make sure of the process.
If I can find the reason to choose the specific alternative related to the personality, from the persona analysis, I think I can reasonably insist why I choose the alternative by not just my preference.
3.1. Estimate the specifications
In each specification, I can define different behaviors or UI design consequences.
I popped up some typical alternatives, and estimated which alternative is much closer to meet what users need from the persona analysis.
3.1.1. Text fields and buttons
In the first alternative, I designed the text fields components for ID and password separately and activated buttons all the time.
After users input the ID, then they can input the password in the next page.
2. Buttons (Always activated)
In the second alternative, I designed the text fields components for ID and password within the same page as below and conditionally activated buttons when users input both ID and password.
2. Buttons (Conditionally activated)
For the estimation, I considered which one is easier to be taken over by hackers.
At this point, I noticed the second one is easier than the first one to be taken over because hackers can get 2 responses of the components by 1 submission in the second alternative.
When I looked at the button components in the second alternative, I should manage more status even though the number of pages to express the behavior is simple.
3.1.2. Feedback and masking password
In the first alternative, I designed more feedback while checking validations, and gave an option to show and hide password while masking password.
In this case, users get clear messages in each validation, and they can also clearly go to the page which they need to do like creating an account or resetting password in each step.
Users sometimes make a mistake while typing the password, but they may not know why they can’t sign in successfully because the password is masked due to security reasons.
That’s why the option to show and hide passwords is absolutely needed in a masking password context.
2. Option to show and hide passwords
In the second alternative, I made it without the option to show and hide passwords while masking passwords.
In this case, you may see only two different feedback for checking validations to check the existence of ID or wrong password like in the left and middle images.
In addition, you may think if there is no matched account, you don’t need to show the feedback like in the right image as below.
2. Feedback for checking validations (Recommended)
For this reason, you may want to simplify the feedback for checking validations as below, or you may like to design the snack bars or toast messages for that because you don’t have enough room to express the feedback in the page.
2. Dialogue type feedback
For the estimation, someone can say the second one is quite better than the first one because it doesn’t show the correct feedback message if the account is already taken or the password is correct.
That can be the reason that the designer and developer can agree with the simple and unclear feedback when they insist that it is better for the security as well.
However, we should think there is another case that users don’t remember their IDs. In that case, there is no way to know if the input ID exists or not.
In addition, when you use snack bars, toast messages, or any other dialogues, feedback message and text fields position may not be close enough.
Moreover, if you correct the second alternative for the feedback, you have to consider more things.
For example, you should design a dynamic layout to show the validation message between ID and password text fields, and handling to show the status of the selected text fields which user made mistakes is more complicated.
In conclusion, the alternatives meet what users need from the persona analysis quite enough, but I would rather try to make sure of clear and certain feedback as much as possible.
3.1.3. Policy
Policy is one of the apparatus to support users’ needs in this case. I also designed two different alternatives for these and estimated them.
In the first alternative, the system can filter suspicious trials to take over users data, and users can also try to sign in after they make some mistakes by accident in the left image as below.
In the second alternative, the system can filter suspicious trials to take over users data, but users can’t also access the system at the same time.
2. The way to block the trials for a while
For the estimation, we can think about very strong policies.
For instance, we can just block the account permanently or lock the account for a long time after some incorrect trials. You may also think of the idea of 2-factor authentication.
However, I considered the stronger the way is for the security policy, the harder users can access the product.
At least, if it guarantees a stronger policy than just nothing, I think it can be fine in most cases except like financial products.
Plus, we also think of other users having different persons.
4. User journey map
I chose the first alternative of each specification after the considerations, and I defined the user journey map as below.
It shows how users journey the product from sign in to the main or landing page.
5. Epilogue
I tried to explain the processes more practically from persona analysis and user journey map in the early stage to the high fidelity design in the final stage based on my experience. Please share your experiences or ideas about this. Thanks.
댓글
댓글 쓰기