Toggle navigation

The Most Important Skill of the Decade: Jeromy Wilson on Prototyping Techniques

Jeromy Wilson"How do you know you're coding the right stuff?"

That's the central question in Jeromy Wilson's recent blog post called "The Most Important Skill of the Decade". He believes that for a technology company to be successful they need great programmers, but even more importantly they need to know how to prototype and test what they want to build before creating it.

Jeromy says that prototyping is a skill that must be learned, that it's not "just putting pretty pictures together." He writes that learning prototyping includes developing "listening skills, innovation skills, UX skills, critical thinking skills, and tech savvy skills."

Successful prototyping is what leads to successful products today, which is why he calls software prototyping "the most important skill of the decade." He also believes it's a skill that everyone involved in the process of creating software should learn, not just designers and developers.

He has developed a comprehensive course on software prototyping called Master Software Prototyping on the learning platform he created, Niche Academy, which he built as a place for people to teach their own "niche" subjects that may not be available elsewhere.

I spoke with Jeromy, a long-time Balsamiq user, about prototyping as well as his recent leap from corporate employee to entrepreneur, which he described to me as "the right time and the right thing."

Q&A with Jeromy Wilson

Who are you and what do you do?

My name is Jeromy Wilson. I’m the founder and CEO of Niche Academy - which is a Software As A Service (SAAS) platform which allows anyone to create their own “niche” online learning academy. I’m also an instructor at a Niche Academy called “Everything but Coding”, an okay ping pong player, a lousy singer, and a Balsamiq aficionado.

Why did you start your own learning academy and what are you hoping to accomplish with it?

There are a lot of people out there with their own niche expertise to share.

I built Niche Academy because it was something I wanted to use but couldn’t find. I wanted a better way to teach software prototyping and other related skills. Hence, my “Everything But Coding” academy. I know there are a lot of other people out there with their own niche expertise to share. Education is changing because of the way eLearning tools like Niche Academy are making knowledge more accessible than ever before.

What makes Niche Academy different?

We want to be the best at helping individual and business experts teach what they know. We want the software to essentially disappear in front of their students eyes and have them only see what they need to do to learn. We have made it extremely easy to create your “niche” academy, create your courses, and reach your learners. We are doing everything we can to make the platform disappear and help the instructors and learners shine.

We are also infusing creative ways for the learners to learn. Like allowing the learners to learn based on their current learning style (which isn’t necessarily the same day to day).

It’s a process, but our development style is ever striving for simplicity, clean interfaces, essential and effective features, and happiness. 🙂

How did you discover and learn about software prototyping?

My first experience with prototyping was at a company called Dynix (now SirsiDynix). I took some requirements I had written to one of the lead developers. After looking them over for a few seconds he handed them back to me and said, “Could you draw me a picture?” I immediately went back to my desk, grabbed a pencil and a blank piece of paper and I drew him a picture. By the time I had finished that first wireframe, I was hooked. The creative and inventive process of coming up with something new was irresistible to me. I eventually graduated to PowerPoint and Visio.

Lesson learned about high fidelity prototypes: make sure everybody knows it's just a prototype.

I worked for Dynix for several years before accepting an invitation to join a startup called Alpha Bay. I was the first official employee at Alpha Bay and one of my first tasks was to create a high fidelity prototype of the retail system we intended to build. That prototype was too good, as it turned out. The first time we showed it to a customer, they wanted to know how long it would take to roll it out in their stores. They were ready to buy. When we told them it was just a prototype, they felt like they’d been tricked. Lesson learned about high fidelity prototypes: make sure everybody knows it's just a prototype.

When and why do you use Balsamiq Mockups?

When I’m creating a new product or design, the Balsamiq mockup is the first thing I create after going through the understanding and brainstorming phase. When I first start building a new product, new design, or new feature I start by first understanding my audience and what they are trying to accomplish. I then brainstorm about how I will solve their issue or fulfill their need - which usually includes a whiteboard with initial workflow and layout ideas. I then create my first Balsamiq mockup, get feedback, change the mockup, further validate, etc. Then I write the acceptance criteria after the mockup and validation are complete.

It’s so much easier to look at a picture than to read a bunch of requirements, use cases, or user stories.

I put together mockups because it is the best way to get everyone on the same page and the only way to start getting real feedback. Plus, it’s so much easier to look at a picture than to read a bunch of requirements, use cases, or user stories. That being said, I write some great user stories - filled with plot twists, suspense, and sometimes humor (which my bosses hated, but the developers and customers loved).

I also used Balsamiq to create a test for graphical designers we were interviewing. They had to create a functional webpage based on the balsamiq mockup. Here it is:


Can you tell me about a specific project where Balsamiq was especially useful?

It’s been helpful with every project I’ve worked on. Here’s a good example though. I built an app for the Apple App Store several years ago that didn’t do very well. Great product, but I didn’t market it very well. So, to solve that problem for my next app, I found a blogger that had a lot of influence in her market and asked her if I could build an app based on her approach. She had written a book as well. So I bought the book, read through it, and then put together a Balsamiq based on what I had learned from the book and how I proposed to convert that into an app. She gave me feedback and I made the proper adjustments and then we built it. It did much better than my first app and even broke into the top 30 in it’s category.


Do you have any Balsamiq tips or tricks that you'd like to share?

I use the quick add religiously. You can get to it by simply hitting the “+” or “/” key and then type name of the UI component you want to use. So simple and fast. I also use the markup components quite a bit. You can make notes and put arrows all over the place to remember decisions you made and why and then with a click of a button you can hide them.

What other tools do you use for your job that you really like?

Besides Balsamiq I use Basecamp for project management, Camtasia for screen recording and video editing, SnagIt for screenshots and quick videos to send to developers explaining bugs, Dropbox for all my files, Pixelmator for image editing and manipulation, and ProtoShare for medium fidelity prototypes to name a few.

Why is software prototyping so important?

When done right it gets the right product out faster, it fuels innovation within a company or for a startup, and it unites teams with a process that helps everyone be successful.

Describe the different types of fidelity you mention in your course, how they differ, and when to use each.

In my course I teach about three types of fidelity in software prototyping. Low fidelity (LoFi), medium fidelity (MeFi), and high fidelity (HiFi).

LoFi prototypes are rapid sketches, mockups, and wireframes. It’s everything from drawing on a whiteboard or napkin to putting mockups together in Balsamiq. It’s where ideas are born and begin to be fleshed out. It’s very iterative and fast changing.

MeFi prototypes incorporate a look and feel closer to what the actual product will look like with links, buttons, and UI elements that actual work, but data isn’t being saved. Look, but don’t touch.

HiFi prototypes allows actual users to use the prototype as they would in real life. Not everything may work perfectly and some things might not work as they will in the actual product, but this gets you the feel of the product or feature.

What are some common misconceptions about software prototyping or mistakes people often make when creating them?

The first mistake people make is falling in love with their prototype.

I think the first mistake people make is falling in love with their prototype. They put all this effort into creating something and then get defensive when someone gives constructive feedback. Prototyping is all about validating, failing fast, iterating, and eventually getting to the right solution.

One of the misconceptions is that prototyping slows the process down. Why not just start coding and make changes along the way? Prototyping actually speeds up the process to getting the “right” solution done. It’s much more difficult and expensive to make changes to code.

Note: If you are interested in Jeromy's master prototyping course you can save 50% using this link.

Thank you, Jeromy. You are a Champion!

Do you have a story to share about the awesome things you do with Balsamiq? Send an email to with your stories or blog posts!

Leon for the Balsamiq Team

Leave a Comment

Comments (2)

  1. Very interesting information, however i guess you have to know how to program/code before you can implement or understand fully this process. Furthermore, i understand what Jeromy is saying regarding proactively correcting the development process by using Prototyping. Efficiency, user friendly, and simple is key to a successful implementation.

    Thanks, Robert

    Robert Y. Heredia
    • Thank you for your comment Robert. Knowing the process of programming/coding is definitely helpful, although you don’t necessarily need to be a programmer/coder (I’m certainly not). You mentioned “simple” in your comment. I completely agree. It’s funny how long I spend on features trying to make them simple. It seems backwards, but creating a feature that is truly simple is much harder than simply creating a feature.

      Thanks, Jeromy