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.

I have an app idea but do not know how to do an initial requirements documentation. Do I do a survey based on what features I think would be good? Do I do a competitive analysis?

I have no budget to recruit users but could rely on some guerrilla methods like approaching people at a local cafe?

Any suggestions? Thanks.

share|improve this question

1 Answer 1

I would say you're thinking the wrong way 'round. Requirements first is waterfall design. And it's a surefire way to make something on budget and on time that everyone will hate and noone will use.

Of course, even if you see your first implementation as nothing more than a starting point, you need something to get started. But a list of requirements locks down all of your design before anyone has had a chance to think about it and a feature by name alone means nothing. You have to place things in context.

My advice would be to start with a simple model of what your users are going to be (some personas, user roles, maybe some axes to place you users on) and start writing user stories. Just two or three sentences describing who your user is, and what they want to accomplish. Make no assumptions about what you're going to build or what features will be included. Just who is the user, what does she want?

From the user stories, you'll get a picture of what a minimal application might look like. I'd follow these principles:

  • Don't include a feature unless it covers two or more different user stories. Features are easy to add, but difficult to remove.
  • Include the client in the design. If you drop a design on someone's desk after four weeks of development they'll never go along with it. All stakeholders need to follow the process and see the reasoning behind it. That means the client, the users and the developers.
  • Don't do dead documents. Don't make long technical documents that noone is going to read. Write simple user stories and illustrate how you're going to implement them with low-fi prototypes like wireframes.
share|improve this answer
    
Thanks Peter. This is a paper project, so there is no client right now. I just need a grounding base to work from. Do you suggest the same methodology? –  Inlin Apr 13 at 23:15
    
Can you explain what you mean by a paper project? Like a project for a university course? –  Peter Apr 14 at 1:44
    
FWIW, I've never been part of a waterfall project that was also on budget. ;) –  DA01 Apr 14 at 3:30
    
"Requirements first is waterfall and thus sure to result in something everyone will hate and no one will use?" Scuse me? Since when is it stupid to sit down and think about what some app should do/what problem it should solve? And since when does that imply waterfall? I am pretty sure that stories in agile are pretty much requirements? –  Marjan Venema Apr 14 at 17:21
    
Yes, Peter. A paper project is what I mean that it will not be executed and developed for market release. –  Inlin Apr 14 at 19:31

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.