Ask HN: Is this UX? | Hacker News Reader

Ask HN: Is this UX?

29 pointsoldmanstan28 comments

I'm taking a class in user experience at my nearby junior college. And some of it seems really practical; but other parts of it don't.

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.

View on HN

You are asking two questions. The first 'is this UX?' one, has the answer "yes". The second one "is this representative of what the average startup goes through when designing a user experience?" also has a "yes" answer, but startups typically cut quite some corners. Good startups cut the corners they can get away with, and only as far as possible.

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.

These are definitely UX methods used by practitioners in larger workplaces/agencies. The issue is that most startups don't have a UX person that focuses exclusively on UX. For better or for worse, there aren't many resources given to UX in startups so the person (it's usually only one person) that is responsible for UX is often also responsible for UI, visual design, branding, marketing, HTML/CSS, etc.

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.

I think you've made an important distinction here, which is easy to gloss over: that UX isn't necessarily UI. I tend to think of the UI more as the layer of gloss that's put over the top; whereas UX is the actual interaction flow a user will participate in. FWIW, a product the company I work for is designing is extremely pretty to look at, but when it comes to using, it becomes painfully obvious there's been little to no external user testing. I'm not involved with the project, but it pains me to see them not stump up the cash for even a basic expert evaluation.

For the OP, while at an undergrad level those techniques might seem trivial (I can remember being an absolutely arrogant prick while we were learning them!), it quickly becomes apparent either in the workforce or at postgrad level that they're valid and necessary tools for turning out a great UX. There's no point in designing something you find pretty and easy to use, when other users (your personas) might struggle with it.

They might bore you now, and I know from experience that lecturers can take weeks to teach what can seem a simple idea, but if you are seriously interested in UX rather than UI, write them up and put them in a notebook somewhere you can refer to later. You'll almost definitely find them useful :).

The most important point in here is: UX methods like the ones above give concrete form to gut decisions and help you defend them against pointless changes and management decisions.

When you just go out and design a UI, people start wanting to add things or change colors (bike-shedding). And you, because you just made it up as you went along, can argue aesthetics, but also perhaps feel like maybe other people know as well as you do.

But now you have personas, so when someone wants to add a feature, you can say: which of these people does that actually help, and which of them does it just confuse or get in the way?

And you have card-sorting, so when someone wants to add extraneous nav elements, you can say: what concept does that fall within? Which personas will agree with that organization?

And when someone wants to add lots of unnecessary questions to a form, you can say: how does this affect the rate at which people move through the storyboard and finish this key process? Do we want to jeopardize the completion rate for sign-ups just to get some more personal info?

Now, once you understand this thinking and have the political power to defend your decisions, you might cut out some of these steps or only use them internal to your own decision-making. But as a young designer, these can be helpful both to fashion your design sense and to protect your decisions.

If you startup experiences "pointless changes and management decisions", it's really pretty much doomed anyway. Might as well go work for a large company.

I haven't heard of these either, so I went looking for links:

card sort http://en.wikipedia.org/wiki/Card_sorting

unfocus group http://michael-roberto.blogspot.com/2010/01/unfocus-group.ht...

I couldn't find anything for "collage groups", but I can definitely see where the first two activities could be useful.

Keep in mind that while "the average startup" (whatever that is) doesn't necessarily perform all of these, or any of these, that doesn't mean that they shouldn't be using them. It could just be a matter of finances, or something as simple as not realizing these sorts of research exist.

I think if you were to work for a larger company, like Microsoft or Apple, that you would definitely find groups that not only use these techniques, but are actually dedicated to them.

The techniques mentioned (personas, card-sorting, etc) are all well known "best practices" in user experience design. The large successful companies in the consumer space (Amazon, EBay, Expedia, etc) adopt these practices (or derive their own mix based on these).

Do startups use these? Some do, some don't. Depends on the time frame, the resources available, and the knowledge and skills of founders.

This is similar to software development methodologies (agile, TDD, XP, etc). Some coders at startups are aware of these software development methodologies and follow them diligently. Others follow their own loose interpretation of these.

Some startups are successful purely with the blind, gut-feel approach: one smart programmer writing code with no methodology, plus one talented UI designer likewise working intuitively without the detailed upfront work. Of course, many startups fail, or have severe growing pains (Twitter for example).

Methodology and process, whether in coding or in UI, helps reduce the risk and insure successful outcome. You can still fail, and many do. Also many teams (especially in older, stagnant organizations), follow these processes blindly, as empty rituals. Ceremony does not guarantee success.

Personas, storyboards, scenarios: we used all of these at Microsoft. I've used aspects of each within the startups I've worked for or started, but never quite whole hog.

Nevertheless, they're likely all valuable tools. Just because you don't need to use a Philips #0 screwdriver every day doesn't mean it isn't critical to have when the situation demands it.

I'm not sure how to say this without coming off as a smart-ass, but isn't "used at Microsoft for UX design" more of an example of what not to do? Last time I tried to use a Windows machine, I ended up shutting it down by accident (was trying to switch users). And don't get me started on Phone 7.

The best UX design, in my experience, is simply done by a smart imaginative person who uses the product in a way similar to the users. Everything else is padding for syllabi/books/industry workshops.

> Everything else is padding for syllabi/books/industry workshops.

I would say, more, that UX design tools are made to let people collaborate on a design. They're useless for a "smart imaginative person" because said person has no need for collaboration.

Good point. It gives a common language, common metrics, etc.

I suppose my argument is, then, that good design shouldn't be collaborated on, but should instead originate in the mind of a single auteur, without the constraint of having to convince or even explain anything to others. As soon as you necessitate UX decisions be communicable and convincing, you begin suffer the weaknesses of design-by-committee.

Most real design-centered shops (like Apple) do something in between: a group of people gets together, agrees on requirements, then each goes off and conceives of their own solution(s) to the entire problem. Then, they meet up again, and use that "common design language" to each, in turn, advocate for their design.

Having worked on Visual Studio, I can't speak for either product you mention. I despise the Windows user experience, but that's really neither here nor there.

> The best UX design, in my experience, is simply done by a smart imaginative person who uses the product in a way similar to the users

I agree. Which is why these techniques tend to be less useful in startups: you're working on a product that is far more digestible in size than, say, Visual Studio or Windows. Hopefully you're building something that is of personal interest or applicability to you.

edit: as long as we're picking on products the other person has never worked on, why is Picasa so incredibly ugly and hard to use? Same thing with the AdWords and AdSense consoles.

I use the regularly, whether it's with start-ups or multi-billion dollar companies.

This is your absolute basic foundation stuff in UX, but it's only one part of it. This (persona modelling) is the sort of stuff that you do when refining processes based on how various demographic targets will go through them. It's essential stuff to know.

So, pay attention!

I'm a UX professional and I don't use these methods. No cardsorts. No storyboards. No personas. No 'unfocus groups'. And I wrote a book about them.

I do use research techniques though, sometimes. Usually they're really fast, and none of the ones you listed :)

Remember that many of the methods you listed where invented for work on large content sites, intranets and such, not consumer oriented products.

Answer to your question: no, it's not representative of what startups do for ux.

Yep, that's UX. Of the methods you mentioned I find card sorting to be particularly effective when you are trying to figure out what to present to the user.

Personas are first and foremost a communication tool and thus more useful in bigger organizations than in a small startup.

Personas can help to avoid useless discussion in meetings around UX design decisions, when every attendee (including managers that might be in a contact with the team only once in a while) has their pet peeves, instead of focusing to think it from the perspective of selected persona.

In a small startup, same group of people discuss all the time about the product and are better on the radar about design decisions, thus value of personas as communication tool is a diminished, although they still can be valuable.

(Note: Personas can be also a good thinking and design tool)

Short answer: this is "agency" UX. If you want to work in a startup, then 90% of what you're learning is useless. You're learning traditional practices that put emphasis on planning. Startups generally need to put emphasis on speed and flexibility and adaptation to change. For that, you might benefit from learning how to rapidly prototype with actual code and when creating UX documents, stick to what you know is important and necessary and cutout 90% of the bloat that traditional UX people design for.

You doubt it is UX because you are not actually designing any UI? Then it is important you understand why this class teaches you these methods: before designing a UI, you have to figure out what UI to design. You can design all the beautiful UI's you want: if you designed the wrong UI, or designed for the wrong user, they are completely useless. You have to understand your users, how they would use the app, etc. You may think you can just 'figure that out', but experience has taught that you will be wrong, because you are usually a very different person from the users of your app.

It's very important to understand that "what is UX" greatly depends on type of company and/or team you are working with (and their expectations).

Startup with small team - these things are still very useful but it's something you should do fast in your head/notebook or whatever to get a clearer picture for your self and provide your team with better suggestions for doing things (and not some formal "ux deliverables").

Yes, they're all pretty standard and certainly applicable to BigCo implementations in UX.

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.

I remember these methods from one of my books. However, I can't remember which one. It may have been in "Ship It", but can't be certain. http://www.amazon.com/Practical-Guide-Successful-Software-Pr...

What you're seeing strikes me as the empirical approach to the often gut-based product decisions that happen when building software. Is the gut method as effective? It all depends on the gut. Systematizing these decisions probably leads to more consistent results, but costs time.

As others have mentioned, it's probably more common to cut as many corners as you can get away with, then refine the experience later as resources, talent and feedback allow.

It seems complicated and long at first but once you get it, it is done easily. For instance, try to explain "how to walk" to someone who had an accident and forgot it. Even thought we know exactly how to walk and start doing it takes less than a second, it takes days to explain/master.

Those are all common well known UX practices.

It's true many startups don't use them. In my experience this is usually because they don't have the in-house skills or knowledge. They don't have to be complex or expensive in time or money.

Congratulations - you now have an advantage :-)

> we're going to do user research methods I've never heard of

That's a good thing.

I always think of HP-UX when I hear UX, when did the people start calling this UX?

I've used all those methods, but of course, using those methods alone don't deliver good (or even mediocre) usability.

Honestly, I think those methods are only useful if you already pretty much know what you're doing in general, know all the key principles, and are trying to get a handle on the specific case you're designing for.

People who don't know what they're doing usually try to hide that behind process-wanker-hood.

Reply on news.ycombinator.com