Hacker News new | past | comments | ask | show | jobs | submit login
A comprehensive list of UX design methods and deliverables (uxdesign.cc)
123 points by davesailer on Jan 25, 2021 | hide | past | favorite | 29 comments



I am disturbed by the number of times "user" is replaced with "consumer" and "computer program" with "company" or "brand". Language is important for keeping the goal in sight.

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.


This view is over-simplistic. Many—perhaps most—products are designed to serve more than one kind of user.

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 definitely agree with the sentiment.

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.


Surely you're thinking of UI design. The term UX design was coined because it's not the same thing. You're right that UX design is not principally intended to benefit the user. That's by design.


I haven't heard that perspective before; the 'U' in "UX" stands for "User".

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.


I have very little direct experience with the UX specialization, although one could argue that everyone is somehow involved in it, I never worked directly with a UX Designer[0].

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.


There is a lot of value in visualizing information.

Especially if you need to communicate that information with design, product, and engineering stakeholders who understand visual information better.


I wholeheartedly agree. I also think the visualization space is vast and under-explored. Especially in the "hardest" cases like taming complexity, very abstract concepts and discovering new ideas.


Every time the term “UX” is dropped, what follows is incomprehensible vagueness dressed in bizarre jargon that would make postmodern grievance studies quiver in awe.

> 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?


I like how the example you used actually uses plain language "what it is, who it is for, and when/where it will be used", but because you approached this with the mindset that you're right and UX people dumb, you failed to see that and disproved your own assertion.


There is always plain language in between terms such as “reductive process”, “value proposition canvas”, and “product definition”, of which I have no idea what they mean.


A value proposition canvas is a canvas (could be a poster, could be a whiteboard, whatever) on which you put what value you propose to deliver.

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. :)


And then it doesn't make sense.

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”


> 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”

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?


Technically it would have been more precise to define "Value Proposition" as "(The result of) a reductive process in the early stages of product definition that...".

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.


Very well, so your interpretation now is that, contrary to what the page itself says, the definition of “value proposition” is rather to be taken the process that leads to a final “value proposition”?

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.


I'm sorry, I would like to help but I can't figure out where you're getting tripped up since (to me) the various interpretations don't seem to differ much in meaning beyond the linguistic/semantic fuzziness that is common in informal communication.


There seems to be a strong focus on iterative process. Problems/needs are (actively) discovered and then boiled down to possible solutions/proposals or at least something that can be acted upon.

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.


I fail to see the connexion between what you just wrote, and what I said that it does not make much sense to call a process wherein ideas are reduced in number a “proposition”.


I work in UX so I'm poorly equipped to objectively evaluate whether the field's jargon is any better or worse than any other field.

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.


The section you quoted defines exactly what it means by product definition - and the entire thing is a definition of value proposition canvas. If you can't understand the meaning of these things when they're clearly defined then I don't know how to help you.


I am a multimedia designer, by education, and I tend to still dislike some of these methods. Often I find them to just be a distraction from getting actual work done. Does not mean I would not use some of them, but I really prefer to just get the work done.


No mention of https://en.wikipedia.org/wiki/Fitts%27s_law ?

I call bullshit.


can experiences be designed? or are they co-produced with the service/system?


Everything is UX. UX starts with underlying data analysis - see Taxonomy and Card Sorting on the linked page. It continues through the development process. It doesn't directly comment on service implementation, but it does help specify what those services need to deliver


I think so. Some examples of places where this has impact but is often overlooked could be when you change car brand. Or if you go from one phone OS to another. The UX features will be slightly different, and there will be a learning curve.

Pulling down to update on feeds/pages/apps is as natural as clicking icons by now.


Co-production is a form of design, no? You design within constraints and it should be happening in tandem with the development of the system so they both feed into one another.


Yes you can design different experiences on top of the service/system. Customer support, packaging, onboarding process, flows etc.


This is just your standard formalization of a process to make it sound more professional and seem more legitimate.

It's similar to agile.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: