Author: Christy Tucker

6 Tips for Staying Productive While Working Remotely

I’ve been working at least partially from home since 2006. I love it, but it does require some deliberate effort.  I find that I’m actually more productive working remotely than I am working in an office. Here’s how I do it.

6 Tips for Staying Productive While Working Remotely

1. Set a Schedule

I set an alarm and get up in the morning like I always have. I have a normal schedule of when I work, when I take lunch, and when I stop in the afternoon. That schedule is somewhat fluid, and I often work an hour or two late in the evening after my daughter is in bed. I find that having a baseline schedule, even a flexible one, makes it easier to separate my work and personal life.

While many employers worry that remote workers will be too distracted by home and not get anything done during the work day, I find the opposite is true for me. I find it easy to get sucked into email or work when I should be “off” in the evening.

2. Get Dressed

I get dressed in real clothes every day; if I stay in my pajamas I’m not motivated. I wear comfy clothes, but I know people who wear nicer clothes even working from home because it helps their mindset. I once worked with a woman who wore a suit every day working from home for years because it was how she could be most productive.

3. Seek a Change of Scenery

I work from Panera or a coffee shop once or twice a week because the change of scenery is helpful. In fact, if I’m running a little behind on a project and need a really solid day of work to get caught up, taking my laptop to work from another location for a few hours is often the jolt I need.

4. Plan Face-to-face Interaction

Working remotely can be isolating. I’m happier if I schedule lunches with friends or former coworkers. Once or twice a month is enough for me, but you need to find the right balance of interaction for your personal needs. That face-to-face interaction is important, even for introverts like me.

5. Pay Attention to Your Natural Rhythms

I pay attention to my natural rhythms. For example, I know I have an easier time writing in the mornings, so that’s when I do my heaviest work. I leave boring administrative tasks like invoices and accounting for the early afternoon when I hit the post-lunch slump.

I take a 20 minute nap nearly every afternoon. I learned years ago that I’m more productive with the nap than without. If I don’t get a nap, I at least take 5-10 minutes to close my eyes and meditate or do progressive muscle relaxation. You might not need that, but listen to your body and figure out what you do need. Maybe you need a walk in the afternoons or a few minutes outside in the mornings. Maybe your most productive time is after lunch, so you can schedule your heaviest work for that time.

6. Keep a To Do List

I use Remember the Milk for my daily to do list. I use Google Calendar for my schedule, and I use various spreadsheets for specific projects. I am always more productive when I have a prioritized list of my tasks to complete. Breaking larger tasks into smaller ones also helps keep me on track.

Your tips?

If you currently work remotely (or have in the past), what did you find helpful in maintaining your productivity?

 

My 10 Most Viewed Blog Posts from 2017

My 10 Most Viewed Blog Posts from 2017

Based on the number of views, these are my top blog posts from 2017.

  1. Instructional Design Isn’t Dying. It’s Evolving. This post also earned an honorable mention in eLearning Learning’s MVP awards.
    Recently emerged monarch butterfly
  2. Scaffolding in Microlearning
    Screenshot from Duolingo
  3. 40+ Instructional Design and eLearning Books
    40+ Instructional Design and eLearning Books
  4. Converting Traditional Multiple Choice Questions to Scenario-Based Questions
    Converting to Scenario-Based Questions
  5. Managing the Complexity of Branching Scenarios
    Branching scenario with exponential growth
  6. How Long Should We Let Learners Go Down the Wrong Path?
  7. How to Start Creating Conversation-Driven eLearning
    Conversation-Driven eLearning
  8. How to Get Started Writing a Branching Scenario for Learning
    Get Started Writing Branching Scenarios
  9. What to Write First in Branching Scenarios
    What to Write First in Branching Scenarios
  10. Objections to Stories for Learning
    Objections to Stories for Learning

My post on Immediate and Delayed Consequences in Branching Scenarios didn’t make this top ten list, but it was a finalist for eLearning Learning’s MVP awards.

My goal for this year was to continue posting consistently, with a regular post every other week and a links post about once a month. I met that goal and published a total of 41 posts in 2017. I also wanted to continue to write about storytelling and scenarios, since that’s my favorite niche.

  • 26 regular posts
  • 15 links posts
  • 16 posts on storytelling and scenarios

Thanks to everyone who reads this blog, especially those who comment, share, and like my posts. Blogging would be a valuable tool for reflection even if it was just for myself, but it’s so rewarding to hear from people how my posts have helped them. I’m looking forward to more great conversations in 2018!

 

Branching Scenario Prototype in Twine

I built this branching scenario in the open source tool Twine. This scenario is moderately complex, with a total of 17 pages (or passages in Twine terminology) and 8 different endings. The ideal path has 5 decisions to reach the best conclusion.

I generally use Twine as a prototype for review and testing purposes. You can use Twine as the finished product though, especially if you do some formatting to make it look better. This is currently pretty rough (just text on a white background), but that’s OK for a prototype.

If you use Twine as a prototyping tool, you can build the finished version in Captivate, Storyline, or another tool of your choice.

Try the scenario out yourself by clicking below (the scenario will open in a new tab).

Click to open the scenario in a new tab.

This is the map of the entire scenario. You can see how many of the choices are reused.

Twine map of the entire scenario

Want to learn how I created this?

Read the previous posts in the series to see my process for creating this scenario.

 

Can’t get enough? Check out all of my posts on Storytelling and Scenarios.

 

 

ID and eLearning Links (12/3/17)

  • This is the link I send people to debunk the blanket claims about “people forget X% after Y time.” The reality is that how much people forget depends on who your audience is, what they’re learning, and how you train them.

    tags:training instructionaldesign research myth

    • The amount a learner will forget varies depending on many things. We as learning professionals will be more effective if we make decisions based on a deep understanding of how to minimize forgetting and enhance remembering.

    • To be specific, when we hear statements like, “People will forget 60% of what they learned within 7 days,” we should ignore such advice and instead reflect on our own superiority and good looks until we are decidedly pleased with ourselves.

    • Many of the experiments reviewed in this report showed clearly that learning methods matter. For example, in the Bahrick 1979 study, the best learning methods produced an average forgetting score of -29% forgetting, whereas the worst learning methods produced forgetting at 47%, a swing of 76% points.

  • Mini-scenarios and branching scenarios provide better assessment than traditional multiple choice, but this provides some other options for deeper assessment that can still be scored by a computer.

    tags:assessment scenario e-learning instructionaldesign feedback

Posted from Diigo. The rest of my favorite links are here.

Instructional Design and E-Learning Links

Writing Mistakes and Consequences

In my previous post, I explained how I write the ideal path for a branching scenario first. Once that is complete, I write the mistakes or errors and consequences for those choices.

First, Draft One Alternate Path to Its Conclusion

I start writing a single alternate path from beginning to end. This is the easiest way for me to create continuity in the narrative. I have the ideal path already created at this point, but you can see below that some choices are dead ends. Other choices are still marked as TBD for placeholders.

branching-ideal3

In this case, I’ll go back to the very first decision and start writing the mistakes and consequences. When I was drafting the ideal path, I knew the worst choice was to send a price estimate right away. I’ll start there and finish writing that path. In this case, this mistake is a big one that will result in an immediate failure and restart.

Sophie provides a fixed-price quote based on her limited information. Robert immediately accepts without negotiating, making Sophie wonder if her price was too low.

One month into the project, Sophie realizes what a terrible mistake she has made. She severely underestimated the scope of the project and the time required. She’s frustrated, and her client is frustrated at how long everything is taking. Sophie works long hours for weeks–so many hours that her effective hourly rate is much lower than usual.

Once the project is finished, Sophie vows to never give a price estimate again unless she has more information.

Draft Another Alternate Path (and Another, and Another…)

Once the first alternate path is written, go back to the beginning of the scenario. Find the first decision point that isn’t fully fleshed out, and start writing there. As before, try to write one complete path from start to finish.

In this example, I go back to the first choice. In my first pass at drafting the ideal path, I left a placeholder for “Some other OK choice TBD.” Now I need to create a third option and follow through on the consequences.

In this case, a partially correct choice would be to ask specific questions about the project. (The best choice is to ask high level questions about the business goals first, rather than getting into the details of the training too early.)

Sophie realizes she doesn’t have enough information to provide an accurate estimate. She asks Robert to clarify how long the courses actually are.

Robert replies with the details.

  • Course 1 is a half day (3.5 hours).
  • Course 2 is one day (about 6 hours).
  • Course 3 is two days (about 12-13 hours).
  • Course 4 is four days (about 26 hours).

What should Sophie do next?

[[Send Robert a price estimate for the whole project.|Send Robert a price estimate.]]
[[Ask Robert what level of eLearning he wants.]]
[[Ask Robert some high level questions about goals and budget.|Send Robert some client screening questions.]]

I continue like this with each choice until every path reaches its conclusion. I use my notes from my conversations with the SME and other stakeholders, plus any other research, to determine realistic consequences.

Good, Bad, and OK

By default, I usually aim for one choice that is the best (the ideal path), one choice that is clearly bad, and one choice that is OK or partially correct. If you’re stuck on what choices or mistakes to provide, try aiming for that pattern in each choice.

I do vary that, especially later in the scenario. By the time someone has made multiple good choices and is nearing the end of the ideal path, there might not be any terrible choices. It may be Good-OK-OK instead. If someone has made a large mistake, there might not be any good options; maybe the best recovery is an OK choice.

In Twine, I tag my choices as Good, Bad, and OK. In PowerPoint or other tools, I usually color code them in a flow chart as green, yellow/orange, and red. This helps me keep track of the structure. It also helps voice over or actors know the tone if this will be turned into audio or video later.

Let People Recover from Mistakes

Not every mistake should result in immediate failure and a restart. Just like in real life, sometimes people can recover from their mistakes. Branching scenarios can help people practice that skill of moving past an error.

In the example above, I want the learners to have a chance to realize they’re getting into the details too early and to back up. After asking about the length of the training, they can choose to ask high level questions instead. That gets them back to the ideal path.

Screenshot from Twine showing choices reused

Crossing Paths

I usually have some paths that cross, as shown in the screenshot above. This is one reason I really like Twine for drafting branching scenarios, regardless of what tool or format the final version will be.

Often, I create several ways to get to the same path or ending. Reusing some choices or endings helps reduce the complexity of the scenario.

After a Failure

You have several choices of what to do next after you reach a failed ending of a scenario.

  • Ask learners to restart and try the scenario again. This is what I did in the immediate failure of providing a price estimate with woefully inadequate information above.
  • Let learners back up one step so they can make a better choice.
  • Let learners go back to a milestone or checkpoint so they don’t have to redo the entire scenario. This is especially helpful in longer scenarios with many decision points.

I explain the pros and cons of these restart or retry options in detail in a previous post.

Testing and Revising

Once I have a complete draft of everything, I test the options, reading through each path and revising to fix anything broken. I prefer to do this testing at least a day after I finish the initial draft. It’s easier to see my mistakes when I have time to set it aside for a while and come back later.

I also review my notes. Did I include all of the mistakes that were critical to include? Does the flow make sense? Is there anything too repetitive that should be collapsed into a single path or rewritten?

After that, it’s ready for me to send for review by the SME and other stakeholders. I post the Twine version as an interactive prototype so they can test it themselves. I also export to Word so it’s easier to track changes in wording (especially with multiple reviewers).

Looking for more?

Check out my previous posts on branching scenarios: