Ask HN: Is this UX?

For instance, a few weeks ago we spend a good amount of time creating personas for our target users. And then we created storyboards and scenarios. And so on.

In a few weeks, according to the syllabus, we're going to do user research methods I've never heard of: card sort, unfocus group, collage groups, and such.

My question is: is my class representative of what the average startup goes through when designing a user experience? It seems to me that most startups don't do most this process.

So, someone in that role has to condense each field of work into their most efficient/cheap forms. Formal UX processes like wireframing, rapid prototyping, and user stories can directly result in product decisions.

Other tasks are meant more for gathering inspiration, forcing lateral thought, challenging assumptions: exercises that inform product-level decisions. While that's very valuable, many startups already have a fairly clear path determined by folks from the engineering or business segments. The designer is usually taking pre-determined product decisions and crafting them into something usable, attractive, cohesive, marketable, and high-conversion. No easy feat, but not quite where unfocus groups are helpful.

This isn't what I would necessarily describe as ideal, but it is how it often works in my experience. I would hope that the fuzzier UX processes find a home in startups but I don't often see design having that much of a priority, in terms of resources allocated or level/stage of input.

Some of it, however, is bleeding into product development (user stories, personas, etc- not so much "UX" IMHO but still domain-useful). But if product dev is something you want to get into make sure you are learning about spec docs, agile methodologies and perhaps a programming language or two.

You should also keep in mind that all these are methods and not goals. You do not need personas/card sort/whatever to build a product, but they can help prevent or solve a problem. Startups often wait to the 'solve a problem' phase before they invest in these methods. That is fine, as long as you a) can detect your problem early, and b) once you have identified your problem, do not waste time doing stuff that does not help solve it. For these, you have to know what methods exist and what kind of problems they are useful for. That is what you should take away from this class.