What do you do if there’s no budget for User Experience (UX) in the project plan? Do you abandon the idea of UX or is there something else you can do?
Working on a Shoestring
If you’re just starting out in your UX career, there’s going to come a time when you get to work on your first commercial project. What do you do if there’s nothing in the budget for UX or only a tiny sum of money available for UX?
Well, the good news is that you don’t have to panic. You can carry out some UX related activities with very little budget and you’ll often find that in small teams, other people will pitch in if you’ve sold the benefits of UX to them well.
One Day of Your Time
Let’s look at an example. You’re asked to review the UX on a website that your company is launching. They’ve spent all the money they’d allocated to the project on the design phase (without you) and thus they’re not able to give you anything to fund the exercise. However, several people on the team have agreed to give you a few hours of their time if you can come up with a plan that makes sense.
You also have a time constraint. Today is Friday and they want the UX work done on Monday so that any changes can be made on Tuesday and the site must be launched on Wednesday.
What could you do?
Firstly, you want to get as much feedback as you can handle in that short space of time. So the majority of your time (perhaps 6 hours of an 8 hour day) wants to involve working with people. The rest of the time should be allocated to reporting your findings (you’re going to have to write something down so that the development team can do something about the issues you identify).
To work with actual users you could head to a local internet café, and perhaps the company could spring for a few cups of coffee to encourage people to lend a hand? That would be a kind of guerilla user testing. It won’t be perfect; you don’t have enough time to let the users go deep into the site, but it will help uncover any really obvious issues. You could spend 3 hours on this.
You could also sit down with your project team and hold an internal review of functionality. A kind of high-speed user acceptance test if you like. You take the functional specification for the site and work through it from A to Z to see if everything works as planned and get their feedback as you go. 3 hours on this might reveal some substantial insights if you keep everyone focused on the task in hand.
Then you have a couple of hours to report on the project. This doesn’t need to be a major task. Agree up front that the report is going to be a bullet point summary of issues identified – nothing more. This should (combined with the outcome of the meeting with the project team) give the developers enough to go on to make any changes prior to the release.
