Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

We might be starting development of a web product in a couple of weeks. This being a startup, we have a limited budget. It's not zero though, we might spend a couple of grand on UX design.

I would really appreciate your advice on how to best spend that money? What can we do ourselves? We are prepared to learn and work hard, but I am not sure where to start and how to best invest our time and money.

share|improve this question

11 Answers 11

Unless you predict that your UX budget will grow in the near future, I would hold it off until you have a prototype that you can test, and then running usability tests and an expert review, if you can squeeze that in. That would give you the most bang for your buck.

In terms of things you can do yourselves to prepare - take a basic workshop and read books.

share|improve this answer
    
Hey thanks. I started reading "Don't make me think". Where could I learn more about expert reviews? –  Vladimir Aug 6 '11 at 9:57
4  
Read the 'sequel' to DMMT, Rocket Surgery Made Easy, for great tips on shoestring usability testing. –  Rahul Aug 6 '11 at 12:48
2  
I slightly disagree with Vitaly here, in my opinion you could start as early as with a paper prototype to "test" it with potential users. Instead of making one big usability test just before you ship, do more "quick" rounds with paper and prototypes early on... 1. Paper Prototype Walktrough (kind of a test) 2. Expert Review on paper & on digital Prototype 3. Usability Test with 3-4 Users on digital Prototype –  patrics Aug 7 '11 at 15:25
    
Patrick, if I understand correctly, you would involve the UX expert in an early phase, but after doing the groundwork (iterative testing of prototypes) yourself? Do I understand correctly you advise to involve her both to review the paper and the clickable mocks? –  Vladimir Aug 9 '11 at 12:20

I'd also consider doing some market research and talking to some users before you start designing anything.

share|improve this answer
1  
+1 for "before you start desiging anything". Absolutely. You need to ensure that you're capturing user's needs and not just building a product you think will solve that problem. Best to do some down and dirty market research, sitting with your target users in their environment. Your only cost would be time, travel, participant incentives (Amazon work well) and the fee to recruit participants in your target market (free if you use a tool like Ethn.io). –  Janel Aug 8 '11 at 15:09

You can do a lot on a limited budget. The main change I think is cultural, you have to get everyone considering the user. You can help embed this with personas, user flows etc.

What you could realistically spend the budget on is making sure you prototype and user test (and of course actually having budget to implement changes).

share|improve this answer

I'd spend a good bit of the budget on testing. Try reading Benefits of Extremely Low-Budget User Testing from Jacob Nielsen:

Summary: Testing a bank statement with two users increased the likelihood of picking the best design from 50% to 76%.

He has more details in his linked article: Why You Only Need to Test with 5 Users:

enter image description here

share|improve this answer

I'd spend at least some of your time, if not the budget on things other than testing. The best way to avoid having to spend a lot on testing is to make it right the first time, which means knowing the best practices (by means of reading the literature), looking for possible issues with a design beforehand, and then iterating that until it's as nice to use as you can get it.

share|improve this answer

The first step you should take i actually free: Attitude...

Rule no. 1: Know the user
Work yourself into a mindset where you know the user and can imagine how the users think.

Rule no. 2: Focus on the task
A lot of people think that the graphics and look'n'feel is the primary focus when working towards UX. They're wrong. The look is indeed important (don't get me wrong), but it is the work flow and the fact that that the user can get their job done that is important. You should always ask yourself "what is the propose of this product?" and the one liner answer you get should always be with you when you design you product.

share|improve this answer

You're creating a new product to simplify peoples' life. So first of all you need to learn who your typical user is. Their average skill level, typical workflow and so on. Your decisions should revolve around your target users.

Having a small budget is actually a good thing. That way you will have to do most of the user experience work. Steve Krug's books are a good start.

Do not let topics like information architecture, personas, wire-framing etc. get in the way. Use whatever feels most natural. Research your intended users, research your competitors and common complaints on their forums. Use pen and paper to sketch block diagrams of your user interface, and create numbered sequences of them to represent workflows. Use rough sketching. The point is to visualise and discuss ideas.

Once you have all these in place start coding and fleshing out the real product. Then start using it internally. When you feel quite confident target a beta of the product to get real feedback from users. User feedback is invaluable.

Finally, as you are approaching the end of your beta period, I would suggest using your budget on a service like usertesting.com to get people fitting your target to try out the product and get more valuable feedback.

share|improve this answer

Echoing sagacious advice from above, I would always start from user research as this drives everything that follows; get it wrong and everything else falls to bits. I have worked on some big projects where not enough research was conducted in the first place and this came back to haunt the application later on.....

Depending on the complexity of the product I dare say you could get away with 10-20 1 hour interviews with potential users of your product. If you have more persona types then you may want to add more users.

Next step would be to build cheap prototypes: paper or simple html click throughs, and then test them test with a few users.

After this you keep refining the prototypes until you feel confident that you want to begin the more expensive 'built' version.

summary

do your research!

build basic version

test

refine

test

refine if needed

build fancy pants version

test

refine

get rich

share|improve this answer

You might spend a couple grand on usability? Usability is as essential as developers, servers, management, or accounting. The interface is the product. Usability engineering is about making something cognitively simple, which no one who is familiar with the product will know how to accomplish by just guessing.

Start with paper prototypes and random people (get out of the office), then iterate as much as humanly possible. There are mountains of research going back decades that show how effective paper prototyping is -you will get through 5x the number of iterations than you normally would.

If done correctly, you will very likely have to change fundamental programming decisions. It's better to learn what those changes are now instead of having to rebuild it from scratch.

Also read The Humane Interface by Raskin, it gives a good intro to the relevant cognitive psychology.

share|improve this answer
    
And let's make it clear: the money is in the manhours, NOT the software (though a copy of Adobe and a computer may still set you back). Spend 'em up front, though, and you'll save yourself HEAPS in the long run. –  Rachel Keslensky Jan 22 '13 at 14:35

Sorry, UX will cost you eventually -- if not now, then later when you're wondering why nobody's using your stuff. The best thing to do is spend the money early to get your thrashing out of the way so all of the big things -- like who your users are, what they want, and how you're going to give it to them -- are out of the way.

If you're that cheap, get your hands on a UX intern who's already studying this stuff -- even paying them at $10/hour, you'll get a little over a month's work out of them (and yes, you have to pay them) -- but for actual bang, it may be worth it to buckle down and hire a proper designer, or just invest in a handful of books and learn by doing.

  • Paper prototypes are cheap, quick, and easy to iterate. If you're heavy on using a computer, Powerpoint / Keynote prototypes are also pretty useful and quick to do, but might look too high-fidelity for proper feedback.
  • You don't need a lot of people in order to test them, but you DO need to step outside of the office to find them.
  • The more iterations you do, the more likely you'll get good results, as long as you're iterating with a "broad stroke" in mind -- i.e. iterate with as big a set of variations as possible, and then narrow it down, widen it up, narrow it down again, etc. You want to get to the best version possible, and not just what you think will be the eventual best version. The only way you're going to get there is if you make sure to show some variety along the way to prevent yourself from getting stuck in a rut.
share|improve this answer

"A couple of grand" can actually get you quite far when you're going at it with a start-up attitude. Assuming that you are willing to spend some time on this as well as some money, there are plenty of things you can do. There are already a lot of good answers here, so I'll try keep repetition to a minimum, but based on my experience working on UX at a start-up, here are some of my thoughts.

  1. Get to know your users. Even if you don't have any yet. You are building a product, so you will need to do this anyway (how else will you know your market). Get specific. very few products are for "everybody". You can always identify different types of users that have different demographics, needs etc. Find out what makes each type tick (preferably by talking to them) and write this down (You can take this one step further and construct persona if you like).
  2. Understand your product. Understand the tasks, goals, steps etc. that users will face in your product. Map out the flow of tasks and think how that translates to controls, screens, dialogs etc. in your system. Identify typical scenarios (based on what you learned from users!) and make sure the flow makes sense for those. Think about what happens in exceptions.
  3. Get early feedback. You don't need to have a finished product to get feedback. You can get feedback on lots of things, from stories to crappy drawings on the back of a napkin. Again, lots of this stuff you will have anyway. You probably sketched some screens of your interface before you started coding HTML – show those to some people. Make sure you ask the right things to the right people: ideally you get feedback from real potential users, but if you can't get your hands on those, you can also ask friends or even colleagues (those are obviously biased, but can still get you feedback on whether screens are confusing, buttons are not labeled clearly etc.).
  4. Iterate. Keep asking for feedback as you go along. Refine the flow by rearranging screens, etc. where needed.
  5. Use the web. If you are a web startup, you can get a lot of feedback from the web, some of it for free. Websites such as FiveSecondTest are great, because you can post a screenshot and get feedback from a total stranger for free. You can also look into things like Amazon Mechanical Turk and ask people for feedback on Twitter.
  6. Use Unmoderated Remote User Testing. For less than 200 dollars/pounds/whatever you can get a few complete strangers to use your website, performing tasks you give them, while recording a video of their actions and thoughts. This has many limitations (they are not real users and may be too experienced, you cannot interact with them etc.), but the information you get from it has very good value for money.
  7. Get in touch with your first users. Make it easy for them to get in touch with you, but also try to reach out to them when they talk about you on Twitter or something. You'd be surprised how willing to talk some people are and how much valuable information you can get from them. If your site is live, you can even recruit people from among users of your site using popups (but target them properly so you don't annoy and scare away users/customers. Services like ethnio can help). Offering a reward (a gift card, for example) will make sure you don't just get only people who really love or really hate your product, but also people who just want a gift card and are otherwise more "average" and representative.
  8. Measure. Define what indicates different levels of "success" for your product. Measure things like registrations, logins, active users, purchases, everything. You can only detect problems if you know what a problem looks like.
  9. Use A/B testing. Once you launch, this can help you test the impact of changes you make. Be careful that you're actually interpreting the results right, it's easy to draw the wrong conclusions. To your homework and define the right performance metrics and set up the test in a solid way.
  10. Get expert opinions. If you can afford it, it may be worth to pay someone to give their expert opinion. I think this is most valuable for solving problems, rather than finding them. If you have identified a problem from user feedback or usability testing, an experienced designer might be able to help you understand why the problem exist and propose a solution.

A lot of this may seem like blasphemy for a UX professional with a budget, but doing anything is better than doing nothing at all. The most important thing is commitment. If you can take some time to talk to users and think about how you are supporting them, that is worth a lot. If you don't want to spend the time but have money: pay someone to do it for you, you won't regret it. Bear in mind that the sooner you find a mistake or invalidate an assumption, the cheaper it will be to correct. Thinking about UX properly early on will save you lots of trouble later on.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.