What are the basic questions to ask a person who wants his Medium sized website done?

Question

I wanted to know the basic question that a person needs to ask if someone wants his web app done?? It can be UI,platform,crux of the applications and many other things...Please post what one needs to know before starting to work on a app.

Answer 1

What is your budget? Make sure everyone's expectations are realistic. High quality work requires higher prices. If they aren't willing to accept that, walk away. I'm assuming your work will meet high standards. This is still an important question even if your work is sub par, but walking away is less of an option.

What is your time frame for completion? In other words, do he expect you to write Facebook for his company in a week? If so, walk away. The difference between this question and the previous question is that you should walk away regardless of the quality of your work. Unreasonable time frames always end badly. Always.

What is the purpose of the website you are asking me to build? This is, surprisingly enough, often overlooked. Small to medium size businesses often take the approach of 1) make website, 2) ????, 3) profit! Make sure they have a plan to integrate the website into their business. A static, stale website full of useless information is almost worse than no website at all.

How technical are your users? This has wide ranging implications. For example, less technical users will cause a higher IE6 market share, so you'll have to design accordingly. Older users may require larger font sizes. The list goes on. Knowing your users is very, very important. For example, Stack Overflow uses "markdown" syntax because its users are technical and can grok it.

Will your site need internationalization? This depends entirely on the company, but in markets where there are large numbers of <insert non-English language> speakers, internationalization can be key to driving business to the site.

Are you willing to rely on my expertise? This is important, because more often than not, business owners think <blink> is just uber cool. Make sure you are in the driver's seat. Listen to their suggestions and accommodate them, but only where it makes sense. Don't compromise your design sense for their benefit, because this site will be in your portfolio and will therefore reflect on you.

Do you have any existing infrastructure I need to know about? This doesn't apply in all cases, but knowing ahead of time that you need to integrate their web application with an Active Directory environment can make a big difference in the technology you choose.

Learn their product inside and out. Not a question, but excellent advice. This will increase the quality of the overall product you are delivering (the website).

Do you have a color scheme in mind? Many times the company will have a color scheme incorporated into their logo, but if not, it would be nice to ask them if they have anything in mind. If it's not too outrageous (e.g., vomit green clashing with bright orange), try to use it as a starting point.

---

In response to the comments: The UI is really your dominion. Aside from basic things like color scheme preferences, you're the expert. Remember, the business owner is not a web designer and probably won't be able to tell you "I want the login form here and the date/time picker here".

The best approach is to work through some common use cases for the website. This, of course, relies on the business owner knowing what his customers will want to accomplish while using his website. This will determine both the UI flow and the core functionality of the website. Everything flows from use cases. They can be tedious to investigate and document, but the work is well worth it.

The UI and core functionality are unique to every website, so addressing them in the general case is difficult. Working through use cases is common practice in projects of all sizes and of all types, and it's a skill you will need moving forward. Sorry to give you such general advice, but it's really the soundest advice I can think of. Good luck!

Answer 2

There are also process questions that may be worth asking intially.

What kind of progress reports would he want to see as you work along on this project? This leads into the whole communication component that is big, IMO.

Would he like to see prototypes and offer feedback at various stages of development in an Agile fashion or is it just a big black box that you deliver when it is done?

Legal requirements, including does the application have a "Terms of Service" or "End-User License Agreement?" as well as what license is this supposed to be built using? Does he want everything built off an open source stack or is it a "just along as it works" scenario?

Scale would also be something as in what are we calling "medium" in terms of its production environment? A medium size webfarm from Amazon, Microsoft or Google would probably contain thousands of machines given the company's size while others may view having more than a handful to be medium sized.

Last but not least, nail down the requirements. This falls into the legal requirements in a sense as you build it for $x and he wants an application that does a,b, and c.

Answer 3

Some of these are similar to Mr. Brendel, but hopefully I added value. In no particular order:

• Why are you building this application? (Describe what the "happy endpoint" for this web application looks like.)
• Are we carving new processes/modules/functions, or simply automating existing processes/modules/functions? (The latter is easier than the former.)
• What are the processes/modules/functions in scope for this application? Who defines them?
• What is the overall business model of the client? Where are the touchpoints between the application and that model? How much is being affected?
• What value is being delivered? How will it be measured? (Closely related to the first question...)
• Who's going to use the web application? (The web app needs to be designed with the end-users in mind.)
• Who are the "stakeholders"? (IOW, who's going to benefit or lose directly from the project? Of course, it won't, but what if the dealine must slip? Who's the person(s) that this will reflect on?)
• What's your budget, if any?
• What's the dealine/go-live drop-dead date, if any?
• Do you have any rules/process for interacting with external/internal developers? (Ex: reporting needs, coding standards, etc...)
• Is it technically integrated with anything else or stand-alone?
• Is it visually integrated with anything else or stand-alone? What characteristics/attributes/attitude should the site convey to users?
• Is it replacing anything? If so, what and why?
• What "server stack" will it be deployed on? What technologies must be used, if any?
• What are the "hard metrics" that must met, if any? (Ex: Must be able to field 1000 requests/min.)
• What are the project's security needs?
• Who will test/validate the prototype? What are their needs/expectations for performing testing/validation?
• Who will maintain the web application? What are their needs/expectations for performing maintenance?
• Who will maintain any static content? What are their needs/expectations for performing maintenance?
• Who will train users? What are their needs/expectations for performing training?

Now, be careful. First, interview stakeholders both individually and in groups. Interview multiple times, if possible, because your first interview will possibly precipitate ideas that you'd pick up in a second interview.

It's best not to mash all of this in one interview with all stakeholders and end-users in the room at once. Divide it into two parts, at least: the "current and future business" part, and the "exact solution" part? Don't mix conversations about the business-side of the problem with the other conversation you should have on pet features, functionality, content, search engine optimization, etc. The latter will tend to obscure the former, but the former is where a good developer can really catalyze a business.

Hope this helps. Requirements gathering is pretty much an art, not a science...

Answer 4

Ask them to provide you some links to sites which have similar functionality or layouts. This will really speed up communications (especially the creative process) and set expectations on both ends.

This is the easiest way to establish a starting set of requirements.