General Assembly Blog

It was a strange sight: a 40-year-old man taking a block of wood out of his shirt pocket, then pretending to scribble something on it with a stick. He stopped, then tap, tap, scribble again. After that he put it back into his shirt pocket.

The man is Jeff Hawkins, the inventor of the PalmPilot, the first handheld device that put computers into our pockets.

Hawkins had launched a similar venture a few years earlier, an amazing handheld computer called GRiDPaD. This was before we had LED monitors, when laptops weighed more than 10 pounds, so it was an impressive piece of hardware — but it was a flop because it wasn’t small enough for people to carry around. This is why he decided to simulate the experience of carrying around the device by cutting a block of wood representative of its size, sticking a piece of paper on it to simulate the interface, and carrying it around for months. Every time he needed to make an appointment, he’d take it out and pretend to check his calendar on the “device” and add the appointment to it.

This story illustrates prototyping — a quick and cheap way to simulate a product experience in order to reduce risks — very well. In the Palm Pilot example, the biggest risk was that the device might be too big to carry around. This type of prototype looks very crude because the focus is on realistic scenarios.

Prototypes can be really close to the final product with all of the features that will be included when the product is launched. But designers often start out by making a rapid prototype, the quickest and easiest way to prototype, in which the designer tries to mimic the experience without actually building or creating anything.

In software development and product design, rapid prototyping refers to techniques used to simulate the experience of using the software. In most cases, these techniques involve no coding in order to optimize speed and minimize cost. The goal is still to reduce risks — in this case, having to do with the product’s efficiency and effectiveness.

Effectiveness and efficiency are essential in user experience (UX) design. Effectiveness means the product’s user is able to get the value they come to the product for. If you’re an Airbnb user, you want to be able to book a place to stay while traveling. How do you do this? You would visit Airbnb’s website or open its mobile app. Can you accomplish this task (booking a room) using the website or app? If you can, then it’s effective — it’s giving you the result you desire.

Now, just because a product is effective doesn’t mean it’s efficient. Efficiency means you can complete the task with very little effort. If booking a room on Airbnb’s website takes you over an hour or too many steps, you probably wouldn’t use it often.

To determine whether a product is effective and efficient, we need to test it. And if the product is not built yet, we create a prototype and test it with real users.

The UX design process is based on design thinking framework, a problem-solving approach used by designers that’s centered around the target audience for which they design. It starts with understanding who they’re designing for (called a persona) and the problem the persona has before coming up with solution ideas. This way, the solution directly addresses an actual problem the target audience is experiencing.

The design thinking framework looks like this:

1. Empathize: Understand who your users are and the pain point(s) they experience.

2. Define (the problem): Using the problem as a starting point, generate ideas for potential solutions.

3. Ideation: Generate ideas and choose the one or two most promising.

4. Prototype: Create prototypes of the best idea or two.

5. Test: Test the prototypes, and use the learnings to improve the solution. After testing, you’ll return to the appropriate step. For example, if the idea is not effective, you’d go back to ideating more or simply choosing another idea to prototype, then test again.

UX designers go through this iteration loop multiple times until they find an effective and efficient solution.

The focus of prototyping is to get as much learning as possible with the least amount of effort. This means we only put into the prototype what we need to test, based on what we want to learn about our product idea. In Lean Startup, a methodology to build businesses and products, this concept is called building the minimum viable product, or MVP. The focus here is the viability of the product idea — is it going to work?

When creating prototypes for digital products, like apps and websites, there are many tools available. These tools allow designers to create prototypes, regardless of whether they know how to code. Some of the platforms commonly used by professional product and UX designers include InVision, Marvel, Flinto, UX Pin, proto.io, and Axure.

Creating a prototype with these tools is very easy. Here are the steps:

1. Use a UI design application like Sketch or Adobe Photoshop to upload screen mockups (typically in the PNG file format).

2. Add hotspots — areas with which users can interact — to a screen and define what should happen when the user interacts with it (e.g., take the user to another screen, transition between pages, etc.).

3. Preview the prototype to make sure it’s doing what you want it to do.

4. Repeat steps 2 and 3 for each screen.

Once you’ve connected all the screens, you can then use this prototype to test your design in usability test sessions. You’d show the users your prototype, then ask them to complete the specific task for which you’re designing the prototype. This would allow you to discover, then address issues that block them from completing the task.

At General Assembly, students in our full-time User Experience Design Immersive and part-time User Experience Design course (on campus and online) learn hands-on how to create a rapid prototype by using Sketch to create the screens, then InVision to connect those screens and make them interactive. This portion of the course happens right before the students learn how to conduct usability testing to make sure their design work well.

In order to determine what to prototype, students create user flows, wireframes, and information architecture before they create the screens in Sketch. By the end of the course, students have both the theory and hands-on experience of applying the design process.

Students in GA’s part-time Product Management course also learn to create rapid prototypes; after drawing drafts of their wireframes on paper, students turn to platforms like Sketch, InVision, and more to digitize their designs and create interactive prototypes.

Danny Setiawan is a UX professional with 15-plus years of experience. He is currently the managing director of CoCreate, a UX consulting firm, and a product mentor at Starta Accelerator. Danny has worked with brands like Yahoo! Finance, The Economist, PwC, MSN, Kimberly-Clark, and Microsoft. Danny teaches the part-time User Experience Design course at General Assembly’s New York campus.

We all know the products that are successful; the ones that seemed to come out of nowhere and then change the way we go about our lives — like the smartphone, ridesharing, or turn-by-turn navigation. But there are a lot of products that didn’t make it. Though there are many reasons why products aren’t successful, one that often comes up is that people don’t see value in what it does. Or, they don’t see enough value in it to pay for it.

One way to avoid going down that path is by conducting user interviews. This is where product teams go out into the world and talk to people who fit their product or service’s personas, observe their behavior, and ask them questions. A persona is a representation of users who have the same problem or goal. Though personas are not real people, they are created based on real user data, often generated or validated by user interviews.

User interviews were introduced in 1990 when the authors of a report called Contextual Design: An Emergent View of System Design talked about “contextual inquiry” as part of the product development process. The goal of an interview is to discover what problems users have that product teams might be able to solve. This is done by visiting users in the environment in which they use the product or a competitor product, or where a problem is occurring; watching their behavior; asking them questions about their behavior; and then drawing conclusions from what they observed.

Anyone and everyone on a product development team — including product managers and user experience designers — is encouraged to take part in a user interview at some point. It’s very easy for teams to get caught up in their own assumptions around what products users want or need. By observing real people, in context, experiencing a problem, team members build empathy and have a strong desire to personally solve it. So the act of interviewing can result in not only more successful products, but also more inspired teams who find meaning in their work.

Oftentimes, user interviews are criticized as “asking users what they want.” That is a misnomer and not the true objective. As researchers, the goal is always to observe current behavior so that we can understand as much as we possibly can about the problems users experience, relative to the solution we’re able to provide. We try to prove that the problem is real, in what context it occurs, how a user currently solves the problem, the frequency with which it occurs, and how frustrated a user is when it’s occurring.

Critics will often add that they understand problems enough by looking at analytics, or quantitative data. Unfortunately, quantitative data can only tell you that there is a problem — it’s qualitative data that will tell you what that problem is and why it exists. The insights the team gets from truly understanding and empathizing with the problem allows them to think more broadly about their solutions and truly build the next set of innovative and successful products.

A key step in planning user interviews is, of course, finding your users or potential users. Sometimes seeking out people who are willing to talk to you can be as simple as doing an intercept interview, where you approach people on the street, in a place of business, or digitally while they are using your product, and ask them if you can have a few moments of their time. It’s OK if they say no! Simply move on to the next person (who will most likely say yes).

You can also find people by asking your product or service’s current users via an email blast, or by reaching out to those who have submitted a support issue.

It’s common practice for researchers to compensate interviewees, though it’s encouraged to try to compensate as little as possible. That’s why you’ll often see companies recruit by saying something like, “Talk to us for 30 minutes and get entered to win a $25 gift card.” The idea is to provide just enough compensation to entice people to participate, but not too much to introduce additional bias into the data.

If you have a large budget and are looking to speak with very targeted users, you can also hire a company to recruit users for your test. This can be very expensive and can also inject a bit of bias because those users tend to be compensated at a greater rate than willing participants from other methods. But sometimes that route is the only efficient way to get access to a specific group of people.

Depending on where your users are located, you might conduct an interview in person, on the phone, or over video conference. It’s best to have two people from your team there to conduct the interview so that one person can ask the questions and have a conversation while the other takes notes. (It’s quite difficult to simultaneously take notes and practice active listening.) If you record the interview, make sure to tell the user beforehand.

The goal of a user interview is to get at why users behave the way they do and how they feel about their experiences. Because of this, it’s important to ask open-ended questions that focus on the person’s past or current behavior. Interview prompts can even be phrased in a way that it isn’t a question, such as, “Tell me about a time that you [used a self-checkout/searched for clothes online/scheduled an appointment with a doctor],” or, “Tell me about the last time you…”

After the user has described what happened, follow up with questions that get at why they behaved or reacted the way they did. Ask them questions about how they felt. Watch their body language as they answer those questions. Sometimes the most important information about how to proceed can come from what people don’t say.

Above all, do not ask users to predict what they will do in the future. If you find yourself asking questions like “Would you use this product?” or “Would you pay for this service?” or “What would you like to see in future updates?”, simply pause, and rephrase the question so that it asks about past behavior. “Why did you use this product or similar products?” “Have you ever paid for a service like this?” “Why have you stopped using this product or similar products?” By focusing on past behavior, teams will gather information about the problems users are facing so that they can use their collective wisdom and skills to come up with innovative solutions that succeed in market.

In General Assembly’s full-time User Experience Design Immersive (UXDI), part-time User Experience Design, and part-time Product Management courses, students get firsthand practice conducting interviews. We first discuss how to interview and learn best practices for being effective. Then we jump in and start interviewing. Students draft questions and an interview script, practice with one another, and get immediate feedback from their peers. Then they set out to find and talk to real users who have the problem they’re looking to solve. In UXDI, students work with real-world clients and conduct interviews with their current or potential users.

After their first interviews, students generally say that the experience of approaching and talking to strangers was a bit scary, but also that it gave them so much good information that they need to take their projects in a whole new direction. Essentially, they discovered that their assumptions were incorrect and they now understand what problems are worth putting more time and effort into exploring and solving.

Tricia Cervenan is an instructor for General Assembly’s part-time Product Management course in Seattle. She has been developing products for over eight years and currently helps clients solve software problems at the product agency L4 Digital. You can find Tricia on Twitter at @triciacervenan.

Whether you’re starting a new project, evaluating the state of your business, or trying to decide how viable a new product might be, here’s a remarkably simple yet powerful tool that can help you move forward: SWOT analysis.

SWOT is a strategic planning method structured on four elements of concern —  strengths, weaknesses, opportunities, and threats. SWOT can be terrific tool for strategic planning, and it helps to better manage the future of a product or organization. It’s often used by product owners, marketing managers, and business analysts, but may be undertaken by entrepreneurs and other business decision-makers as well. A SWOT analysis can benefit a business at any stage, and its popularity has driven its use to noncommercial organizations, industries, and even entire countries.

A SWOT analysis is often created during a strategic planning session as the result of brainstorming exercises. It can be constructed quickly and the results are usually broad and simplistic, but they can help jumpstart discussions of strategic priorities.

A SWOT analysis includes factors both internal to the company and outside in the greater environment. Strengths and weaknesses are internal. They are the things the organization does — or doesn’t — do well. Recent research has shown that these are the most important factors, and they’re within the organization’s control. For instance, when performing a SWOT analysis on a company, the internal factors may include the organization’s people and culture, client and vendor relationships, physical plant and equipment, financial assets, manufacturing prowess, intellectual property, marketing capabilities, and beyond.

Opportunities and threats are external factors. These are the forces that are outside the organization, but could still have a significant impact on the ability to reach the stated objective. For a company, these may include competitors and vendors, technology, macroeconomic trends, government policy and regulations, changing demographics, and more.

SWOT analyses have emerged as a valuable approach because they’re fast, flexible, and give a quick overview of the company’s situation. The method works like this:

1. Clearly state your objective.
2. Identify strengths — things you do well that may help reach the objective.
3. Identify weaknesses — areas that need improvement and may hinder you.
4. Identify opportunities — places ripe for growth or advantage moving forward.
5. Identify threats — competitors or conditions that could harm your efforts.
6. Recognize relationships between the identified elements.
7. Prune and prioritize to those topics you can focus on to drive change going forward.

The elements proposed in a SWOT may be wide ranging, yet the analysis must be realistic and rigorous. SWOT is a strategic tool. It is about planning for the future, so focus on things that could actually impact reaching the stated objective.

Threat of new upstart competitor? Yes.

Threat of zombie apocalypse? Not so much.

A SWOT analysis can help reveal issues and determine whether the desired objective is feasible in the operating environment. SWOT results can be simply listed or shown in a series of columns. However, the most common representation is a matrix like, this:

A SWOT analysis can be used early in a strategic planning session as a conversation starter to surface issues like market positioning or technology changes. Or, it can be taken deep and used as a more comprehensive study.

As a planning tool, SWOT analysis can utilized at many levels. It can be used to:

• evaluate a product,
• appraise a line of business,
• assess a team, or
• analyze an entire organization.

At General Assembly, students learn about SWOT analysis in our User Experience Design Immersive in the unit on business analysis. It’s also covered in our part-time Product Management course, as it’s key in understanding the path to product-market fit. Students are taught to be aware of the competition and what they are doing, but to not let that be the only determinant of what your product should be. They must also appreciate the assets they have to leverage and how it all fits together.

Jason Reynolds teaches the User Experience Design Immersive program and related workshops at General Assembly’s Boston campus. He is passionate about user experience and process improvement and is excited to share his knowledge and experiences with others — especially those new to the field of UX.

When you think about the world’s most visionary leaders, whose faces do you see? Steve Jobs? Elon Musk? Perhaps Oprah Winfrey, Bill Gates, Sheryl Sandberg, Henry Ford or Amelia Earhart? In hindsight, what makes these leaders “visionary” is often the enormous degree of impact they enabled. However, leaders like the list above rarely stumble into their success; they enter their field with a resolve for how they will make a difference. They see things no one else does. They have a vision.

Seeing things no one else can see takes practice. It’s not a bolt of lightning, but consistent practice that allows truly visionary leaders to constantly push the boundaries of what products can enable a better world. Subsequently, forming a product vision enables you to set the North Star to guide you and your team toward a goal without leading you astray.

In the context of product management, business strategy, and entrepreneurship, if your company’s mission is to solve problem “X,” your vision is the imagined and idealized world in which your product has solved problem “X” with the greatest conceivable outcome. The best product visions paint a picture of a dramatically better world in which the lives of your users are improved by your product.

Having a clear product vision allows product teams and leaders to:

• Suspend constraints. It’s impossible to develop a vision without dreaming big. Thinking about the ideal end-state, even if only for a moment, will allow you to open yourself up creatively to all the possibilities of how a problem can be solved without being held back by feasibility concerns. When developing a vision, anything is plausible as long as it doesn’t violate the laws of physics.
• Inspire greatness. A well-articulated vision allows your stakeholders (both internal and external) to close their eyes and envision the same thing as you. Your customers who see themselves as part of your vision will be more likely to buy your product. Talented employees who share in your vision will be more likely to join and stay on your team.
• Set strategy. A vision helps you forge a path from where you are to where you ultimately want to be. Your vision will inform short-term roadmaps as well as long-term strategies, where you can plan concrete steps (e.g., minimum viable product, future version releases) toward your end goal, saving you time spent via trial and error iterating in the wrong direction.
• Align teams. Having a shared North Star means anyone on your team can constantly evaluate whether the work at hand gets you a step closer to the end goal, lending a level of built-in focus to your team.

A great company mission and product vision informs clear strategy and roadmaps. To clarify further, here’s an excerpt from a post I wrote about product strategy:

… I want to provide a relevant and concrete example using Tesla. I choose Tesla because a) Elon Musk is rad, b) Musk and Tesla have been unusually public and transparent about their strategy, and c) Tesla is a rare example of a company that has followed through on its strategy with execution that is down to the “T”. This puts it into a godly territory that is almost difficult to believe.

• Mission: “Tesla’s mission is to accelerate the world’s transition to sustainable transport.” (This was recently updated when Tesla merged with SolarCity.)
• Vision: To summarize, Tesla’s vision is to reduce vehicle carbon emissions through the advent of electric vehicles.
• Strategy: This is the famous “Master Plan”: 1) Build a sports car, 2) use that money to build an affordable car, 3) use that money to build an even more affordable car, 4) while doing above, also provide zero emission electric power generation options, and then finally 5) don’t tell anyone.

Interestingly, despite all of these benefits, many teams don’t (or don’t know to) explicitly define a clear product vision. Often, teams will home in on a short-term solution and begin defining, designing, and developing a product without a long-term vision. Product teams can go on for months and years building features and fixing issues based only on reacting to user or stakeholder requests without a clear end-goal in mind.
In the absence of a vision, product leaders from all backgrounds (product management, engineering, design, marketing, executives) are required to step in and define a vision and ensure that the team gets to a shared understanding.

We’ve spoken primarily about product vision at a grand level, but it can also be something as small as how a single feature can transform a user’s experience in the product. It is never too early for early- or mid-career professionals to practice developing and sharing a product vision.

In General Assembly’s part-time Product Management course, students practice developing a product vision as part of their final project. The course guides each student through the steps from identifying a problem in the market to solving that problem — no matter how small the product or feature may be — through the development of the product ideas into a concrete vision, executable roadmap, along with success metrics, and product design.

For businesses, train your team to get the full picture of the product development cycle. Through design thinking, lean methodology, and agile development skills, you can ensure your company is equipped to efficiently develop and deliver effective digital products and services.

Vince Law is a Product Management instructor at General Assembly San Francisco, where he has helped newly promoted product executives become effective leaders and aspiring product managers land jobs. He was previously GA’s director of product management, a role in which he directed, mentored, and built a team of 15-plus product managers across a spectrum of initiatives. In addition, he advises and consults various startups around the world, and blogs on Medium. He has previously served as the senior product manager at Storm8 and as a product manager at Kabam, and has worked in the consulting, finance, telecom, and automotive industries in various capacities.

By Cliff Gilley

Agile methodologies in product development are those that embrace the principles of the Manifesto for Agile Software Development, a set of guidelines created in the late 1990s by a group of software development professionals seeking to revolutionize the business. These methodologies focus on performing work in small, iterative steps that allow a product team to validate its assumptions and test hypotheses frequently. Examples of these methodologies include Scrum, Kanban, and Extreme Programming.

These Agile methodologies are often contrasted with “waterfall” approaches, which focus on defining as many of the requirements as possible before the project can begin, in as much detail as possible, so that there is no question as to what will eventually be delivered. The biggest downside of a waterfall approach is that it requires a large amount of up-front work and long development times before anything useful and testable is actually completed.

The importance of the Agile way of thinking cannot be understated in the modern business of software and general product development; its application stretches from development and quality-assurance work up into product design and management, and even into marketing and business strategy. While Agile began as a solution to a very specific set of problems developers were facing, it has grown into its own culture that permeates every aspect of modern businesses. It’s essential for any product manager to understand the fundamentals of Agile methodologies so that they can influence an organization to change for the better or engage more meaningfully with their teams on a day-to-day basis.

In practice, the most popular Agile methodology is Scrum, one of the first methodologies designed to deliver software products following Agile principles. In Scrum, the product manager creates a backlog of “user stories,” simple statements of the problem a development team is being asked to solve. Each user story gets stored in a “product backlog” that the product manager prioritizes according to business and other needs.

The development teams, usually sized between five and nine members for optimal effectiveness, look at these stories, estimate their complexity, and take some of them into a “sprint” as a commitment to deliver. A sprint is a two-to-three-week period during which teams work to deliver their commitments. During a sprint, the product manager and development teams work together to discuss, clarify, and deliver all of the previously agreed-upon stories. At the end of the sprint, each development team demonstrates to the product team and interested stakeholders what it has completed. Once the team has iterated to the point that the product team believes the work is worth sharing widely, a release can be created and push out the product updates.

There are other Agile methodologies, besides Scrum, that are important to understand given that many companies may pick and choose from one or another to build their processes. Kanban focuses on limiting works in progress, only allowing teams to take on a set number of stories or efforts at any one time, then working them through to completion before taking on more. Extreme Programming, on the other hand, is a very hands-off methodology that puts most of the power and authority on individual developers rather than taking a full-team approach. This methodology stresses that constant pairing and test cycles ensure quality outputs from the teams.

The main value of Scrum and other Agile methodologies lies in their focus on atomic units of work. The Scrum team commits to a small number of user stories for each sprint, which means that, at any time, the future work can be reprioritized, or even abandoned or added to without affecting the team’s work in progress. At the beginning of the next sprint, they look at the next set of priorities and commit to delivering another set of work. This is the opposite of “waterfall” methods, which establish a large commitment over the course of many months and apply strict processes for changing those requirements.

The other value in Scrum and Agile methodologies lies in the testing overhead required to validate the work the team completes. Because the team is delivering small sets of functionality, each of those sets can be tested during the sprint. This reduces the kind of massive, overarching integration testing required with a waterfall approach, in which everything is “done” only at the end of the entire project.

General Assembly teaches Agile methodologies as it relates to software development in our part-time Product Management course, full-time Web Development Immersive (WDI), and in workshops. We focus on the difference between the principles of Agile methods and the real-world application of those methods. Expert instructors, who have used these methodologies to help teams through Agile processes in their own careers, prepare students for the use of Agile through lectures and practical examples from their real-world experiences. In WDI, we reinforce Agile principles through lessons on user stories, pair programming, and more.

Product Management is the ultimate “jack-of-all-trades” role in a healthy organization. It’s one of the few roles where you’re likely to be needed to contribute to the success of so many other teams.

 – Cliff Gilley, Product Management Instructor, General Assembly Seattle