

Ask HN: Is this UX? - oldmanstan

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.<p>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.<p>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.<p>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.
======
Someone
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.

------
irondavycole
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.

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

------
asolove
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.

~~~
petervandijck
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.

------
AgentConundrum
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...](http://michael-roberto.blogspot.com/2010/01/unfocus-group.html)

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.

------
rayval
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.

------
aaronbrethorst
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.

~~~
andreyf
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.

~~~
derefr
> 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.

~~~
andreyf
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.

~~~
derefr
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.

------
petewailes
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!

------
petervandijck
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.

------
c1sc0
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.

------
dirtyaura
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)

------
hkuo
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.

------
Confusion
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.

------
Neputys
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").

------
dotBen
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.

------
asnyder
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...](http://www.amazon.com/Practical-Guide-Successful-Software-
Projects/dp/0974514047/ref=sr_1_1?s=gateway&ie=UTF8&qid=1285486720&sr=8-1)

------
danilocampos
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.

~~~
cinimod
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.

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

------
brudgers
> _we're going to do user research methods I've never heard of_

That's a good thing.

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

------
ahoyhere
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.

