Whiteboard Workflow with Microsoft Lens

Whiteboards are fantastic tools for thinking out loud. Whether you’re explaining ideas to an audience of thousands, or working through some problems in a conference room you’ve snaffled, starting with a big, blank whiteboard can help you get it all out there.

Once you’ve solved your problem on the whiteboard, you have a new problem of recording your work for later reference.

Plenty of approaches have been created with varying cost, complexity , and success. Electronic whiteboards can provide a printout of whatever you drew, but are expensive, require consumables, and the know-how to use the one you found in the room. Smartboards are neat and provide benefits to be sure, but amplify all the problems. Expensive to buy, complex to use.

All of these solutions take away from the biggest benefit of using a whiteboard - they’re simple! You grab a pen and go. No fuss, complete focus on solving your actual problem.

The rise of digital camera technology brought us to the verge of a fantastic solution - use your camera to take a photo. Download it to your computer and off you go. Perfect - except that your photos can be let down by bad lighting, poor focus, low resolution, and not having your camera around.

As smartphones and their integrated cameras have improved, the likelihood of you having a decent enough camera around to snap a whiteboard pic has increased. Even better, your tiny little computer can email it to anyone you want, or upload to your photo stash. Brilliant, but you’re still up against problems of lighting, focus, and having your final output being a photo of the thing you created, rather than the actual thing you created.

Straight from camera . You can see what's there, but lots of distractions including reflections, shadows, and noise/grain. It won't reproduce well.

Enter Microsoft Lens. It helps you to take a photo of your whiteboard (or piece of paper for that matter), and then automatically processes the photo to turn the content on the whiteboard into a digital drawing. It crops out everything that isn’t the whiteboard, kills reflections, cleans up the background so it is simply white, and enhances whatever it was you wrote up there.

 Microsoft Lens has a super simple interface. Point it at the whiteboard, hit the big red button.

Microsoft Lens has a super simple interface. Point it at the whiteboard, hit the big red button.

 

Once it’s done all that, you choose what you want to do with your picture. Native export options include the Microsoft Office apps, OneDrive, Photos app, and Mail.

 Export to all the things.

Export to all the things.

It gets even better - hidden down in the corner is the familiar share icon. Tap that and up pops the Share Sheet with all of your setup options including Basecamp. Pushing a whiteboard pic straight to the relevant Basecamp project, correctly named and commented is just fantastic. So many intermediate steps saved because it just works.

IMG_0965.PNG

Microsoft Lens is simple, free, and just works - all the things that you want from a whiteboard.

 Poor lighting didn't help this pic (some ugly shadows up the top that'd need to be cleaned up), but overall pretty good. Reflections are gone, the contrast is greatly improved, and the drawing itself has been sharpened up.

Poor lighting didn't help this pic (some ugly shadows up the top that'd need to be cleaned up), but overall pretty good. Reflections are gone, the contrast is greatly improved, and the drawing itself has been sharpened up.



Scott Adams on Learning

Scott Adams (of Dilbert fame) wrote about a perspective on learning/training that resonated strongly with me. 

"Investors know that diversifying a portfolio is the smart way to go. But does diversification have the same benefits when applied to learning? I think it does, because knowledge acts like a financial asset."

He's looking at the lifetime value of learning a new skill - especially those which may not be an absolute necessity immediately, but will pay off over time. 

I agree wholeheartedly. Taking the time to identify and pursue complementary skills has paid off many times over in my career. A key point here - some of the most useful complementary skills I've picked up at first glance have little to do with my day to day work, but in so many ways they make all the difference.   

What’s the point of storyboards?

Storyboards are a common deliverable for elearning projects - but don’t get caught up obsessing over the means rather than the end.

What is a storyboard?

Storyboards are a series of static illustrations used as a proxy for demonstrating a more complex medium such as film, or in our case, an elearning piece. Simple pictures stand in for what happens on screen. A good storyboard will help you to figure out the flow of your piece, and whether anything is missing.   

What are storyboards for?

Storyboards are a planning tool. They help you determine if your story makes sense. Are you introducting topics and ideas in a logical order? Does your arrangement of topics flow naturally from one idea to the next, or are there awkward gaps forcing the learner into impossible leaps of logic? Visualising your ideas in such a tangible way leads to rapid improvement. Design problems can be solved by adding, removing, or rearranging the screens. Because it’s all on paper, it’s fast and cheap. 

Learning designers need to be able to share their ideas to get feedback. Storyboards provide an easy format to demonstrate an idea, and just as importantly, are unintimidating for others to suggest changes or additions. 

Low Resolution

Initial storyboards should be low resolution. Only include enough detail to get the bones of the idea across. 

Adding lots of detail too early in the process makes storyboards worse, not better. The first problem is the additional time it takes to produce the storyboards. Additional polish and refinement certainly makes your storyboards look nicer, but are they getting your idea across any better than a simple line drawing? Probably not - so don’t waste the time. Storyboards exist only to help you along the way to a finished product, they’re not the actual product. Don’t overinvest in them with unnecessary detail.

The second problem is that all of that additional flourish and detail can distract the people who need to help you. Rather than being able to focus on the ideas you are presenting, the details become a distraction. You get sucked into debates about colour, typography, and specifics of images. All of that is important, but it’s not important right now. It’s not the job of the storyboard to help make decisions on anything other than the flow of your story. Only include enough detail to present your ideas, and that’s all you will get feedback on. Don’t give your well-meaning review team the opportunity to get distracted. 

High Resolution

I’ve seen plenty of examples of elearning storyboards, and plenty of them are what I would describe as “high resolution”. They often include full colour graphics, artwork that would be very close to the finished product (if approved), and line by line breakdowns of scripts.  They are trying to be a non-functional version of the finished product, and you can tell a huge amount of work has gone into producing them. 

I get that both clients and learning designers want to be confident about what the finished product will be, and we’d love to get that confidence as soon as possible. No one wants to be build or be given a finished product that’s not quite right and have to either do over, or live with something subpar. Review and feedback is an important process, and I’m a huge advocate for lots of both as early and often as possible. Here’s the the thing though - those great looking documents are giving you false confidence. You’re no closer to seeing an actual finished product. The learning piece still has to be built from scratch. 

I’m hardly the first person to riff on this. Jason Fried of Basecamp (formally 37Signals) has written on these exact ideas in relation to UI design for web applications. As elearning designers, UI for web applications is a huge part of our work whether we think of it in those terms or not. In 2006, Jason published “Getting Real”, and later released the book for free on the web. The included essay “Ignore Details Early On” is a consise reminder to focus on what matters, when it matters.  

In a post to Signal vs. Noise in 2008, Jason describes their UI design process, specially “Why we skip Photoshop”. He lists a number of reasons why building static mockups of an interface isn’t useful, compared to building a working prototype. It’s a quick read, and worth taking a look at. My summary though is that it’s a waste of time to do what is essentially the same work twice - once for the mockup/storyboard and once to make the actual product. 

A final reminder - I am definitely not suggesting that clients and/or stakeholders should have no input between seeing the rough storyboards and your delivery of the finished piece. Your stakeholders need to provide input and signoff in the design phase - but if you’re showing visuals, show an in-progress version of what will be the finished product. 

Storyboards are a tool to road test your ideas and story. Don’t get bogged down in the details - that’s a job for a different tool and time.