I recently sat through a product management (PM) talk from a Senior PM at a Toronto tech startup. The talk was aimed at giving MBA students who don’t have a technology background an overview of PM. During the talk, many terms were thrown around that might not have made sense for newcomers. So, here’s my list of what I think are the most common terms for someone new to PM.

This post covers the design, UI and UX terms. The next one will cover engineering related terms like backlogs, sprints, APIs and user stories.

Design, User Interface (UI) and User Experience (UX)

Source: Dilbert.com

User Personas

A critical part of a product manger’s job is to be the empathetic voice of the user. It is through the product manager that their pain points, likes and dislikes about the product are translated. So, it’s important to get an intimate understanding of who your users are. A persona is a profile of a product’s typical user(s). A single product can have multiple personas, one for each type of user using the product. The persona can help the product manager and others within the company understand important traits, goals, responsibilities and needs of the user. A persona typically has a catchy name like “Travelling Tom” or “Nerdy Nina” — don’t ask me why.

Sample Persona¹

Product Mockups

The product manager has to be able to convey his/her ideas clearly. This communication is often in visual format — through mockups. Mockups are a great way for the PM to think about the design and layout of a a new or existing feature and convey them to others.

Low Fidelity Mockups

A low fidelity mockup serves to layout the high-level structure of a design without going into the specifics. It helps the designers and other stakeholders understand the UI and navigation of the page. At my previous startup Tract, we acquired our first few customers using just low-fidelity mockups of the entire mobile application! If done right, a low-fidelity mockup can sell your product vision really well and go a long way. My favourite tool for creating a low fidelity mockup is a pen and paper or Balsamiq.

Low Fidelity Mockup Example

Hi-Fidelity Mockups

A hi-fidelity mockup, on the other hand, serves to give the designers and other stakeholders a much more realistic view of the what the actual feature or screen looks like. It usually contains design specific elements like the dimensions of an image, the typeface to use and colour schemes.

Hi-Fidelity Mockup Example

Each type of mockup has its own pros and cons and should be used situationally.

Usability Testing

Designing and building something beautiful but not functional is useless. Imagine having a gorgeous peeler that cannot….peel. It is imperative to put your product through usability testing before pushing it into every user’s hands. This ensures that your product does what you designed it to do, every time. Fixing a bug once it’s been released is very expensive (and stressful!) Worse, you risk frustrating your users and hurting your adoption and retention metrics.

Usability testing can be done using the mockups, prototypes or functional software. The type of testing done depends on what kind of information you’d like to get from your users. Some common types of usability testing include:

In-person observations — Observing a user as they use a specific part of your application

Eye-tracking tests — Using specialized hardware and software to see which parts of the screen users focus their attention on. A visual heat map is then generated for review

Learnability tests — Observing a user while they try to find and learn how to use a new feature

Benchmarking tests — Comparing users as one group uses the old design and another uses the new design to see if the redesign actually enhances usability

Choosing a test group can also vary depending on your goal — you can launch it to a select few customers, an internal group of employees or outsource it to external testing agencies. As with QA testing, usability testing is not a one-and-done thing. It has to be a a continuous process to ensure that you have happy, un-frustrated users.

In the next part, I’ll touch on lingo you need to be able to communicate with the folks on the engineering team.

Continue reading Part 2