Please give an example of each and where each is used in UX process? Is each necessarily used in all projects? Or some things are necessary to certain projects and others to other projects?
1 Like
hi @akrimony
It’s an interesting question and I will partially reply to it, because part of your question, in my opinion, is pure theory.
My experience, as a designer, tells me it does not matter how you define this kind of information but it counts as you use them to determine the product/service design process.
Surely some of these elements are needed in specific moments of the product design process. For instance, to define the user flow in the early stages of the project it is essential to determine the effort required to implement the project itself.
There are, of course, different layers of the same information if what you are designing is something new or if it is an update, a bug fixe and/or a process optimisations.
I am sure that a good research will provide you the formal definition for each of these deliverables. Regarding the “how and when to use them” I think is strictly related to the nature of the project, the processes available within your context and the status of the project.
A good start could be: http://uxmastery.com/resources/glossary/
3 Likes
Hi! I’m going to answer your second question, mostly because I think “good practice” really depends on your unique org/client setup and team and other constraints. The artifacts themselves aren’t as important as the benefits they confer - hopefully a shared, informed understanding of the user needs which can then be used to guide and validate good design.
"Is each necessarily used in all projects? Or some things are necessary to certain projects and others to other projects?"
No, each is not necessarily used in all projects. Depending on how “lean” your org is, you may not have the benefit of even a conversation with developers before they’re demo’ing some kind of MVP for project stakeholders! You have to meet the org and the process where it is at, and that may or may not include these different artifacts. In the case I mentioned, what has worked for me is learning the dev team’s rhythms and then going and whiteboarding collaboratively with them with different high-level action response diagrams, boxes and arrows. These are flows of some kind; to keep them from describing The System however we always try to focus on a specific human case and make it speculative but still practical. Even if we’re talking about an edge case. I think of user scenarios as longer documents that are more narrative. I observe fewer people using these as documents per se but the contents are critical to relay to project stakeholders in at least conversations for leveling.
4 Likes
@fotoband Luke, what is an edge case that you referred to? Is this a use case for extreme users (edge of the demographic )?
Thanks!
Marie
Yes Marie. I sometimes hear “corner case” and “edge case” used interchangeably but my understanding is these are non-typical scenarios but still possibly valid scenarios a design may need to account for.
1 Like
Hi @akrimony!
Our company currently just uses User Flows in our planning process which for us is basically the same as User Scenarios. Once the initial spec has been written…
We get a doc together and write down every task that the user will complete with the tool. Under each tasks, we write down every step.
ie. Change a password
- Sally logs into her account
- Sally wants to edit her password so she goes to Account
- Sally clicks Account Settings
- etc.
This really helps us not only make a process with the least amount of friction as possible, but also helps us visualize the end goal for the project. As we work through each and every task and scenario we can eliminate issues that we may come up against down the road. It also helps the devs as they know how the UI is supposed to function.
Hope this helps!
4 Likes