Video 2 of 4: How to Validate a Business Idea Spending Minimal Time & Money

I was recently invited by the team at Docstoc to participate in their “expert” video series, meant to help small business owners, entrepreneurs, and individuals. This is part 2 of 4.

Here, I talk about how to test a business idea:

  • Throw something in front of customers. Create minimal marketing materials and present them to customers (in person, via mail, via search, etc). Don’t need a lot. 500 visitors or 10 in-person consultations will probably get you 90% of the information. (See: Jakob Neilsen, Hallway usability testing).
  • Gauge the response. # of folks who provided email address, # of survey respondents, what they said, etc. Some of this is not scientific. Hopefully you will have verified some of your hunches. Perhaps you’ll hear something that you didn’t expect.
  • Refine or drop the idea. Proceed with confidence, or, further dig into some of the concerning pieces. Better to work hard at this, up front, and be honest with yourself (vs. spending lots of time and money building stuff folks don’t want).

Video 1 of 4: Four Steps to Build Great Software Products, A User Centered Approach

I was recently invited by the team at Docstoc to participate in their “expert” video series, meant to help small business owners, entrepreneurs, and individuals.

In this first video, I describe the software development process I like to follow. I think that it optimizes for the end user.

It requires a lot of focus and energy, up front, iterating on the user interface in each phase:

  • Wireframes
  • Design mockups
  • HTML / CSS / Assets
  • Development

The product person remains as the primary advocate for the user – nothing rolls out until they approve.

Lots of stuff can get lost in translation from design to development. Lots of really important nuance can be lost. Development is hard. Help the development team by clearly and consistently communicating to them what you want.

WinDirStat – See treemap of your file system, easily find big files

WinDirStat is still a really great tool, even after all these years.  Very useful!

I don’t know of any other way of quickly and intuitively finding out what’s taking up my disk space.  Perfect use of the treemap visualization.

Excel “Comment” Bubbles Need to be Improved

It’s about time that Microsoft improve the “Comments” functionality in Excel:

Wow. Just plain ugly. Shooting from the hip:

  • That shadow technique (angled lines) is a bit…dated.
  • Square corners? Rounded would be much better, especially given the grid-like nature of Excel. Rounded corners would create a nice contrast to the rest of the display.
  • 8 ways to tug / pull / stretch?  Totally unnecessary.  Why should this be resizable to begin with?
  • Default size: about four rows of text high.  Doesn’t automatically resize.

Stop Using Lorem Ipsum!

I think I’ve discovered a handy way of summing-up how I think about designing user interfaces: No Lorem Ipsum!


A Symptom of a Bigger Problem: Lazy Product Design
Lorem Ipsum isn’t always bad. It’s often useful in “marketing pages” – places where you want to indicate there will be a few paragraphs of text here, a sentence or two there, etc. But when designing interfaces? No way. Use Real Data. Text that represents, you know, what the user might actually see.

Designing and building great software is hard. You’ve got to put yourself in the shoes of the end user, try to understand their needs and motivations, and try to create a tool that’s really useful (and hopefully fun and interesting too). You’ve got to sweat the small stuff. Every screen. Every permutation of every screen. Every label, every text box, every error message. It’s the accumulation of thousands of design decisions that makes something great.

Using “Lorem Ipsum” or “Menu Item 1” or “Product 1” (or whatever) makes it harder to design great software. What happens when “Product 1” becomes “How to Be Funny: The One and Only Practical Guide for Every Occasion, Situation, and Disaster (no kidding)”? Find out early so you can design accordingly.

“The problem is we don’t understand the problem”

Aza Raskin, the talented user interface designer (and son of the original designer for Macintosh, Jef Raskin), shares a really insightful short story that suggests how we should go about tackling “deeply difficult challenges.”

Aza goes on to talk about a man named Paul MacCready who sought out to build the first human-powered airplane. From the article:

The problem was the problem. Paul realized that what needed to be solved was not, in fact, human powered flight. That was a red-herring. The problem was the process itself, and along with it the blind pursuit of a goal without a deeper understanding how to tackle deeply difficult challenges. He came up with a new problem that he set out to solve: how can you build a plane that could be rebuilt in hours not months. And he did. He built a plane with Mylar, aluminum tubing, and wire.

I think this perspective is useful when thinking about technology-based solutions to K-12 education. Modern instructional formats (like Academy123 and Khan Academy) afford scale, “failing quicker”, and iterating toward success.

Imagine “a process of ongoing improvement“:

  • 100,000 mini-videos, 2-3 minutes in length, in one subject (say, algebra).  For each specific topic (say, simple factoring), videos are recorded in dozens of different ways (teacher A, B, C. Easy, Medium, Hard. Instructional method X, Y, Z).
  • Each student is prescribed a customized path through those videos. The prescription changes on-the-fly.  Some students, for example might respond better to a male teacher, a female teacher, a young teacher (peer), and older teacher, etc.
  • Hundreds of videos are re-done each week, based on student results, attention data, and other analytics. The content gets better over time.
Click to Play

Click to Play


Scaling teachers using technology

Issac Asimov, the famous Science Fiction writer, wrote an amusing short story (below) that describes a highly individualized and customized learning environment, while at the same time, reminds us how our existing education system is so outdated and inneficient (textbooks that students don’t read, 35 kids in a class, students grouped by age and not by ability, etc.).

Has technology advanced enough such that we can approximate, with sufficient “fidelity”, a real flesh-and-blood teacher?

Isaac Asimov – The Fun They Had

Use These Mockups: Lots of Design Patterns in Balsamiq Mockups (BMML) format

For those of you that use Balsamiq Mockups, here are a bunch of templates I created that you might find handy.
Download them all in one ZIP file (90KB).

I find myself re-using many of these elements when I design applications (especially the boring/tedious/must-have features, like Forgot Password, Sign In, 404 page). Enjoy!

The following mockups are included in the ZIP file:

Home Pages

Home Page, Members Only Mockup
Home Page, Downloadable Product Mockup

Feature Tour

Feature Tour Mockup

Pricing, Upgrade, Downgrade

Pricing Page Mockup
Upgrade & Downgrade Mockup
Upgrade “Thank You” E-mail Mockup

Read-Only List of Items

Read Only List of Items Mockup

Editable List of Items

Editable List of Items Mockup
Add Item Mockup
Edit Item and Delete Item Mockup

Invite Friends

Invite Friends Mockup
Invite Friends Via E-mail Mockup (Popup)

Settings / My Account Page

Settings / My Account Page Mockup

Sign In

Sign In Page Mockup
Sign In Popup Mockup

Forgot Password Process

Forgot Password Page Mockup
Password Reset Email Mockup
Reset Password Page Mockup


404 Page Mockup
Log / History Page Mockup
Downloading Page Mockup
Windows System Tray Mockup
Windows Tour Mockup

A Blast From the Past: ICQ and AoLOL!

Yesterday, at the Israel Conference here in L.A., I met, in person, for the first time, someone that I’ve been communicating with electronically for about 15 years. Funny when that happens.

I first met Yair Goldfinger when he was working on ICQ, a company that he co-founded back in 1996 that invented instant messaging as we now know it. I was 16 years old, a Junior in high school, when I was introduced to the ICQ team. These were four young Israeli guys working on something that turned out to be really, really big. In a way, ICQ is symbolic of kicking-off the dotcom boom: the prototypical startup that exited really, really big (sold to AOL for $400M in 1998).

The ICQ guys asked me to give them some feedback on their web site, which, at the time, was littered with broken English. I was rather helpful in that A) I can speak Hebrew fluently and I connected well with the team and B) English is my native language, so I could help them get things into decent shape.

I was really intrigued by their product, especially considering that I had built something somewhat similar (but vastly simpler, without their bigger vision): an add-on for AOL 2.5 that, among other things, allowed you to see if your friends were online. And, if they were, you could send them instant messages.

I called the product AoLOL!. It was my very-first piece of commercial software. I labored over it for months and months until my cousin, who had some experience in the world of computers, demanded that I release it. I was new to software development, and by the time that I had built an adequate number of features, I learned so much about how to improve my work that I couldn’t bear to release the software as-is. It was never good enough! (typical problem among software developers).

The product actually did quite well (considering the circumstances) and sold hundreds of copies (shareware, $14.95 per copy). It was an incredible feeling to get checks in the mail from complete strangers!

At one point, the ICQ guys asked me if I’d be interested in joining them – they were in the Bay Area at the time – but I had to decline (I was still in high school!). They also offered me UIN #007 (ICQ didn’t have usernames, they assigned numbers to each user), and I I declined (don’t ask me why). My UIN is 104007 (four thousand and seventh person to sign up – they started at 100,000).

Later, AOL launched the “buddy list,” and I let the ICQ team “borrow” my AOL account (“yar1g”) to check it out, see how it works, etc.

Fun to look back. Everything was so exciting and new.

DeviceReady: Test Your Android App Across 25+ Devices

I keep hearing from lots of folks that Android fragmentation is a big problem. When developing apps for Android, you have to consider the various devices, versions of operating system, form factors, etc. Sounds like a nightmare.

I’ve been thinking lately about one possible partial solution:

A service that enables Android app developers to submit their app and get screenshots of how the app looks and performs across the most popular Android devices.  Not an emulator.  Your app running on each of those devices.

Like Selenium + Browsershots for Android.

To test the concept, I quickly came up with a name (DeviceReady), threw together a landing page using Unbounce, shared the idea on Hacker News, and purchased about $75 worth of Google Adwords.  The results after 3 days:

Pretty good, right?

I think this is a winning idea because:

  • A company serious about their android app really should test it across dozens of devices.
  • Presumably they are spending a lot of money building and testing their app.
  • The cost of the service, at, say $100 per month (5 submissions) or $25 per submission would be negligible.
  • It is unreasonable to think that a small or mid size android dev shop (most of them) would buy dozens of handsets and manually test on each.