You've now learned how to write a good functional requirements document and now it's time to write a technical specifications document. Is it actually needed? Well, it depends.
What is technical specifications document anyway?
While functional requirements document captures what client wants, technical specifications document layout HOW you will approach the functional requirements technically. It will be fully technical (eg. what technology you use, the database structure, etc).
For example, client needs a website that allows visitors to register. The technical specifications document will mention something like, "A ASP.NET session will be used to store visitor ID then a temporary session record will also be added to the database, etc". Another example will be client needs to have a drop-down-menu then in the document you'll mention, "ABC Drop-Down-Menu will be used with custom javascript", etc.
What is the purpose of technical specifications document?
The purpose of having this document is obviously to record the "magic" behind the website you create. Therefore, if you need to re-visit the project 1-2 years later, you know what it has.
Is it compulsory?
It normally is. Writing technical doco however consumes time but trust me, it's worth the time.
What's in there?
So, what does this document contain?
- Technology used
- Database schema
- Any custom Javascript and other scriptings
- CSS classes used
- etc (other framework used)
We have to be dilligent enough to keep updating this document as soon as our approach changes. For example, instead of saving the user to database, we will save the user to an XML file. Any technical changes have to be reflected in the document. If you get lazy (like I am), keep reminding yourself what the purpose of this document is. It's really-really for our own benefit.
Click here to download sample technical specifications document.
Tuesday, February 9, 2010
Wednesday, February 3, 2010
How to Write a Good Functional Requirements Document
Based on my previous article:
http://prowebdevelopment.blogspot.com/2010/02/how-to-do-efficient-requirements.html
I would now like to share my experience in writing functional requirements into a document. You have now finished your requirements gathering meeting and now it's time do your homework: writing functional requirements document. This is the document that will either win you the job or not.
What is functional requirements document?
Functional requirements document or sometimes called functional specification document is a document that captures and details client requirements. It's really a physical translation from meeting minutes into a format that is readable and understood by both parties.
What's in functional requirements document?
It's pretty much detailing everything you've talked about in the meeting with the client. It details the domain name, colour theme, approved layouts, website functionalities, hosting details, price agreement, etc.
It details how the system should behave and NOT how it is implemented. The customer doesn't need to know how it's implemented as long as the final product does what's required.
How does it look like?
Please download a sample functional requirement document here.
How to write a goood functional requirements document?
It's not hard to write a good functional requirements document. Below are some advice:
- Write with correct grammar. Get someone to proof-read the document once you've finished writing it.
- NEVER mentions anything technical! The document is meant to contain the requirements of the system and not HOW the system is going to be implemented. It should never say, "The website will be programmed in Visual Studio", etc. Remember, this document is the bridge between you and the client. Both parties have to be able to understand it!
A technical specification document on the other hand talks more about the technology behind it. It talks about how to achieve a particular requirement technically. For example, to allow visitors to register we will be storing the data in SQL database and the username will be stored in session, etc. I'll talk more about this later.
- Simple in layout heavy in content. Please download the sample functional requirements document above.
Conclusion
So, that's pretty much it! It's really not that hard to write a functional specification document. It really just captures what client wants out of the system.
Please stay tuned for more information,
Tommy
http://prowebdevelopment.blogspot.com/2010/02/how-to-do-efficient-requirements.html
I would now like to share my experience in writing functional requirements into a document. You have now finished your requirements gathering meeting and now it's time do your homework: writing functional requirements document. This is the document that will either win you the job or not.
What is functional requirements document?
Functional requirements document or sometimes called functional specification document is a document that captures and details client requirements. It's really a physical translation from meeting minutes into a format that is readable and understood by both parties.
What's in functional requirements document?
It's pretty much detailing everything you've talked about in the meeting with the client. It details the domain name, colour theme, approved layouts, website functionalities, hosting details, price agreement, etc.
It details how the system should behave and NOT how it is implemented. The customer doesn't need to know how it's implemented as long as the final product does what's required.
How does it look like?
Please download a sample functional requirement document here.
How to write a goood functional requirements document?
It's not hard to write a good functional requirements document. Below are some advice:
- Write with correct grammar. Get someone to proof-read the document once you've finished writing it.
- NEVER mentions anything technical! The document is meant to contain the requirements of the system and not HOW the system is going to be implemented. It should never say, "The website will be programmed in Visual Studio", etc. Remember, this document is the bridge between you and the client. Both parties have to be able to understand it!
A technical specification document on the other hand talks more about the technology behind it. It talks about how to achieve a particular requirement technically. For example, to allow visitors to register we will be storing the data in SQL database and the username will be stored in session, etc. I'll talk more about this later.
- Simple in layout heavy in content. Please download the sample functional requirements document above.
Conclusion
So, that's pretty much it! It's really not that hard to write a functional specification document. It really just captures what client wants out of the system.
Please stay tuned for more information,
Tommy
How to Do an Efficient Requirements Gathering?
Inviting client to a cafe for a cup of coffee is one thing but to have an efficient meeting and discuss about the website requirements is another thing.
On this opportunity I want to share with you my experience during requirements gathering time and how to make it efficient.
One rule that will not change: Client never knows what they want! Therefore - if we don't guide them - don't expect them to explain to us what they actually have in mind. Well, not all clients are the same but most of them are!
Especially with designing and developing a website, some of the clients I know don't even have any knowledge on what it's all about. Yes they're expert in what they're doing (ie. their business) but they normally have no idea what website is all about and what it takes to build one. What they know is: they need a website and that's about it.
It's our job as a professional web site designer and developer to guide them with this process.
What Do You Need?
Before coming to any meeting, it's always good to prepare what you want to talk about. I always prepare a checklist for this. The checklist doesn't have to complicated but at least it captures the basics of website development. For example:
- Domain name to use
- Colour theme and logo
- Basic pricing for domain and space hosting
- Website layouts discussion
- Site structure discussion
- Functionalities discussion
The Bottom Line
The bottom line is always that big question, "So how much will that cost me?". Client always wants to know pricing up-front. Always tell them, "It all depends on the functionalities.". Never say anything about price up-front because client remembers! And we'll be cornered later on if we've quoted them a price and we actually need more money.
It's OK to let them know of static pricing such as domain and hosting price, SSL price, etc.
The Requirements
Just like searching in Google, we have to know what questions to ask to get the right answer. You can pretty much type in what you like in Google but it doesn't mean that the results you get are the ones you want. When gathering requirements, make sure that you ask the right questions.
So, what are the right questions then?
Always start with this question "What's the purpose of the web site?". Be assertive and listen! Some clients are direct (ie. straight to the point), some aren't. Those who are direct will answer, "It will contain information about my business and nothing more.". But those who are not will go around in a circle and answer, "Well...I thought before that the website will talk about where my company is but then I changed my mind... I think the website should allow user to submit bla bla bla". At this point, you have to be assertive and ask the keyword question: "So, your website will only contain information about your company and nothing more?".
Then guide them into more detail, "Do you need visitors to be able to register?", "Does it need a contact form where visitors can submit enquiries from?", etc. They will then answer your questions either directly or indirectly. So in a nutshell:
At any time always be assertive and ask the keyword questions!
That's really how you can gather requirements efficiently. Don't let them steer you but you steer them. Apologise if you feel that you're cutting off their explanation but don't be afraid to do so. The more direct you are the better. Otherwise, they'll keep going on a circle.
If you need to, prepare a checklist that contains general website functionalities such as news roller on the homepage, contact us form, news & events page, etc. I will talk more about general functionalities that a website normally has later.
Your Homework
Once your meeting ends, summarize what you've talked about on a document then send it to them (client). Get them to ask you questions on things that they're not clear about. Otherwise, get them to approve the requirements document by signing it.
I will discuss later about how to write a good requirements document. It has to be detail enough and clear! It shouldn't say things that are too broad, for example:
- Client wants a news listing page.
Make it more detailed, for example:
- Client wants a news listing page that lists latest 10 news sorted by date. A paging control will also be added to the page to allow readers to navigate to older news items.
It's OK to make assumptions!
Once again, you're the expert not them. If a particular requirement is not clear, just make an assumption. You may forget to mention during the meeting how the news listing page is going to look like, but it's OK to make an assumption based on your expertise (just like above). When client later receives your requirements document, they can then picture it in their head and they may go, "Aha..that's a good idea" or even "Nah..that's a bit too over the top, let's forget about the news listing page".
A lot of the times client thinks that your ideas are great ideas and they normally approve it. That's even better because it means you will get longer work hence more money! Imagine if they cancel the news listing page, you have lost 1-2 days worth of work.
Don't complicate the requirements. Even though you want to win more work, it doesn't mean that you have to complicate them (the requirements). As long as what you add in there can help them achieving what they want, that's good enough. By complicating the requirements, it will make your life a lot harder later on when developing the website. It will also increase development time and may blow out the budget. Client may not want to go ahead with your service because it's too expensive.
Conclusion
So, let me remind you again. An efficient requirements gathering can only happen if you're assertive and listen. Ask the keyword questions. Do a lot of practice to find the keywords in a question.
Cheers,
Tommy
On this opportunity I want to share with you my experience during requirements gathering time and how to make it efficient.
One rule that will not change: Client never knows what they want! Therefore - if we don't guide them - don't expect them to explain to us what they actually have in mind. Well, not all clients are the same but most of them are!
Especially with designing and developing a website, some of the clients I know don't even have any knowledge on what it's all about. Yes they're expert in what they're doing (ie. their business) but they normally have no idea what website is all about and what it takes to build one. What they know is: they need a website and that's about it.
It's our job as a professional web site designer and developer to guide them with this process.
What Do You Need?
Before coming to any meeting, it's always good to prepare what you want to talk about. I always prepare a checklist for this. The checklist doesn't have to complicated but at least it captures the basics of website development. For example:
- Domain name to use
- Colour theme and logo
- Basic pricing for domain and space hosting
- Website layouts discussion
- Site structure discussion
- Functionalities discussion
The Bottom Line
The bottom line is always that big question, "So how much will that cost me?". Client always wants to know pricing up-front. Always tell them, "It all depends on the functionalities.". Never say anything about price up-front because client remembers! And we'll be cornered later on if we've quoted them a price and we actually need more money.
It's OK to let them know of static pricing such as domain and hosting price, SSL price, etc.
The Requirements
Just like searching in Google, we have to know what questions to ask to get the right answer. You can pretty much type in what you like in Google but it doesn't mean that the results you get are the ones you want. When gathering requirements, make sure that you ask the right questions.
So, what are the right questions then?
Always start with this question "What's the purpose of the web site?". Be assertive and listen! Some clients are direct (ie. straight to the point), some aren't. Those who are direct will answer, "It will contain information about my business and nothing more.". But those who are not will go around in a circle and answer, "Well...I thought before that the website will talk about where my company is but then I changed my mind... I think the website should allow user to submit bla bla bla". At this point, you have to be assertive and ask the keyword question: "So, your website will only contain information about your company and nothing more?".
Then guide them into more detail, "Do you need visitors to be able to register?", "Does it need a contact form where visitors can submit enquiries from?", etc. They will then answer your questions either directly or indirectly. So in a nutshell:
At any time always be assertive and ask the keyword questions!
That's really how you can gather requirements efficiently. Don't let them steer you but you steer them. Apologise if you feel that you're cutting off their explanation but don't be afraid to do so. The more direct you are the better. Otherwise, they'll keep going on a circle.
If you need to, prepare a checklist that contains general website functionalities such as news roller on the homepage, contact us form, news & events page, etc. I will talk more about general functionalities that a website normally has later.
Your Homework
Once your meeting ends, summarize what you've talked about on a document then send it to them (client). Get them to ask you questions on things that they're not clear about. Otherwise, get them to approve the requirements document by signing it.
I will discuss later about how to write a good requirements document. It has to be detail enough and clear! It shouldn't say things that are too broad, for example:
- Client wants a news listing page.
Make it more detailed, for example:
- Client wants a news listing page that lists latest 10 news sorted by date. A paging control will also be added to the page to allow readers to navigate to older news items.
It's OK to make assumptions!
Once again, you're the expert not them. If a particular requirement is not clear, just make an assumption. You may forget to mention during the meeting how the news listing page is going to look like, but it's OK to make an assumption based on your expertise (just like above). When client later receives your requirements document, they can then picture it in their head and they may go, "Aha..that's a good idea" or even "Nah..that's a bit too over the top, let's forget about the news listing page".
A lot of the times client thinks that your ideas are great ideas and they normally approve it. That's even better because it means you will get longer work hence more money! Imagine if they cancel the news listing page, you have lost 1-2 days worth of work.
Don't complicate the requirements. Even though you want to win more work, it doesn't mean that you have to complicate them (the requirements). As long as what you add in there can help them achieving what they want, that's good enough. By complicating the requirements, it will make your life a lot harder later on when developing the website. It will also increase development time and may blow out the budget. Client may not want to go ahead with your service because it's too expensive.
Conclusion
So, let me remind you again. An efficient requirements gathering can only happen if you're assertive and listen. Ask the keyword questions. Do a lot of practice to find the keywords in a question.
Cheers,
Tommy
Designing & Developing Professional Website - Step 4 - Web Site Deployment
The website is now fully tested and client is happy for it to go live.
It's now time for us to setup the live hosting service before we can transfer the files over.
Selecting Hosting Service
Selecting a hosting service can be a daunting task. They may look cheap but have they got good support, etc? Below are some advice that I can give when selecting hosting service:
- Look at review websites for a particular company that you're interested to get your hosting service with. Check and ensure that various review websites all say the same thing. Check the comments from people who have had their websites hosted with that company.
- Check if the hosting company supports your need in terms of the type of coding they're supporting, database, etc. Some host companies only support PHP and MySQL but some also support ASP.NET, etc. Ensure that the website you've developed can run on their environment.
- Check what the support is like. You can normally "test" this by sending a support email. These hosting companies normally have a Contact Us form on their website. Try sending an enquiry and see how long they get back to you.
- Check price (of course). Windows hosting is definitely more expensive than Linux hosting. You generally need Windows hosting if you program in ASP.NET otherwise Linux hosting will be sufficient.
- Check how much quota you have (ie. no of emails, databases, sub-domains, etc). If you know that your client will be creating a lot of email addresses, you may need to get higher plans.
Configuring Hosting
- You can use FTP clients such as FileZilla (free) to transfer files with.
- Create temporary redirection mechanism so that you have the time to test the production website before it goes fully live. This can be approached below:
* Create an index.html file that contains "This website is under construction" message or similar to the root folder so that when visitors are trying to access http://www.thenewproductionwebsite.com/, they see the "website under construction" message. The downside of this approach is, some IT-savvy visitors may be able to play around the URL eg. visiting http://www.thenewproductionwebsite.com/Home.php and they may end-up seeing the production website. That's fine if the website runs correctly but what if it doesn't?
* Ask the hosting provider to redirect ALL requests to http://www.thenewproductionwebsite.com/ to a temporary space/file. You can then create a sub-domain for testing eg. http://testing.thenewproductionwebsite.com/.
Please note that these are only required if you're not sure that the live website will run correctly after deployment. Your UAT environment may be different from the live environment. You may not use the same hosting provider hence server configuration may be different.
Before Going Live
Before your website goes live please make sure that everything runs correctly. Forms can send emails, user can register, the website has write permission to the required files, etc. It's embarassing when the website goes live and visitors try to register and the website then shows an error message.
So....that's all for now. From this point on, I'll go deeper and deeper into designing and developing professional website!
Cheers and see you soon,
Tommy
It's now time for us to setup the live hosting service before we can transfer the files over.
Selecting Hosting Service
Selecting a hosting service can be a daunting task. They may look cheap but have they got good support, etc? Below are some advice that I can give when selecting hosting service:
- Look at review websites for a particular company that you're interested to get your hosting service with. Check and ensure that various review websites all say the same thing. Check the comments from people who have had their websites hosted with that company.
- Check if the hosting company supports your need in terms of the type of coding they're supporting, database, etc. Some host companies only support PHP and MySQL but some also support ASP.NET, etc. Ensure that the website you've developed can run on their environment.
- Check what the support is like. You can normally "test" this by sending a support email. These hosting companies normally have a Contact Us form on their website. Try sending an enquiry and see how long they get back to you.
- Check price (of course). Windows hosting is definitely more expensive than Linux hosting. You generally need Windows hosting if you program in ASP.NET otherwise Linux hosting will be sufficient.
- Check how much quota you have (ie. no of emails, databases, sub-domains, etc). If you know that your client will be creating a lot of email addresses, you may need to get higher plans.
Configuring Hosting
- You can use FTP clients such as FileZilla (free) to transfer files with.
- Create temporary redirection mechanism so that you have the time to test the production website before it goes fully live. This can be approached below:
* Create an index.html file that contains "This website is under construction" message or similar to the root folder so that when visitors are trying to access http://www.thenewproductionwebsite.com/, they see the "website under construction" message. The downside of this approach is, some IT-savvy visitors may be able to play around the URL eg. visiting http://www.thenewproductionwebsite.com/Home.php and they may end-up seeing the production website. That's fine if the website runs correctly but what if it doesn't?
* Ask the hosting provider to redirect ALL requests to http://www.thenewproductionwebsite.com/ to a temporary space/file. You can then create a sub-domain for testing eg. http://testing.thenewproductionwebsite.com/.
Please note that these are only required if you're not sure that the live website will run correctly after deployment. Your UAT environment may be different from the live environment. You may not use the same hosting provider hence server configuration may be different.
Before Going Live
Before your website goes live please make sure that everything runs correctly. Forms can send emails, user can register, the website has write permission to the required files, etc. It's embarassing when the website goes live and visitors try to register and the website then shows an error message.
So....that's all for now. From this point on, I'll go deeper and deeper into designing and developing professional website!
Cheers and see you soon,
Tommy
Tuesday, February 2, 2010
Designing & Developing Professional Website - Step 3 - Website Development
We have now arrived at the most interesting part of the professional website development process. It's the development time YAY! It's time to get our hand dirty.
During development we will certainly need tools to help us achieving what we have planned before. I personally use the following tools at the very least:
- Adobe Photoshop
- EditPlus Text Editor or Adobe DreamWeaver
- Any development/coding tools such as Visual Studio or text editors for PHP development, etc
- Other tools such as Adobe Flash, etc
Adobe Photoshop
Using Adobe Photoshop we will create the website prototype. I will detail later what this is all about. In a nutshell, we will be creating images on how the actual website will look like (ie. the end "product"). We will design all layouts that have been approved prior.
We will then send these images to client so that client can see and approve what the final products will be. Remember, when developing websites we have to encourage client to approve everything up-front before we even start the development. Any changes/modifications have to be discussed up-front as much as we can otherwise the delivery of the final product may be delayed.
There will always be changes during the development but as a professional web developer we have to be able to - somehow - make those changes as "out-of-scope". Therefore, the decision is then on client on whether to implement those changes or not. I will discuss about this later.
HTML Editors
HTML editors such as EditPlus or Adobe DreamWeaver will help us a lot in producing the HTML code. After we design the prototype (see above), it's time for us to then "cutting up" those prototypes into HTML which can then be incorporated into a programming language such as ASP.NET or PHP for producing dynamic websites.
These text editors will help us doing the "cutting up". I will elaborate more on this later.
Dynamic Website/Coding Tools
What is static website vs dynamic website? Static website means that the HTML code on the website is static. If someone needs to update the content of this website, he has to literally edit and update the HTML code. Dynamic website means the HTML code is generated "on-the-fly" (eg. from database).
There are heaps of programming languages out there that can help us producing dynamic websites such as ASP.NET, PHP, ColdFusion, PERL, CGI, etc. These programming languages generally have their own "editor". The difference between this editor and HTML editor is it can load "commands/libraries" that are specific to the programming language.
If you need to develop dynamic websites (which most of the websites nowadays are), you will certainly need these tools. They will save you a lot of time and plus you don't have to memorize the commands/syntax that are relevant to the programming language.
Other Supporting Tools
You can also use other supporting tools such as Adobe Flash to create flash animations, etc.
UAT and Test Environment
It is extremely important to always have User Acceptance Test (UAT) and Test Environment. This will be used for testing and client demo. You will not want to use the live hosting space for your client demo because search engine may crawl it and there is a chance of visitors coming to the website that is not ready yet. This may hurt the website later on.
Test Environment can be your own laptop/computer while UAT is normally hosted or at least accessible remotely by client. Try to make your UAT environment isolated from public visitors. You can use a temporary domain name eg. http://test.clientdomainname.com/ or something.
Testing is always important as it is a part of quality control. By having UAT also, client can see the progress and they will like you! They can also make comments on the current progress of the website. You have to always be aware that what you send as a prototype may look different on the browser.
Conclusion
So...this is the development process in a nutshell. I will of course elaborate more on this. We will go much deeper than this. Later on we will talk about development methodologies such as Agile, SCRUM, etc. It's all about fun fun fun.... :)
Cheers,
Tommy
During development we will certainly need tools to help us achieving what we have planned before. I personally use the following tools at the very least:
- Adobe Photoshop
- EditPlus Text Editor or Adobe DreamWeaver
- Any development/coding tools such as Visual Studio or text editors for PHP development, etc
- Other tools such as Adobe Flash, etc
Adobe Photoshop
Using Adobe Photoshop we will create the website prototype. I will detail later what this is all about. In a nutshell, we will be creating images on how the actual website will look like (ie. the end "product"). We will design all layouts that have been approved prior.
We will then send these images to client so that client can see and approve what the final products will be. Remember, when developing websites we have to encourage client to approve everything up-front before we even start the development. Any changes/modifications have to be discussed up-front as much as we can otherwise the delivery of the final product may be delayed.
There will always be changes during the development but as a professional web developer we have to be able to - somehow - make those changes as "out-of-scope". Therefore, the decision is then on client on whether to implement those changes or not. I will discuss about this later.
HTML Editors
HTML editors such as EditPlus or Adobe DreamWeaver will help us a lot in producing the HTML code. After we design the prototype (see above), it's time for us to then "cutting up" those prototypes into HTML which can then be incorporated into a programming language such as ASP.NET or PHP for producing dynamic websites.
These text editors will help us doing the "cutting up". I will elaborate more on this later.
Dynamic Website/Coding Tools
What is static website vs dynamic website? Static website means that the HTML code on the website is static. If someone needs to update the content of this website, he has to literally edit and update the HTML code. Dynamic website means the HTML code is generated "on-the-fly" (eg. from database).
There are heaps of programming languages out there that can help us producing dynamic websites such as ASP.NET, PHP, ColdFusion, PERL, CGI, etc. These programming languages generally have their own "editor". The difference between this editor and HTML editor is it can load "commands/libraries" that are specific to the programming language.
If you need to develop dynamic websites (which most of the websites nowadays are), you will certainly need these tools. They will save you a lot of time and plus you don't have to memorize the commands/syntax that are relevant to the programming language.
Other Supporting Tools
You can also use other supporting tools such as Adobe Flash to create flash animations, etc.
UAT and Test Environment
It is extremely important to always have User Acceptance Test (UAT) and Test Environment. This will be used for testing and client demo. You will not want to use the live hosting space for your client demo because search engine may crawl it and there is a chance of visitors coming to the website that is not ready yet. This may hurt the website later on.
Test Environment can be your own laptop/computer while UAT is normally hosted or at least accessible remotely by client. Try to make your UAT environment isolated from public visitors. You can use a temporary domain name eg. http://test.clientdomainname.com/ or something.
Testing is always important as it is a part of quality control. By having UAT also, client can see the progress and they will like you! They can also make comments on the current progress of the website. You have to always be aware that what you send as a prototype may look different on the browser.
Conclusion
So...this is the development process in a nutshell. I will of course elaborate more on this. We will go much deeper than this. Later on we will talk about development methodologies such as Agile, SCRUM, etc. It's all about fun fun fun.... :)
Cheers,
Tommy
Monday, February 1, 2010
Designing & Developing Professional Website - Step 2 - Website Analysis
So, at this stage you have gathered the requirements, selecting domains, colours, etc. It's now time to do the website analysis.
Let's determine our goal first. The goal of this exercise is to come up with design ideas. We will now decide what menu we're going to use, what it's going to look like, what breadcrumb and left navigation controls we're going to use, what programming language we are going to use, etc.
Selecting professional web site designs
Based on the approved site structure and colour theme, it's now up to us to determine how we're going to design the site. I personally start from http://www.templatemonster.com to get some ideas. There you can select thousands of website templates that have been designed by professionals. I wouldn't mind purchasing if a particular design looks really-really good.
Determining how to approach the design
Once you've selected the design, it's now time for us to determine how we would approach it. For example, on a particular design that we've selected there is a drop-down menu. We have to determine how we can develop that drop-down menu. Whether we'll need a Javascript or third-party vendor control or whatever.
There will be other elements of the design that require development. Some may need programming. These include image buttons, navigation controls, footer, header, etc.
Determining how to approach functional requirements technically
On the website requirements that you've collected before, client may need a latest-news roller on the homepage. We will now need to determine how we can make this happens. Whether we'll be using database to store the news, or file system, or XML file, etc it is all part of this exercise.
There may be another requirement to have a contact form on the site where visitors can post an enquiry online and the posted enquiries can be retrieved later. It's our job to determine how we'll approach this.
Conclusion
In a nutshell, this step really gets us to do a bit of research and planning so that we have ALL the resources we need to develop the end product: the professional web site!
Remember, even with a lot of planning, things can still go wrong. They will just go even worse if there is no planning at all. So, before we're touching any code, let's get the planning right.
Until next time,
Tommy
Let's determine our goal first. The goal of this exercise is to come up with design ideas. We will now decide what menu we're going to use, what it's going to look like, what breadcrumb and left navigation controls we're going to use, what programming language we are going to use, etc.
Selecting professional web site designs
Based on the approved site structure and colour theme, it's now up to us to determine how we're going to design the site. I personally start from http://www.templatemonster.com to get some ideas. There you can select thousands of website templates that have been designed by professionals. I wouldn't mind purchasing if a particular design looks really-really good.
Determining how to approach the design
Once you've selected the design, it's now time for us to determine how we would approach it. For example, on a particular design that we've selected there is a drop-down menu. We have to determine how we can develop that drop-down menu. Whether we'll need a Javascript or third-party vendor control or whatever.
There will be other elements of the design that require development. Some may need programming. These include image buttons, navigation controls, footer, header, etc.
Determining how to approach functional requirements technically
On the website requirements that you've collected before, client may need a latest-news roller on the homepage. We will now need to determine how we can make this happens. Whether we'll be using database to store the news, or file system, or XML file, etc it is all part of this exercise.
There may be another requirement to have a contact form on the site where visitors can post an enquiry online and the posted enquiries can be retrieved later. It's our job to determine how we'll approach this.
Conclusion
In a nutshell, this step really gets us to do a bit of research and planning so that we have ALL the resources we need to develop the end product: the professional web site!
Remember, even with a lot of planning, things can still go wrong. They will just go even worse if there is no planning at all. So, before we're touching any code, let's get the planning right.
Until next time,
Tommy
Saturday, January 30, 2010
Designing & Developing Professional Website - Step 1 - The Requirements Gathering
In this opportunity I would like to talk about the requirements gathering phase of designing and developing professional websites. As I've mentioned on my previous article, this will be the very first step that we need to do before we even start designing, coding etc.
Remember, without defining a clear goal and purpose for our professional web site, we will end up getting confused and stopping mid-way through.
What's in It?
1. Goal and purpose of the website
During requirements gathering phase we need to define the goal and purpose of the website. For example, the website will be informational only. It won't have the capability of visitor to signup or login.
Another example: The website will be a community website where a visitor can register and interact with the other members. He will have a profile of himself and able to upload an image, etc etc etc.
After we determine the purpose and the goal of the website, the picture will get clearer. We can start picturing what will be on our website.
Be as precise as it can be! Ask your client what they want on their website. You - as a professional website designer and developer - needs to also have some knowledge in this area. Go to various websites that are popular nowadays such as community websites (Facebook, Twitter, etc), news sites, etc. This way you can offer clients various functionalities.
Remember, that's where the money is. The more functionalities you can offer, the more money you can make out of it.
2. Selecting the title and domain name
The next step will be for us to determine what the title and domain name of the website will be. Normally the domain name will mimic the title. For example, if the title of the website is "Tom's Mowing" then the domain name will normally be http://www.tomsmowing.com/ or something like that.
However, from SEO (search engine optimisation) perspective, a more friendly domain name may also be selected. For example: http://www.professionalmowing.com/.
Please ask your client what the domain name will be and what the TLD he wants. TLD is the extension at the end of the domain (eg. .com, .net, .com.au, etc). Also, let your client know that the domain he wants may not be available.
Bring a laptop that has wireless/mobile internet as you can perform a quick domain search during meeting.
3. Creation of the website structure
This is the important bit. When you first publish the website, it should have some content, shouldn't it? It's less likely that someone publishes a website without any content. The basic content that I normally instruct client to develop is the site structure.
Website structure is normally visualised in a tree-view form. For example:
- About Us
---- History
-------- 1970
- Products
- Services
---- Hosting service
---- Repair service
---- Eye test
- Contact Us
etc
It doesn't matter if you have "Under construction, please come back later" message on every page but at least - from visitors point of view - they can see what's coming.
Get your client to submit to you the basic site structure. If they want to be able to add more later then it's a further matter. Without this, it will be very-very hard to design the professional website later on. As we go along hopefully you'll start realising that all these will tie together.
4. Creation of the website layout
Normally I will create two layouts: Homepage layout and Content page layout.
What is layout anyway? Layout is the positioning of the website elements. Together with site structure, this will ease your way through when designing the website later on. Example of a layout is below:
Remember, these are only page layouts and no more. They only tell us where to position things!
We are not yet determining the design of each element (eg. color of links, shape of left navigation control, banner with gradient colours, etc).
5. Selecting colour theme based on client corporate branding
Now, this is normally the last step during this process. Ask client for their corporate branding (eg. logo) because a website is really an another realisation of client's corporate branding, hence colours have to match!
It also makes your life easier as well when you know what colour the website you're designing will be.
Conclusion
So, last but not least, this is really one of the most important steps in a professional website creation process. By skipping this phase we'll end-up getting confused of what we want with the website.
I've been there, I've done that,
Tommy
Remember, without defining a clear goal and purpose for our professional web site, we will end up getting confused and stopping mid-way through.
What's in It?
1. Goal and purpose of the website
During requirements gathering phase we need to define the goal and purpose of the website. For example, the website will be informational only. It won't have the capability of visitor to signup or login.
Another example: The website will be a community website where a visitor can register and interact with the other members. He will have a profile of himself and able to upload an image, etc etc etc.
After we determine the purpose and the goal of the website, the picture will get clearer. We can start picturing what will be on our website.
Be as precise as it can be! Ask your client what they want on their website. You - as a professional website designer and developer - needs to also have some knowledge in this area. Go to various websites that are popular nowadays such as community websites (Facebook, Twitter, etc), news sites, etc. This way you can offer clients various functionalities.
Remember, that's where the money is. The more functionalities you can offer, the more money you can make out of it.
2. Selecting the title and domain name
The next step will be for us to determine what the title and domain name of the website will be. Normally the domain name will mimic the title. For example, if the title of the website is "Tom's Mowing" then the domain name will normally be http://www.tomsmowing.com/ or something like that.
However, from SEO (search engine optimisation) perspective, a more friendly domain name may also be selected. For example: http://www.professionalmowing.com/.
Please ask your client what the domain name will be and what the TLD he wants. TLD is the extension at the end of the domain (eg. .com, .net, .com.au, etc). Also, let your client know that the domain he wants may not be available.
Bring a laptop that has wireless/mobile internet as you can perform a quick domain search during meeting.
3. Creation of the website structure
This is the important bit. When you first publish the website, it should have some content, shouldn't it? It's less likely that someone publishes a website without any content. The basic content that I normally instruct client to develop is the site structure.
Website structure is normally visualised in a tree-view form. For example:
- About Us
---- History
-------- 1970
- Products
- Services
---- Hosting service
---- Repair service
---- Eye test
- Contact Us
etc
It doesn't matter if you have "Under construction, please come back later" message on every page but at least - from visitors point of view - they can see what's coming.
Get your client to submit to you the basic site structure. If they want to be able to add more later then it's a further matter. Without this, it will be very-very hard to design the professional website later on. As we go along hopefully you'll start realising that all these will tie together.
4. Creation of the website layout
Normally I will create two layouts: Homepage layout and Content page layout.
What is layout anyway? Layout is the positioning of the website elements. Together with site structure, this will ease your way through when designing the website later on. Example of a layout is below:
Homepage layout
Content page layout
News page layout
Remember, these are only page layouts and no more. They only tell us where to position things!
We are not yet determining the design of each element (eg. color of links, shape of left navigation control, banner with gradient colours, etc).
5. Selecting colour theme based on client corporate branding
Now, this is normally the last step during this process. Ask client for their corporate branding (eg. logo) because a website is really an another realisation of client's corporate branding, hence colours have to match!
It also makes your life easier as well when you know what colour the website you're designing will be.
Conclusion
So, last but not least, this is really one of the most important steps in a professional website creation process. By skipping this phase we'll end-up getting confused of what we want with the website.
I've been there, I've done that,
Tommy
Subscribe to:
Posts (Atom)
