Method in construction is essential, D&G Building by Y
This is the third stage of the 5 Stages of Project Management series and is about the construction of the web site.
Assuming the other stages have been followed to reach this point, by now you will have an effective design brief outlining your client’s expectations and a design that has been agreed by your client. During the previous stage, you will have identified the key aspects of the design programme that need to be completed and have a good idea of how you are going to break down the construction phase into manageable chunks.
This stage is about building your design into a working site but it is important not to rush in too soon. Most people visiting this series will either be designers with experience behind them, or clients wishing to understand our design process. Neither groups are likely to want a detailed explanation of the construction phase (which you either know or don’t want to know about). If I’m wrong about this, let me know in the comments and I will add more posts on construction at a later date.
Learn to code
There is nothing more important than knowing your code and knowing what your code does. While software that does it for you can be useful, when things need debugging, you need to know what you have in front of you. All our websites are hand-coded from design. We do not use templates for our designs because we don’t see the point of making every web site look the same and we rarely use software to generate the code. This way, we know what we are developing and can ensure the code follows our semantic structure. It is essential for a developer to know what is under the bonnet (the ‘hood’) rather than relying on some random gobbledegook created by a third-party application.
Get your inclusions and structure ready
Make sure you get your site structure, directories, images and graphics ready before you start building the pages. We find this makes the construction go much more smoothly than if we’re suddenly starting to create new directories half-way through the site; suddenly the logic of the structure starts to fall apart when you do this and things get very confusing.
We like to build a site from bottom up. That way, you know the semantics of your code work and that each element you add is improving usability rather than making the whole site fall apart. If you test the site at each addition, you also know where you need to start debugging if things mess up.
Generally (but it does change sometimes for particular projects), we tend to use this order to get things right:
- Databases and back end applications
- Testing scripts in PHP or other code to test the applications work as expected
- Photography and site graphics, optimised and cropped to the right size with thumbnails
- Back-end administrative application for the site
- Front end pages in HTML, PHP, ASP, etc. with structure in place (no styling)
- CSS and styling
This helps you to debug problems as you go. If you knew the page was fine at step 4 but doesn’t work at step 5 then you know the first place to look for the problem is in the relationship between the back-end and the front-end code.
It is useful to build ‘dummy pages’. These are blank template pages for the site that have the complete layout ready to use. This saves time and energy repeating the same code for every page, particularly links and header code, much of which stays the same throughout the site. Page specific PHP, etc. will need to be linked from an external file.
Learn how to reuse code
There is no need to recode the same information time and time again. You can save a huge amount of time by pre-building code that you will use repeatedly. This, in turn, should feed through to saving cost for your clients. By reusing code that works every time, you will save time debugging code that has been misspelt or missed an ending ‘;’. You will have preformed, bespoke code ready to use when you need it on any particular site. Re-using code files on several pages also reduces server requests and page load because the code will already be available in the cache.
This does not mean you should copy another site and just change the words and pictures – this would bring you back to those awful templates you get with some software packages. Creating snippets of code that can be added into any site you are constructing to achieve a desired result is acceptable.
Don’t start populating pages until you are ready
Always make sure that your pages work and look as intended before starting to build each page of the site. This will save time later when you realise you’ve missed something, or need to change something on every page. Commenting code to mark the parts that need to change when building pages, is very useful (it’s also useful when you come back to a site to update it later!)
A final word
I have mentioned structure several times in this post. That is because structure and logic should be the foundations of this stage of the process. The discipline of creating your structure before you put pen to paper is priceless. Whether you are thinking about your site structure, the semantics of your code or the structure of your CSS files, make sure you think carefully about the order and how they fit together. It can make a massive difference. Then, stick to it!
If you are following an Agile design methodology, you might reiterate through these pages time and time again as you develop different aspects of your site design, adding new functionality.
This is the third part of the 5 Stages of project management series.
Rowers by Y
This is the second stage of the 5 Stages of Project Management series for web design projects. So far, we have taken an overview of the 5 stages as a whole and looked at how to write a successful design brief as part of the Inception stage. We are now ready to look at Stage 2, Design.
Before starting this stage, if you have completed the inception stage, you should have a well defined brief and understand the scope of the job. Without these, your project may end up with higher costs and delay because your expectations differ to those of your client. Now you are ready to evolve your ideas into some concepts to present to your client. For now, you are not actually building the site; you are designing concepts to a pre-construction stage that can be presented to and agreed by your client.
The brief may have given you a number of ideas for how to design the site and this stage is intended to consider these ideas, present the best to your client and identify the preferred option. But before you can do that you need to get answers to a few more questions and test your ideas against them.
Some things a web designer should consider:
You need to test your ideas against what users will expect to see. The users of the site are of absolute importance – if you put your navigation system at the bottom of the page, for example, is this what users will expect? Where will they expect to see the logo? There are a number of conventions that users will expect and you should consider these carefully before you decide to go against them.
You also need to consider user-specified items that should appear on the site, such as login widgets, video, interactive elements, forms, etc. How and where will these appear? How important are they for functionality, usability and ‘stickiness’ — the ability to keep users on the site. Create a hierarchy of these objects.
This is another important feature of any site and one that you should start designing into the site from the first drawing. In this sense, accessibility is about the colours you use — do they provide sufficient contrast? — The fonts you use, — are they easily legible? Is the content going to be overshadowed by that great picture you want to use? Are the link methods you are planning to use accessible? Have you structured content correctly, — is data stored in a table and is the table accessible?
The fundamentals of these questions will be put into practice when you start building the site. Creating the foundation of that best practice now, will make life a lot easier further down the line.
Plan the site
You should also have a clear idea of the content that will appear on the site, how pages will fit together — which page will link to which? This will help you to develop your site structure and the overall site map. This is essential for a large site but is also really useful for a small site and will help you to start structuring your Search Engine Optimisation as a core part of the page design.
Do you want to see my sketches?
Before you start anything electronically, you should use pen and paper to sketch your ideas. This gives you the opportunity to see how they look, modify them and hone them without spending hours getting Fireworks, Photoshop, Illustrator, etc. displaying what you intended and finding it doesn’t work. It also gives you some rough concepts to present to your client and seek feedback. You should only start committing them to electronic form when you have some clear ideas on paper.
Sketching a design allows you to play with where elements of a page should go to maximise visitors’ attention and optimise use of the hotspots on the page. It also allows you to ensure that visual elements work together.
What do you get out of following a design process?
There are very clear benefits to working through a design process (no matter how basic). It gives you a structure to work to and elements on which to focus; so, rather than jumping in and getting it wrong, you are able to concentrate on making the design achieve the results it expects before dedicating time and your client’s money to a concept that simply won’t work. Furthermore, it will help you to explain your design process to your client.
At the end of this stage you should be presenting your final mock-ups to your client for approval and to decide on which design to follow. This is much easier if you are able to describe the process you have followed and explain the reason you have made the decisions you have made.
The next stage in the five step project management cycle is construction. If you have developed your design well, you should have:
- A site structure and site map
- An understanding of the back-end data structure
- An agreed design to carry forward
- An understanding of what content will be required
Creative brief, building blocks of web development
This post is the second part of my 5 stages of project management series and covers the most important aspect of the first stage; writing a brief for a web design project.
Why is this important?
Web design projects are only ever successful if two things can be achieved at the same time:
- You provide your client with a site that fulfills the brief and they are satisfied with it; and
- You have correctly estimated the time it will take to complete the project and you have been adequately paid for the work you have done.
To achieve both of these, it is essential for you to have a clear understanding of what your client wants to achieve. One of the ways we do this at Redcentaur is to set out in a creative brief exactly what the client wants to get from their web site and the reasons for it. This helps us to identify the objectives of the site and to scope the work necessary.
Obviously, the completion of a creative brief is not the be-all-and-end-all of understanding your client and the goals of the web site. It is the starting point, from which there needs to be conversation and discussion to drill down into the responses to the brief.
There are two parts to a creative brief that are designed to give the web developer a clear understanding of the client, their needs, desires, strengths and weaknesses. Paying heed and due attention to the brief can pay dividends for both client and designer in reducing the risk of missing the mark at a later stage.
The creative brief
The key part of the brief is to understand the creative requirements of the client. This can be broken down into four sections. Remember, your client might not have a clear grasp of these expectations themselves. This section of the brief should help them to start pinning down some of these concepts if they haven’t already.
This section should give a general overview of the client and the project as they envisage it. It should state the purpose of the project from their perspective and identify any specific goals they have in mind.
Your client probably has a general idea of who the target audience is for their web site and this section provides you with an opportunity to identify the target market from the outset. By asking your client what they think the target audience is, what they care about and why they would visit the site, you are able to develop an in-depth understanding of your client’s aspirations and the factors that will measure the success of your web design.
In our experience, this is one of the most difficult factors to obtain from a client. Often clients do not have a clear idea of their message or how that message should be conveyed. This section is about what it is your client wants to say to their target audience and why it is important for that audience to see this message. This section may help the client to start defining this message.
In an age when the internet has brought huge amounts of information to every audience, competitive edge is king. You need to be clear on the things that set your client apart from the rest and what factors make your client a success where others in their field are not. This will help you to identify the key strengths of your client that will need to be the focus of the design.
The technical brief
The client may have an idea of the technical aspects of the site that need to be delivered. These can be as fundamental as site logos and photography, copy, contact forms, etc. or more technical issues, such as database integration. The technical brief should be tailored to the services that you are able to provide. This is a secondary part to the brief as much of the technical specification will be a result of the design as it develops, but it is important here to understand if the client has decided the site will form the backbone of its customer relationship management, for example.
Roles and responsibilities
Once you have some answers to these questions, you can start to flesh out what are the roles and responsibilities within the project — who will provide the site images, who will provide the copy…?
It is important to have an understanding of this so that you can accurately estimate the time required to complete the design — if you suddenly find that the client does not have suitable photography, you will have to spend time either getting the photographs or sourcing them; a cost that you may not have factored into your quote.
Once you are clear on the scope of the web site and have a clear brief, you can move on to the Design Phase.
Please leave a comment below to let us know how useful this is to you. Are there other aspects that you feel have not been tackled in our brief? Is this something you don’t find useful? How do you understand your client’s expectations?
Web development requires a structured project management
This is the first part of a series of posts detailing how Redcentaur manages web design projects for its clients. In this post is an overview of the five stages we use to develop web sites. Detail will be provided in future posts that link each of these stages together.
While steps used within these stages may vary widely from project to project, and depend largely on what is involved in each project, the stages themselves generally remain the same. This is because they are fairly generic in nature. However, do not underestimate the importance of good project management skills: they can save you and your clients money, time and unnecessary effort. Vandelay Design has identified 10 other basic principles for projects in the excellent post, Guide to finishing projects on time, which supports this series of posts quite neatly.
The one most important factor for project management is communication.
No project management post would be complete without mentioning the one most important factor for project management: communication. It is essential for any well-executed project for the project manager to talk to the client, the design team, the development team and anyone else involved in the project. If there are relatively few people involved, this becomes easier, but it is essential that the client and the team working on the website are in communication.
Two kinds of project management
Redcentaur uses a flexible approach to project management, which is based on the kind of project we are working on, the particular needs and structure of the project and the client we are working for.
Structured, hierarchical approach
With a cascading or “waterfall” approach to project management, each stage of the project, from Inception through to Completion is finished in order. This structured approach works well when a client has a limited budget or tight deadlines and we are able to set out clear revisions. This is useful in that it creates a delimited timeframe for completion and should provide the client with a cost limit. The downside is that it is not easy to revise work once a stage has been passed, so if a client changes their mind about some element, it can often mean starting over. The structure is fairly inflexible, which suits some clients better than others.
Flexible, “Agile” approach
The agile approach to project management is more flexible and has become a favourite for IT projects in recent years. An agile method takes a less structured approach and results in different aspects of the build being focused on by different teams. The project is developed through various iterations until a final version is adopted. While the approach is more flexible, there is less certainty about the costs involved as each stage may require several iterations. It also requires the client to be far more engaged in the process.
The five stages
Regardless of whether an agile or waterfall project management methodology is used, the basic principles of managing a web development project fall into five key project management stages. These are the stages used by Redcentaur.
- Inception: This is about gathering all of the information that will enable you to understand and define the brief, scope and specification with the client. This is probably one of the most important stages to get absolutely right as misunderstanding or misinterpretation at this stage will cause the rest of the project to go awry. This stage should also be used to start building some concepts and principles, drafts and sketches of ideas. Start building a plan of how the project should be carried forward. Make sure that you understand how your client wants to use the site and how their customers/visitors are going to be using the site; are these two requirements compatible?
- Gateway: meeting with clients to go through main ideas and agree principles and design ideas to take forward.
- Design: Building on the brief and scope that has already been defined, this stage is where you evolve your ideas and present them to the client. You might have several variations to begin with and with the client decide on a favoured option. During the design stage, you should also have a clear idea for information management, data storage and content management. Make sure you consider the site”s users – who are they and what will they expect to be able to do on the site; make sure you make it simple and easy to navigate, purchase or convert clicks to cash throughout the design.
- Gateway: agreeing with client the final mock-ups, design elements and data management systems/design.
- Construction: This is where you start getting your hands dirty with some coding and implement the agreed site design. Site construction is the phase that requires the most concentration. By the end of this stage, you should have an almost-ready-to-go web site for approval by the client that is based on the designs they have agreed. You will need to build any back-end functionality, content management systems, databases, etc. and integrate them into the site. Everything should be tested, tested again and tested to make sure the testing was correct! The more you test at this stage, the easier it will be to reach completion and handover without a headache. By the way, testing might be a good idea!
- Gateway: internal testing of integrated design on test servers to ensure the design works as intended.
- Completion: This is where you do some user testing of site on testing server to ensure that user feedback is completed. Reassess and tweek the design, data management, etc. where there are concerns. Assuming you have completed user assessments throughout, you should at this stage make sure that users see the site and use it as expected: ask people to go through certain tasks on the site to make sure that they understand how to do what you want them to do without difficulty or obstacles.
- Gateway: test with the clients to ensure they are happy with the finished design, ensuring any minor tweeks are resolved and approval is given.
- Close out: Uploading the completed site to the production servers, final on-line testing on the production server, hand-over to the client and completion of any search engine submissions, etc.
Each of these stages will be described in more detail in future posts that will form a series on project management. The second part is already available, How to write a successful brief.
I am sure that other designers use other methodologies and stages to manage their projects. I would be interested in hearing about them. Leave a comment below, with your views on how you manage projects, or how useful you have found this post.