A comprehensive list of UX design methods and deliverables
uxdesign.cc
uxdesign.cc
There is a science to designing human computer interactions. But there is a subtle difference between wielding that science in the service of the humans in those interactions (users) and wielding it solely in the name of increasing the company's bottom line. The former will lead to a better product, will improve customer satisfaction and lead to sales. The later leads to a dystopian, exploitative relationship, even when it increases revenue. The difference is the goal: Serving users or serving shareholders. The language of UX design needs to be carefully crafted to keep a the focus on empathy with users.
Note that there has been debate in the field about the term "user" for decades. Some people object because it is ambiguous, some because it reduces people to their interaction with your software, others due to the connotation with drug use. (For example: https://medium.com/microsoft-design/we-have-customers-not-us...)
I've had people replace instances of one with the other in my documents, so I don't read too much into it these days.
Obvious example: building an e-commerce platform. The merchant is a kind of user. The customer is a different kind of user on that same platform. Yes, they're humans, but they're not doing the same thing.
Any B2B or B2C type product will have at least two very distinct roles like that. And in those cases, arguing that everyone is just a person as a sort of moral position is destructively vague. It's more difficult to serve someone's needs if you can't start to narrow down what they're trying to accomplish.
While I totally agree with the sentiment that we shouldn't conflate personhood identically with their role in a product, solving useful problems does require that you de-scope and discretize the interactions a bit.
I think the term "User Experience" picked up in the late 90s (e.g. Don Norman et al's CHI95 paper) when folks felt that the term "interface" had become too narrow and implied a focus on screens and controls and excluded people and what they do with those screens & controls.
The "human-computer interface" originally referred to the boundary where those two systems interfaced and included hardware, software, and wetware. But nowadays if you ask someone to point to the "user interface" they'll probably point at the screen.
If you're interested, there seem to be a cottage industry of blog posts and infographics about the "difference between UI and UX" but in practice it seems that most people use them somewhat interchangeably and I'm not sure how much benefit the semantics debate provides in practice.
If you squint, you can recognize this approach as an iterative specification for a product or a set of related products.
Some interesting take-aways for me:
- UX seems to put a lot of value on visualizing data, thought and processes in different forms. They range from simple, ad-hoc, to quite involved.
- A huge part of this work revolves around communication and testing: getting the right feedback and then analyzing it.
- In software, they should probably be directly talking to engineers and UI designers, to provide the right set of problems to solve. This is maybe a good way to cut off management hierarchies that understand neither (users and implementation).
[0] I've also seen the term "Engineer", "Architect" and others associated with it, but from talking to a UX "Architect" from a large company, I found that the best description would be "Designer" or "Director", because even though there are sometimes data-driven inputs their bread and butter seem to be very design, and communication focused. Maybe "Analyst" is a good term too.
Especially if you need to communicate that information with design, product, and engineering stakeholders who understand visual information better.
> Value Proposition Canvas:
> A reductive process in the early stages of product definition that maps out the key aspects of it: what it is, who it is for, and when/where it will be used. Helps the team narrow down and create consensus around what the product will be.
Is this perhaps a transformative critical framework that investigates a reductive analysis of social cohesion factors that lead to an embedded matrix of exploratory identity formation?
A reductive process is a process where you take many ideas and boil them down to fewer ideas. The opposite would be something like a brainstorm, where you try to get more ideas.
And I don't really think you actually have no idea what "product definition" may mean. :)
In your interpretation, a proposal of a value one attempts to deliver is a process wherein one takes many ideas, and boils them down to fewer ideas.
That is not what the meaning of the term “proposal” is; no one uses it to mean a process wherein many ideas are reduced to fewer. A proposal is simply stating one's plans, not a discourse.
> And I don't really think you actually have no idea what "product definition" may mean. :)
I normally have an idea, but not in this context, as it speaks of stages of a product definition. A definition does not have “stages”
The focus on communication and discourse is paramount, because UX brings the user to the forefront and then has to convince owners and implementers. This kind of convincing is important and often challenging, because there are often tradeoffs involved.
Having said that, this kind of syndoche where a process is described by its output doesn't seem particularly unusual or UX-specific. When a coworker says it'll take an hour to do requirements I know what they mean.
I'm not sure why you think "definition" (1: the act of defining https://www.dictionary.com/browse/definition) cannot have stages.
So essentially, your interpretation can be reduced to the advice “It is best to think about what one's product is, and whom it targets, before one makes a proposal about it.”?
If that be your interpretation, then that certainly does not follow from the text, and is contradictory with the interpretations others have given.
It's really difficult to understand your confusion here. "Definition" is referring the the act of defining, not the formal statement that results from that process. Are you reading it as the latter?
Every product I have ever worked on had definition stages. How else does the formal definition come into being?
But my impression is that UX jargon is usually pretty self-explanatory but sometimes unnecessary e.g. I'm not sure we really needed to come up with new terms for "sensemaking" (adding meaning), "microcopy" (labels), "responsive" (adaptive), "design thinking" (thinking), etc.
I call bullshit.
Pulling down to update on feeds/pages/apps is as natural as clicking icons by now.
It's similar to agile.