Elearning best practices: Working with distributed production teams
Audience: Instructional designers interacting with distributed production teams.
Objective: List the best practices for interfacing with distributed production team.
Best practices: General communication
1. Premise: Distributed development is slower, requires greater process maturity, constant definition, stricter change management and over-communication.
2. Trust: Trust helps to better relationships, allow faster communication and reduce stress. It is a good practice to have an honest and open conversation about things that don't work.
3. Questions: Precise questions give an opportunity to the team member to clarify. You can ask team members to repeat or summarize so that both sides are clear. If you are making an assumption, it’s a good practice to state that.
4. Expectation: Finding out what works for the team and communicating what works for you could be a good way to begin working in a new project. For example, you might say: “I am a early-morning riser and am normally at work by 7 AM hence I would prefer to have team meetings in the mornings rather than late nights. Does that work for you as well?” “As a best practice, I like to document all our decisions in an email. Are comfortable receiving this process?”
5. Relationship: Building relationships helps all the above and makes working fun. A friendly chat or email can is all that it takes to know the people behind the roles.
6. Cultural dimensions: Understanding cultural differences if the production team is based in a country different than yours eases communication.
Telephone:
1. Accents: Talk slowly and ask your production team counterpart to do the same if you have trouble understanding what they are saying.
2. Tone: Make an effort to sound friendly. In the absence of visual clues, your voice becomes “you” for the listener.
3. Snags: While communicating long-distance across countries, be prepared to sometimes experience technical snags during telecoms - hearing an echo, voice cracking up and low volume are just some of the snags that you might face.
Mail:
1. Language: Make sure your language is clear and concise. Use short sentences and simple language.
2. Format: Instead of using a lengthy paragraph in conveying information, use ordered/unordered lists.
3. Over-communication: Often mails or production related documents are not consistently understood across the teams. Consider picking up the phone to talk to your counterpart (don’t forget the time difference, if it exists) to clarify or sort out questions...it generally works. Also, it is a good practice to document and share your conversations so that you, your counterpart and everyone else in the team is well-aware of the decisions made.
Chat:
1. Clarification: You might use chat for questions that need immediate response or to set instant meeting.
2. Relationship building: You could use chat as way to get to know their teams better. A good occasion to break the ice is when you see your team member online way beyond office hours or to enquire about the holiday that she/he just took.
Best practices: Beginning a new project
1. If you are joining a project that is already in process:
a. Study the approved prototype, if it exists. The project interactions are built by the production teams based on the design and scope presented in the approved prototype. Don’t forget to notice the global links to be used for the project that are presented in the prototype.
b. Familiarize yourself with the project scripting template and the interactions that are being used for the project.
c. Pay special attention to where the content gets placed in the various interactions. You can request your production team lead to give you a walk-through on all the interactions that are being used for the project.
d. Take note of the project scripting style guide. If it does not exist, consider creating one.
2. Know the production team lingo--.fla, .swf, externalized content, html.
3. Know the difference between SCO and multi-page SCO
4. Know the time-difference.
Best practices: Scripting
1. Visualize your course:
a. Asssessments:
- Feedback
- Number of attempts
- What happens if the learner fails on all attempts?
b. Interactivities:
- What would a learner to do after she/he clicks the interactivity?
- Does the learner have clear instructions for the interactivity in the beginning and at the end.
- Has the interactivity been described clearly? Important points to bear in mind while writing interactivity descriptions:
· Be specific where you need to be, let the team handle the creative aspect e.g. Keep the space between the cars consistent.
· Let the team know clearly what you definitely need/don’t need to see in the interactivity.
2. Are there any double spaces? Spelling errors? The production team is not expected to correct them.
3. Images:
a. Resolution (800x600, 1024x768), Color (True, 16 bit), Format (.png, .bmp, .jpg)
b. Good quality screenshots.
c. If taking the images yourself, remember the above factors. If the client is providing the screenshots, pass on the information to them.
d. Contact the Creative Director or the production team lead for this information.
e. Use the same operating system and retain its settings while taking all the images.
f. More specifically for application training, take images for all the steps and the effects in that step (if you care for that level of details). For example, if you want to show the change in state when a user scrolls over a dropdown menu, provide all the images in the “over”state. If you aren’t able to do so for all instances, the production team will be able to doctor the screenshot based on the “over”state for other instances but the quality of the interactivity gets affected.
g. If the screenshot needs to be manipulated, the production team expects clear instructions on the change. If the data needs to be manipulated, clearly state what the team needs to change. E.g. If the names of the registered vehicle users needs to be changed, mention clearly how those names need to be changed.
h. Clearly mention the image filenames and provide the screenshots in the script.
i. Provide the images (using the same filename as in the script) to the team in a separate folder when the script is released for production.
4. Resources:
a. Provide the reference to the Resources in the script.
b. Provide the Resources in the same folder as the images folder.
5. Production team leads should ask for the draft script so that they can have a better feel of the content. If they don’t ask, provide them anyway to help them plan but be sure to mention clearly that the script is draft and not to be used for production purposes.
6. Final step before releasing the script for production, check if your script bundle has:
a. Scripts for all lessons
b. All glossary terms within the script have description
c. All images
d. All resources
e. Images and resources are referenced clearly and consistently in the script—when you change an image filename, make sure the reference to the image in the script is also made
f. Course description
g. Course information
Best practices: Releasing scripts for production
1. Adopt consistent practices for checking in and checking out documents.
2. Find out where to upload the resources, audio files and images and make sure it is known to the entire team.
3. While releasing the script for production, send the mail to the project team alias announcing the release of the course. Send the location details where you have placed the raw course content.
Best practices: Internal reviews
When the production team sends you and other design team members url, usename and password to access the course:
1. Use a standardized format to log all feedback and comments.
2. Be very specific: When logging an issue, be sure to mention the exact location (Module/Page/Paragraph/Sentence). Mention the original sentence and then mention the changed sentence.
E.g.: Module 2>Lesson 5> Page 2> 1st paragraph> Last sentence> Change: “Finally, in some countries, like Germany, we pursue industry-standard offerings.” to: “Some countries like Germany pursue industry-standard offerings.”
No matter which application you use be sure to cover all the above points as incomplete information could mean time spent in simply locating the issue. This also leads to a lot of frustration on the production side.
3. For changes that need to be implemented for the entire course, describe the change under the header “GLOBAL”
4. For exceptions to the global entries, write “EXCEPTION: ”
5. For any issue, describe the issue as clearly as we can, mention why it is wrong (so that if it is an ongoing project, the team is better geared for future courses), and provide a fix.
6. Do not provide the production team options for fixes—asking him/her to make the decision. As an instructional designer, it is highly recommended that you work out the best solution for the issue and ask the production team to implement the same. If we need some inputs from the production team to make the decision, connect with the production lead to collect that information but make the final call. Being client facing, instructional designers are better geared to make these decisions.
7. “Capitalize” can be misunderstood as “capitalize the entire word”. Hence be sure to address this confusion when making an entry. You may write “initial capitalize ’Liquidity Management’” or “Change “liquidity management” to “Liquidity Management””
8. While making entries, do not add new format styles to emphasize a text change—it may confuse the team to mean that the text format needs to change as well.
9. Sometimes when the change in sentence is just a word, it saves time for the production team to have that exact fix. We can emphasize the change by using a different font color.
E.g. Change “liquidity management” to “Liquidity Management””
Best practices: Directing client feedback
1. On receiving client feedback during alpha, beta, pre-live process, the instructional designer must review client feedback and discuss outstanding or unclear issues with the client.
2. That done, the instructional designer can add more information to the client entry for change to ensure that the production team has clear directions. For example, if the client has not written the page number of the issue or hasn’t articulated the issue well, the instructional designer may need to edit the entry to ensure its clarity to the production team.
3. For those issues that are logged by the client and later found to non-issues, clearly state that the production team does not need to take any action against the entry.
For example: The instructional designer may write, “NO CHANGE. IGNORE THIS ENTRY”.
4. If you heard some positive feedback from the client, be sure to share it with production team as well.
Course goes Live!
1. Don’t forget to congratulate the team and each other.
2. Your project team might share the lessons learnt and best practices experienced in the course. Keep your observations ready!
Objective: List the best practices for interfacing with distributed production team.
Best practices: General communication
1. Premise: Distributed development is slower, requires greater process maturity, constant definition, stricter change management and over-communication.
2. Trust: Trust helps to better relationships, allow faster communication and reduce stress. It is a good practice to have an honest and open conversation about things that don't work.
3. Questions: Precise questions give an opportunity to the team member to clarify. You can ask team members to repeat or summarize so that both sides are clear. If you are making an assumption, it’s a good practice to state that.
4. Expectation: Finding out what works for the team and communicating what works for you could be a good way to begin working in a new project. For example, you might say: “I am a early-morning riser and am normally at work by 7 AM hence I would prefer to have team meetings in the mornings rather than late nights. Does that work for you as well?” “As a best practice, I like to document all our decisions in an email. Are comfortable receiving this process?”
5. Relationship: Building relationships helps all the above and makes working fun. A friendly chat or email can is all that it takes to know the people behind the roles.
6. Cultural dimensions: Understanding cultural differences if the production team is based in a country different than yours eases communication.
Telephone:
1. Accents: Talk slowly and ask your production team counterpart to do the same if you have trouble understanding what they are saying.
2. Tone: Make an effort to sound friendly. In the absence of visual clues, your voice becomes “you” for the listener.
3. Snags: While communicating long-distance across countries, be prepared to sometimes experience technical snags during telecoms - hearing an echo, voice cracking up and low volume are just some of the snags that you might face.
Mail:
1. Language: Make sure your language is clear and concise. Use short sentences and simple language.
2. Format: Instead of using a lengthy paragraph in conveying information, use ordered/unordered lists.
3. Over-communication: Often mails or production related documents are not consistently understood across the teams. Consider picking up the phone to talk to your counterpart (don’t forget the time difference, if it exists) to clarify or sort out questions...it generally works. Also, it is a good practice to document and share your conversations so that you, your counterpart and everyone else in the team is well-aware of the decisions made.
Chat:
1. Clarification: You might use chat for questions that need immediate response or to set instant meeting.
2. Relationship building: You could use chat as way to get to know their teams better. A good occasion to break the ice is when you see your team member online way beyond office hours or to enquire about the holiday that she/he just took.
Best practices: Beginning a new project
1. If you are joining a project that is already in process:
a. Study the approved prototype, if it exists. The project interactions are built by the production teams based on the design and scope presented in the approved prototype. Don’t forget to notice the global links to be used for the project that are presented in the prototype.
b. Familiarize yourself with the project scripting template and the interactions that are being used for the project.
c. Pay special attention to where the content gets placed in the various interactions. You can request your production team lead to give you a walk-through on all the interactions that are being used for the project.
d. Take note of the project scripting style guide. If it does not exist, consider creating one.
2. Know the production team lingo--.fla, .swf, externalized content, html.
3. Know the difference between SCO and multi-page SCO
4. Know the time-difference.
Best practices: Scripting
1. Visualize your course:
a. Asssessments:
- Feedback
- Number of attempts
- What happens if the learner fails on all attempts?
b. Interactivities:
- What would a learner to do after she/he clicks the interactivity?
- Does the learner have clear instructions for the interactivity in the beginning and at the end.
- Has the interactivity been described clearly? Important points to bear in mind while writing interactivity descriptions:
· Be specific where you need to be, let the team handle the creative aspect e.g. Keep the space between the cars consistent.
· Let the team know clearly what you definitely need/don’t need to see in the interactivity.
2. Are there any double spaces? Spelling errors? The production team is not expected to correct them.
3. Images:
a. Resolution (800x600, 1024x768), Color (True, 16 bit), Format (.png, .bmp, .jpg)
b. Good quality screenshots.
c. If taking the images yourself, remember the above factors. If the client is providing the screenshots, pass on the information to them.
d. Contact the Creative Director or the production team lead for this information.
e. Use the same operating system and retain its settings while taking all the images.
f. More specifically for application training, take images for all the steps and the effects in that step (if you care for that level of details). For example, if you want to show the change in state when a user scrolls over a dropdown menu, provide all the images in the “over”state. If you aren’t able to do so for all instances, the production team will be able to doctor the screenshot based on the “over”state for other instances but the quality of the interactivity gets affected.
g. If the screenshot needs to be manipulated, the production team expects clear instructions on the change. If the data needs to be manipulated, clearly state what the team needs to change. E.g. If the names of the registered vehicle users needs to be changed, mention clearly how those names need to be changed.
h. Clearly mention the image filenames and provide the screenshots in the script.
i. Provide the images (using the same filename as in the script) to the team in a separate folder when the script is released for production.
4. Resources:
a. Provide the reference to the Resources in the script.
b. Provide the Resources in the same folder as the images folder.
5. Production team leads should ask for the draft script so that they can have a better feel of the content. If they don’t ask, provide them anyway to help them plan but be sure to mention clearly that the script is draft and not to be used for production purposes.
6. Final step before releasing the script for production, check if your script bundle has:
a. Scripts for all lessons
b. All glossary terms within the script have description
c. All images
d. All resources
e. Images and resources are referenced clearly and consistently in the script—when you change an image filename, make sure the reference to the image in the script is also made
f. Course description
g. Course information
Best practices: Releasing scripts for production
1. Adopt consistent practices for checking in and checking out documents.
2. Find out where to upload the resources, audio files and images and make sure it is known to the entire team.
3. While releasing the script for production, send the mail to the project team alias announcing the release of the course. Send the location details where you have placed the raw course content.
Best practices: Internal reviews
When the production team sends you and other design team members url, usename and password to access the course:
1. Use a standardized format to log all feedback and comments.
2. Be very specific: When logging an issue, be sure to mention the exact location (Module/Page/Paragraph/Sentence). Mention the original sentence and then mention the changed sentence.
E.g.: Module 2>Lesson 5> Page 2> 1st paragraph> Last sentence> Change: “Finally, in some countries, like Germany, we pursue industry-standard offerings.” to: “Some countries like Germany pursue industry-standard offerings.”
No matter which application you use be sure to cover all the above points as incomplete information could mean time spent in simply locating the issue. This also leads to a lot of frustration on the production side.
3. For changes that need to be implemented for the entire course, describe the change under the header “GLOBAL”
4. For exceptions to the global entries, write “EXCEPTION: ”
5. For any issue, describe the issue as clearly as we can, mention why it is wrong (so that if it is an ongoing project, the team is better geared for future courses), and provide a fix.
6. Do not provide the production team options for fixes—asking him/her to make the decision. As an instructional designer, it is highly recommended that you work out the best solution for the issue and ask the production team to implement the same. If we need some inputs from the production team to make the decision, connect with the production lead to collect that information but make the final call. Being client facing, instructional designers are better geared to make these decisions.
7. “Capitalize” can be misunderstood as “capitalize the entire word”. Hence be sure to address this confusion when making an entry. You may write “initial capitalize ’Liquidity Management’” or “Change “liquidity management” to “Liquidity Management””
8. While making entries, do not add new format styles to emphasize a text change—it may confuse the team to mean that the text format needs to change as well.
9. Sometimes when the change in sentence is just a word, it saves time for the production team to have that exact fix. We can emphasize the change by using a different font color.
E.g. Change “liquidity management” to “Liquidity Management””
Best practices: Directing client feedback
1. On receiving client feedback during alpha, beta, pre-live process, the instructional designer must review client feedback and discuss outstanding or unclear issues with the client.
2. That done, the instructional designer can add more information to the client entry for change to ensure that the production team has clear directions. For example, if the client has not written the page number of the issue or hasn’t articulated the issue well, the instructional designer may need to edit the entry to ensure its clarity to the production team.
3. For those issues that are logged by the client and later found to non-issues, clearly state that the production team does not need to take any action against the entry.
For example: The instructional designer may write, “NO CHANGE. IGNORE THIS ENTRY”.
4. If you heard some positive feedback from the client, be sure to share it with production team as well.
Course goes Live!
1. Don’t forget to congratulate the team and each other.
2. Your project team might share the lessons learnt and best practices experienced in the course. Keep your observations ready!
Comments
askk if you don't mind. I was interested to fid out how you center yourself and
clear your thoughts before writing. I've had a hard time
clearing myy thoughts in getting my thoughts out there.
I truly do take pleasure in wrriting but it just
seems like thee first 10 to 15 minutes are wasted just trying to figure out how tto
begin. Any recommendations or tips? Thanks!
my web-site - mobile development
ones time due to this fantastic read!! I definitely
enjoyed every bit of it and I have you bookmarked to look at new information
on your website.
Here is my web site ... Agile mobile development