Ask HN: Is this UX?
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.
28 comments
[ 3.9 ms ] story [ 73.4 ms ] threadcard 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.
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.
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.
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.
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.
> 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.
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.
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 :).
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!
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.
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.
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").
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.
That's a good thing.
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.
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 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)
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 :-)
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.