Figure 1. We use persona and scenario to describe the goal that a user wants to achieve (Cooper et al., p.375)

The findings from observations and interviews have to be unpacked, synthesized, and written to articulate who the users are, what goals they have, and what tasks they need to perform. We call this step a define step or a define step. In the define mode, you should create a persona(s) and scenario(s). A persona is a user archetype based on the characteristics of people that you observed and/or interviewed (Cooper et al., 2007). A scenario is an informal narrative about how the persona uses a prototype that you design and build to perform tasks. It should describe how the prototype system supports the user to achieve their goal, what the system does, in what context it is used, and what data it needs to operate (d.school, 2010). Persona and scenario together help you describe requirements.

It is crucial to define personas and scenarios to

Scope the system functionalities and for whom and how it serves, and
Communicate that information to stakeholders.

Scoping the system's functionality to limit its target users increases the likelihood of the system being useful. This may be counter intuitive, but when you extend a product's functionality to serve many users with broad needs, you increase the cognitive load and navigational overhead of the system for all users (Cooper et al., 2007, p.62). So, the best way to successfully accommodate a variety of users is to design for specific types of individuals with particular needs. Personas define who the system is for, and scenarios define what functionality the system offers.

Personas and scenarios facilitate communication between the system's stakeholder. A written form of requirements can be shared between designers and developers who are involved in building the system. Other stakeholders are people or organizations who will be affected by the system and who have a direct or indirect influence on the system requirements (e.g., clients, marketing department) (Preece et al. 2015). See also the following tips for techniques to communicate the persona:

Assignment Tips

Persona

A video explaining what a persona is (9:20-15:20)

An example of a persona from https://www.interaction-design.org/literature/article/personas-why-and-how-you-should-use-them

A persona is not a real person, but it is synthesized from the characteristics of existing people. It is not a stereotype, but it is a composite archetype based on behaviour patterns uncovered through a design process. It has a distinct set of behavioural patterns supported by data and forms a motivation range (goals). Each persona represents a significant portion of people in the real world and enables the designer to focus on a manageable and memorable cast of characters, instead of focusing on thousands of individuals. Personas aid designers to create different designs for different kinds of people and to design for a specific somebody, rather than a generic everybody.

You'd want to collate data from observation and interviews that would be useful for you and your team to relate to the users' point of view. It will launch you into generative ideation. It is a good idea to collect and collate at least the following pieces of information:

User. You should bring them to life with name, their characteristics, attitudes, activities, goals, personal background (e.g., where they are originally from), frustrations (breakdowns, pains), and so on. Consider including demographic information like age, occupation, ability (e.g., unique technical skills, disabilities), experience in using computing devices, etc.
Goals. Users' goals are descriptions of an end state where a user wants to be. For instance, imagine that you are trying to empathize with a wheelchair user who need to travel to unfamiliar city. Her goal may be to "understand the accessible areas of a city" or "understand the hotel room's accessibility." Don't confuse goals with tasks; tasks are intermediate steps that the user takes to achieve the goal.
Breakdowns. Events that prevent people from achieving their goals are referred to as breakdowns. Usually, these are associated with users' pains in using a software system. For instance, though a user wants to connect to a database for her research, something (e.g., lost internet connection, authentication failure) prevents her from doing so. Here, the event that prevented her from accessing the database is a breakdown, and the consequence that she experienced is a pain.

We could classify personas into different types depending on their roles and importance to your design process (Cooper pp.75—106):

Primary: The one most important user persona
Secondary: Users with additional (lower priority) needs
Supplemental: Needs already represented by primary and secondary