Half Engineer / Half Business Guy

Starting Your Business And Becoming An Entrepreneur

Tag: UI

Building A Screencast (“Canned”) Demo Video

WHY WOULD YOU NEED A Screencast Demo?

There are many places you’ll want to live demo your product, but also a number of situations where a demo video will be preferable.

Examples include a walk-through video on your website’s front page for first-time users of your site, or an investor pitch before you’re comfortable running the working version of your product live.

At a very early stage, if you don’t have your web product built out enough to be viewed, but your product is novel, a screencast demo may be a good way to show an investor what your product “feels” like, rather than just giving them an idea. It’s much easier to fall in love with a product when you get to see it in “use”, rather than look at a screenshot or just have it described to you.

Just to make this demo, you’ll have to do at least some UI/UX design and testing, rather than just visual design. (In this post on UI/UX design, I describe various ways to mock up a site)

You Don’t Have To Hire Someone (wHEW!)

Fortunately, it’s actually pretty simple to do yourself with one of a range of tools built specifically for screencast creation. Paid tools I’ve been recommended include Screenflow, Camtasia, and iShowU.

However, I went cheap-o, and loved the results: Screencast-O-Matic. It’s not the most beautiful website I’ve ever seen – but $9 for a year with the Pro account did the trick. The best thing about it (aside from the name) is the simplicity of the interface. It’s got just a few features, and they are the exact ones you need.

Unfortunately, the microphone on your computer sucks, and it will be very obvious you used it when you crank your demo volume up for a room full of listeners and you’re bombarded with whirrs and buzzes. Get a decent mic for your demo (if you’ve got a solid headphone/mic combo this can work too).

What should you include?

In total, your demo should be between 1-2min. You should show:

  1. The Core Features that define your product. E.g. if it’s a travel search, show travel search, which is: Enter city, enter dates, hit “Search”, get results, see detail and buy
  2. The Wow Factor – Make sure this is a real “Wow”. Don’t go crazy here showing a bunch of mediocre details, which happens WAY too much. Pick a couple of killer moves. E.g. Show a truly amazing deal your site can find, or some feature that no one has yet.

You’re going to want to add detail to show everything that you can do – but that’s for the next meeting and the next demo. Don’t BORE them! VC Mark Suster puts it well:

“DO NOT make it a features & functions presentation. Unfortunately most people do…Lame. You’re showing them features, not value. Value is when you frame the demo in terms of why it solves somebody’s true pain point.”

The best way to get this down to the core points is to write a script. If you just try to walk through your site on the fly, it’s easy to show too many features, and not hit your points hard. Write a script, then reduce it down to the Core and the Wow Factor, and expect to record multiple times and refine.

My final tip here – talk while you’re recording the visual part of the demo to keep pace, but voice it over later. You’ll sound much better.


As Mark Suster mentions in his post, there are a TON of bad demos out there. Avoid walking through your product and checking boxes with a monotone “and then you do X, and then you do Y, etc.


The best way to build your demo is to build it like your pitch. Don’t just tell your listener what’s happening next, make them WANT that next step. Describe the problem, and help them feel the pain point your product solves. They should think “Damn, I really want to fix this…but how??

(If you’re giving an investor presentation, it should be woven in with your deck, where you present the problem, a description of your solution, then show your demo.)

In addition to the overall reason for your product’s being, you should be clear why you’re doing every little thing you’re doing in the demo. Don’t say “I’m doing X, now Y – instead say “I’m doing X, because I want to Z – and BOOM, there’s what I wanted”.


This is your product that solves this MASSIVE problem and is going to make A BILLION DOLLARS. Be excited about it for goodness sake! You don’t need to be a monster truck commercial, but avoid the monotone.

I also recommend using a bit of humor. Even the coolest product can have a boring part that needs to be shared. One that comes to mind is logging into your bank account with Mint.com – if I was investing, I’d want to see how you connect a bank account, but once I realized what was happening, I’d tune out as the presenter fills in some form. It’s a good time to crack a joke, make people happy and get the blood circulating.


This is where the program you’re using really helps out. I have seen a ton of demos where people bring up their website on a huge screen, and absolutely nothing is legible to the audience. This makes for an incredibly boring demo, and people will quickly start checking email and ignoring you.

  • Big – Zoom in on the detail you’re talking about so the font is very readable, and the parts of your site that are unimportant for what you’re saying go away. However, you should leave some of “the rest” visible, so people still feel the context of your site
  • Focused – “Gray Out” the area around your focus area so people don’t get distracted by all the other fancy features still on-screen
  • Clear – Don’t show a bunch of power-user moves, keep it simple

As Always – Test And Refine

Just like your product, your pitch, and the rest of your deck, you should always test your demo with others and incorporate their input.

In particular, figure out which pieces of the demo don’t make sense to them, what they feel is missing, and – most importantly – watch their body language and figure out when they get bored, then make those sections better or remove them.

More Visuals, Less “UI”

Why don’t more web apps do this?

Today, I saw what I found to be a really sweet bit of UI – the Yelp iPad app. And it got me to thinking, why don’t more “normal” websites do this? Particularly, increase visuals/immersion and stop bombarding me with “features”.

 More Visuals, Less UI

Now that I have most of the core content-websites I use in iOS app form, when I need to, say, book a dinner reservation, look up the hours for the restaurant and check out the menu, I just use my iPhone.

I get all the info I need quickly, with just a few taps of the thumb. And I don’t need to wait for a mess of twitter feeds and ad servers to load up to begin finding content. This would work equally well with a mouse or trackpad.

For me, this Yelp iPad app is perfect. Just the necessary info, with big, satisfying pictures to immerse me in the experience. I wish the web-based Yelp was the same.

Yeah yeah, I know what you’re going to say…

I agree that packing ads on the screen makes a lot of businesses a lot of money, and that users often won’t scroll down the screen or find something hidden behind a button.

However, the successes of iOS and Android suggest that, if designed correctly, simple, great-looking apps with limited feature sets can make users very happy…and still make money.

web apps that keep it simple and look good doing it

 More Visuals, Less UIAnother recent example of a website that just feels good is about.me.

They’ve captured all of the UI they need, and made it beautiful. Any of the bells and whistles they need (peeks at social networking personalities or blog posts) are hidden behind very obvious icons.

When I want to learn about someone, I just want:

  • A brief blurb about who they are
  • A picture / feeling of the person
  • Links to social media personalities
  • Other relevant links

About.me provides all of this info perfectly. (Also, 400K users and a sale to AOL 4 days after launch suggests to me that people are happy with the user interface design.)

Who could use a change

HuffPostWeb 300x258 More Visuals, Less UIThough there are arguments to the contrary, as a user, I would love to see a news site like Huffington Post shift a bit toward its iOS counterpart. Occasionally, I enjoy reading extremely biased political trash, but the websites of The Huffington Post and The Drudge Report just hurt my eyes.

However…the Huffington Post iPhone app is just so easy to use! Very simple, I can flick through stories and categories effortlessly, and all of the features I really need (save, email, search) are neatly hidden away.

huffpost 200x300 More Visuals, Less UI

FOR ME, there is no need for any more real-estate. I understand that research has been done suggesting that “out of sight, out of mind” holds true, and Huffington Post gets more headlines on the screen, raising the chances users will find something they like, etc…

But personally, I would love to see all this beautiful mobile design, whether mobile phone- or tablet-sized, brought into more “standard” web design.

When Should You Start UI/UX Testing? (Very, Very Early.)


Very early in the life of catapulter.com, before we hired a designer, our team drew up a basic user interface that we believed would work well for the site. We haggled over details for a few nights, and finally came up with a pretty solid UI.

Fortunately for us, one of our mentors set time for us to chat with a UI/UX expert before we hired one.

The first thing he asked us was: “how many people did you test with?”

Of course, we had asked a few people what they thought, but we hadn’t put together a preset, regimented UI/UX test. We had intended to have a designer with UI experience take our initial PowerPoint mockups and move to this step.



It turns out, we didn’t have to go to that level. As a professional UI/UX guru, one of our mentor’s typical first steps is to hold very rough UI/UX tests:

  1. Sketch out a rough wireframe of your site, with every piece needed for the user to complete your target action
  2. Write up a questionnaire to be used consistently across users
  3. Find a bunch of people in your target audience who have no idea what the site is about
  4. Ask them to “use” the wireframe as if it were a website – e.g. for us “plan a trip”

Admittedly, we weren’t entirely convinced this would be useful, with such a simple sketch of our idea…but once we started, we quickly realized that the important part was NOT having users visualize the site.

The important part was that users knew what information they wanted next, and they expected that to be available. Just like on a live website, if the required info isn’t readily available, the user will get confused, frustrated, and/or leave your site altogether.

Given this, much of the value in the test was not asking the user “what do you like/dislike”, but watching the user navigate, asking what they’re thinking at each step of the process, and recording as much information about their experience as possible.

One of the best pieces of advice that we received during our intial design phase was from fellow Betaspringer Andrew Draper of Manpacks:

“At every step of the way, get it in front of users as soon as possible. You think you know the main issues with your site, but as soon as you show users, you’re going to get bombarded by complaints, and see that the biggest issues are actually three things you never even thought about.”

GET it “on paper”

Our next step was throwing together a PowerPoint of the site. I admit that this is mostly because I’m an ex-consultant, but one of its best features is that you can create working links between pages, convert to a PDF, and send this linked mock-up of your website by email to users. If you don’t like PowerPoint, there are a ton of other mockup and wireframing options. Ones that I’ve played with include:

  • Cacoo – An online mockup tool that can be used collaboratively like a wiki
  • MockApp – A package of images of iPhone buttons for Photoshop or PPT that can be easily cut/pasted to create a realistic iPhone mockup (Hint: Use this in PowerPoint, print to PDF, and download the $0.99 GoodReader app to use with working links)
  • There are many other, likely better mockup tools that I haven’t worked with – A recent, pretty comprehensive list of other mockup tools can be found here

As you go through the UI/UX tests, as Andrew said, you’ll notice there are a lot of things that need to be changed, many of which you haven’t thought of. At this point, you’ll begin to realize another very important rule of UI/UX design: you’re never done!

The biggest misconception many first-time web designers have is that “we’ll design and build the thing, then we’re done.” Never. You’ll always have something that doesn’t work just right, new features that a ton of users want (expect, really), and you’ll need to continue to iterate.

Therefore, the key takeaway is: don’t half-ass this initial mockup, testing and design phase.

Test with good amount of users (10-20), incorporating their feedback and iterating as you go. Once you’ve begun to understand what your users want, not just what your team thinks they want, you can move on to spending your time and money on building the site.

This way, you’ll start from a much stronger, user-validated initial design, you’ll understand what additional functionality users want you to build, and you’ll have already seen (and hopefully circumvented) many of the pitfalls that can make a user leave your site immediately and never come back.