In the professional arena, Web design and development projects are very seldom solo endeavors. Instead, most professional Web projects are team efforts. Therefore, Web designers must be able to collaborate with others as a productive member of a team with a common objective.
Working productively as a member of a team is about more than simply showing up for meetings. In fact, it’s about more than just doing your share of the work. It’s about working together to overcome individual weaknesses and enhance individual strengths.
A good team player understands that productive teams are more than the sum of their parts. That is, if we assume that an average individual’s productivity can be quantified by the variable p, then we should expect the total productivity of an effective four-member team to be well in excess of 4p. This is because a good team works together to support its members and helps them bring out their best.
The team project is intended to give you a taste of what it’s like to work as a member of a Web design team. In all likelihood, you will find that it has its ups and its downs. The project is therefore designed to help you take advantage of the ups and work through the downs.
The team project will occupy you to varying degrees throughout the semester. To help ensure that each team manages their time in a manner that will allow successful completion of the project, there will be numerous checkpoints with deliverables due at various points throughout the semester. Unless I announce otherwise, these checkpoint deadlines will be considered non-essential. Failure to meet them will reflect poorly on your team’s performance, but the penalty for a single missed deadline will not be catastrophic. Consistent failure to meet these deadlines, however, will likely have a significant impact on your team’s grade.
An important difference between groups and teams is that teams are more formally structured. Effective and productive teams are much more likely to arise from a process that seeks to distribute talents among teams than from a process that encourages friends to band together.
To this end, I intend to assign students to teams, not to let students form their own teams. This process will be completed in class.
Teams will consist of three to five students (with four being the target number), and will be formed as early in the semester as possible.
Once formed, teams will remain together throughout the semester. Part of learning to work together as part of a team is learning how to overcome your differences and reach a consensus. I will be available throughout the semester to assist teams in these endeavors, but breaking up or reassigning teams will generally not be an option. After all, in the professional world you seldom have complete control over your teammates and must learn to work with them instead.
One of the first things your team must do is identify an acceptable project. This project idea may arise internally as the personal vision of a team member, or it may be found externally by networking with friends, family and employers or the time-honored tradition of “pounding the pavement.” Regardless of where you find your idea, it’s important to begin by ensuring that all members of the team are interested in and excited by it.
I encourage teams to identify and select practical, real-world projects. If you can find a company, organization or individual who could benefit from your efforts, that will give you excellent experience working with a client. Even if your team chooses to pursue the personal vision of a team member, that team member must be willing to serve double-duty as both fully contributing team member and client. In short, whatever project you choose, there must be at least one individual who can be identified as the client or stakeholder.
My recommendation is that you think carefully about the stakeholder when deciding which project to undertake. External stakeholders are generally preferable to a team member acting as stakeholder. Stakeholders located near enough to campus to allow for face-to-face meetings are generally preferable to those accessible only by phone and e-mail. A stakeholder who is excited about and committed to the project is highly preferable to one who needs to be convinced that the project is a good idea.
Projects may involve the creation of a Web site from scratch or the redesign of an existing Web site, but your choice of project must be suitably ambitious to occupy your whole team for the entire semester. If you find a project that appeals to the group, yet seems too ambitious to tackle in a single semester, consider “carving out” a project as the first phase of some larger ongoing project (that will be completed after the course). If you choose this approach, however, be careful to define the parameters clearly so that all team members understand the objectives for the team project and what, if any, obligations will persist once the course ends.
I am not placing any particular minimum or maximum on the number of pages a project may involve, since a 100 page site with pre-existing content and a similar design across all pages could conceivably be far less work than a 10 page site built from scratch using differing designs for each page. As a team, you will need to evaluate each project idea to ensure that you can define the project parameters in a way that makes it sufficiently challenging yet achievable.
Previous semesters’ teams have submitted comments at the end of the semester reflecting the lessons they learned while completing their projects. You may wish to review their reports of Lessons Learned both before you begin and as you progress through your own Team Project, as the issues they encountered are very likely to be similar to those you will encounter.
The reason you are required to read several textbooks during the first half of the semester is to enhance your knowledge and capabilities as a Web designed. Toward that end, you will be expected to apply the knowledge you acquire from these books toward your Team Project.
As you read each book, take appropriate notes and consider how that material might be applied to your Team Project. As you apply material from each book to your project, make note of the fact. These notes will make it easier to write your final report at the end of the project.
Teams will be expected to work through their differences in the interest of achieving their objectives. Individuals will be expected to contribute their fair share of the effort necessary for the team to accomplish that.
I strongly recommend that each team delegate the necessary tasks in a manner that involves all team members in all phases of the project. This is much more likely to result in an enjoyable and successful experience than a “relay race” approach in which each team member does their part and then passes the results on to the next team member. Think of it as the difference between a braided rope and a chain. If one link in a chain breaks, the entire chain fails. However, if one strand of a braided rope breaks, the remaining strands can often hold on until the job is done!
As with any group endeavor, there is a chance that an individual may not be performing in a manner satisfactory to their teammates. If such a situation should arise and the team cannot resolve the issue internally, the other members of the team may, with my prior permission, vote to penalize that non-performing team member (or “free rider”) by having participation points deducted from the free rider’s grade.
If the problems with the free rider persist subsequent to the first penalty, the other members of the team may, again with my prior permission, vote on whether to exclude the free rider from the team. If a majority of the team members vote to exclude the free rider, the excluded student will be required to complete a separate team project on their own.
Obviously, when a team votes to exclude a member, they will complete the project shorthanded. As such, exclusion should be used only as a last resort when the excluded member is not contributing anything to the team already.
Please note that the process of excluding a free rider from a team must be initiated at least 120 hours prior to the team’s scheduled final presentation. However, if a team member has already been penalized prior to this deadline, it is possible that I will allow the team to vote to exclude that member for continuing non-performance after this deadline, even if that exclusion makes it effectively impossible for the excluded team member to complete a project on their own. Therefore, as a team you need to be sure to act on problems as soon as they arise. And, as a team member, if your team decides to take action against you, you need to take the initial warning very seriously and do everything possible to fulfill your responsibilities right up until the final presentation is made to avoid being excluded at the last minute.
It is important to note that while I prefer to operate through the mechanisms outlined above and assign the same project grade to all members of a team, I do reserve the right to assign different grades to different members of the same team when I believe that exceptional circumstances warrant such an action.
Due Thursday, February 7th in class
The first checkpoint submission centers around creating a team resumé. Its purpose is to let you (and me) get a sense of what talents and interests your individual members bring to the team and what you’re currently thinking with respect to the project.
While the resulting documents are expected to be reasonably formal and professional, I am not going to dictate a specific format. There is no need for fancy bindings or covers, but you should produce something that your team would feel comfortable sharing with someone who was thinking about hiring you for a project.
Since you may, in fact, find that you have the need for just such a document, and since the requirements will result in the inclusion of information that you might not necessarily wish to share with a potential client, it is acceptable for your checkpoint submission to consist of multiple documents, as long as those documents are formatted in a consistent way and subdivided in a rational and meaningful manner.
In short, as long as you meet the requirements outlined below, I am allowing you the freedom to do so in whatever manner best suits the needs and style of your team.
The checkpoint submission must satisfy the following minimum requirements:
A sample of this checkpoint submitted in a previous semester is available for you to review. The requirements were somewhat different when it was written, but it does demonstrate the level of thoroughness and professionalism I am ideally seeking.
You may also find it helpful at this point to consider some of the lessons other teams in previous semesters have learned as they completed the project.
Going beyond these requirements is perfectly acceptable if you feel it is warranted.
Due Thursday, February 21st in class
The second checkpoint submission centers around generating a product plan that sets the direction for your project. This is the point by which you will need to have settled on one idea and developed your plan for how to realize that idea on the Web.
For this checkpoint submission, I recommend that you consider the guidance available in section 1 of the Cohen book. You may follow the boilerplates she provides throughout the section or write in accordance with your own format. However, the end result should be thorough and professional in its coverage and its presentation. Again, fancy bindings and covers are not necessary, but careful proofreading and polished formatting are.
Different teams and different project ideas are going to result in different needs for the product plans, so I am not going to specify a specific format. However, I will expect your product plan to include at least the following sections:
Depending upon the nature of your project, you may find it necessary to include additional sections in your product plan. These sections may include, but are not limited to, sections describing your expected revenue model and your budget.
There will not likely be much need for a section describing your projected schedule, since I will be largely setting your schedule throughout the semester. However, if you expect your project to continue beyond the end of the course, feel free to provide a section describing the overall schedule of what you intend to accomplish within the course and what you expect to do after the course is complete.
A sample of this checkpoint submitted in a previous semester is available for you to review. The requirements were somewhat different when it was written, but it does demonstrate the level of thoroughness and professionalism I am ideally seeking.
As always, these are minimum requirements; you are welcome to go above and beyond them if you feel your situation warrants.
Due Thursday, March 21st in class
The primary objective of the third checkpoint is to establish the underlying structure of your project site. By the time you submit this checkpoint, your design process should be well underway. Be sure to reference the documents you produced for the second checkpoint as you work toward the third checkpoint. This will help ensure that your design evolves in a manner consistent with your overall plan for the site.
For this checkpoint submission, you may want to reference the guidance available in section 2 of the Cohen book. You may find Cohen’s advice a helpful place to start, but you are likely to find that you need to go well beyond the boilerplates she provides. However you choose to proceed, the end result should be thorough and professional in its coverage and its presentation. As before, fancy bindings and covers are not necessary, but careful proofreading and polished formatting are.
As with the product plans, different teams and different project ideas are going to have different design needs, so I have not specified a format. However, I will expect your checkpoint submission to include at least the following sections:
A sample of this checkpoint submitted in a previous semester is available for you to review. The requirements were somewhat different when it was written, but it does demonstrate the level of thoroughness and professionalism I am ideally seeking.
As always, these are minimum requirements; you are welcome to go above and beyond them if you feel your situation warrants.
Due Thursday, April 11th in class
The primary objective of the fourth checkpoint is to finalize your design and set the stage for your team to actually begin the process of building your project site. Be sure to reference the documents you produced for the previous checkpoints as you work to complete this checkpoint. Bear in mind that these are meant to be simply checkpoints along the way in a single cohesive project, and resist the temptation to treat them as individual projects.
This checkpoint submission will likely require a bit more creativity than the previous checkpoints. If you have been utilizing the Cohen text, you will find that she offers far less specific guidance. However, feel free to use that guidance as a starting point. Hopefully, by this point in the semester, the individual expertise of your team members will be starting to come “on line” as they finish their individual projects. As before, the end result of this checkpoint should be thorough and professional in its coverage and its presentation. Fancy bindings and covers are not necessary, but careful proofreading and polished formatting are.
At this point, each team will likely be so deeply involved in the specifics of their project that it makes virtually no sense to dictate a specific format for this checkpoint. Instead, I will endeavor to describe what I expect in a general sense and let each team decide how best to implement those objectives for their project.
The submission for this checkpoint should be the culmination of your design process. I will expect it to explain how you intend to realize the goals and implement the features stated in your second checkpoint submission. I will also expect it to clearly lay out a plan for building a site that is consistent with the information architecture, labeling and navigational systems presented in your third checkpoint submission.
You may use any forms of documentation that you feel will work for your needs, but you should at least include page grids (or schematics/wireframes), page designs and coding guidelines.
Page grids establish the basis for the page layouts you intend to use. There should be one page grid for each distinct page layout you intend to use.
Page designs describe the presentational specifics for a page. Typically, there will be one page design for each page grid, but that’s not absolutely necessary. One page design may suffice for your whole site, or you may find it necessary to associate different page designs with a single page grid. Include as many details as possible in the page design with respect to color, spacing, typography, imagery and any other aspects of the design that need to be recorded.
Coding guidelines lay out guidance for your team members to follow as they begin building the pages of the site so that there is consistency of coding techniques and formatting styles throughout the site. The more thoroughly defined your coding guidelines are, the more consistent the code produced by different team members will be. This, in turn, will make it much easier for team members to read, understand and (if necessary) fix the code of others.
In short, if you do your page grids, page designs and coding guidelines properly, an outsider should be able to join your team at any point and immediately become a useful contributor to the project by producing pages. In other words, the combination of these three documents should provide all the information needed to implement the pages of your site, with the exception of the actual content.
This checkpoint should also contain an update on the progress of your usability analysis, using prototypes or paper mock-ups to test the usabilty of your design with at least one representative member of your site’s target audience.
Finally, this checkpoint should continue to update me with regards to how you are applying the material from the assigned readings toward your work on the project. The more carefully you consider this aspect of the checkpoint, the easier it will be to complete this section of the final report.
As always, these are minimum requirements; you are welcome to go above and beyond them if you feel your situation warrants.
A sample of this checkpoint submitted in a previous semester is available for you to review. The requirements were somewhat different when it was written, but it does demonstrate the level of thoroughness and professionalism I am ideally seeking.
Upon completion of this checkpoint, your team should begin implementing your site in preparation for your team project presentation. These presentations will begin in class on Tuesday, May 1st.
Due in class as follows:
Schedule to be announced
You must provide me with a link to your project site’s current home page at least 24 hours prior to your scheduled presentation (though you are free to continue making changes to the site itself).
Each team will have 20 minutes of class time to present the end results of their project to the class. You may choose to present as a team, or you may elect a single representative to make the presentation on behalf of the team. Presentations that occupy significantly more or less than the allocated 20 minutes will be penalized in the grading.
Each presentation should cover at least the following points:
After each team’s presentation, there will be up to 5 minutes available for questions, suggestions and/or critiques from the rest of the class (and me, of course!). During this phase, all team members will be expected to be available for questions, even if they did not participate in the presentation itself.
Due Wednesday, May 8th no later than noon
No late submissions will be accepted!
The final report should be essentially a formalized, written version of the presentation described above. It should cover all the points outlined for the presentation above, with two additional areas of discussion: voting and team member statements. It will also involve the submission of your lessons learned coded in HTML.
Each team will be allocated one vote in each of four categories. The categories correspond to the four assigned textbooks from the first half of the semester.
For each of these four textbooks, decide which of the completed Team Projects best demonstrates adherence to the primary theme(s) of that book. Work from the notes you took during the team presentations, any questions you may have asked, and your own individual examination of the other teams’ sites.
Since you must cast your votes as a team, it is important that you come to consensus before proceeding. Please note that a team may not cast a vote for itself, but you may vote for the same team in more than one category if you feel doing so is warranted. Once you are ready to cast your votes, be sure to thoroughly explain the rationale behind each vote your team casts. Your votes will not be considered in your grade, but the quality of your explanations will be.
Each team member will add a personal statement explaining what they learned from the course and the project and how they were able to apply their abilities and expertise (both pre-existing and new-found) to the team’s efforts. These statements should go into significantly greater depth and detail than the team presentation did.
A sample of the final report submitted in a previous semester is available for you to review. The requirements were significantly different when it was written, but it does demonstrate the level of thoroughness and professionalism I am ideally seeking.
The lessons learned section of your final report should also be submitted as an attachment to an e-mail message. Please code up the lessons learned as one or more HTML lists (unordered, ordered, or definition), nested if necessary. Just the HTML for the list(s) is sufficient; it does not need to be a complete HTML document. This will allow me to easily include your lessons learned in the course website for the benefit of future students.
Here are links to the team projects: