---
sourceDocument: Australia Build or modify applications
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/pt-BR/application-development

 Release :

    - australia

ft:locale :

    - pt-BR

ft:publication_title :

    - Australia Build or modify applications

ft:clusterId :

    - cadev

bundleId :

    - cadev

workflow :

    - Development, Data, and Analytics


---

# Understanding personas

# Understanding personas when creating applications {#ariaid-title1}

* Versão de lançamento: Australia
* 
* Atualizado 12 de mar. de 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 1 min. de leitura

Learn about personas and how to analyze personas before creating an application.
Before creating an application, you should understand who will use the application and why. Personas provide a mental model of the user's goals, behaviors, and pain points. They help teams design experiences that align with real-world
workflows rather than assumptions. Applications built without persona-driven design often lead to fragmented experiences, forcing users to jump between resources and slowing adoption.

## Common personas {#dev-get-start-understand-personas__section_k1f_3fv_whc}

Applications created in the ServiceNow AI Platform typically serve multiple personas that have different responsibilities including the following:

* Low-Code/Citizen Developers are tech-savvy but not formally trained in coding. They may use ServiceNow Studio to build applications with templates and maintain them through their lifecycle.
* Professional developers are skilled in scripting and advanced customization, and may work alongside citizen developers to extend functionality beyond low-code boundaries.
* IT agents (users with the ITIL role) handle incidents, service requests, and asset management. They may need mobile-friendly applications for quick ticket resolution and on-call scheduling.
* Administrators manage roles, security, and governance, and may also do development work.
* End Users (requesters) are employees or customers initiating requests, approvals, or browsing knowledge. Their experience should be simple, branded, and accessible through portals such as Employee Center.
{#dev-get-start-understand-personas__ul_pjf_jgv_whc}

## Researching personas {#dev-get-start-understand-personas__section_fwj_3fv_whc}

* Interview stakeholders to uncover goals and pain points.
* Use existing persona information, such as persona foundation cards or internal libraries, to identify similarities and differences among roles.
* Analyze existing applications (especially similar ones) and usage patterns in your instance.
{#dev-get-start-understand-personas__ul_wh3_ygv_whc}

## Key considerations {#dev-get-start-understand-personas__section_akp_3fv_whc}

* Avoid rigid persona silos. Many roles overlap (for example, admins often act as developers and vice versa). Design flexible experiences that accommodate hybrid responsibilities.
* Map tasks to outcomes. Focus on what users need to accomplish rather than just their job title. This approach prevents over-engineering features that don't add value.
* Plan for scalability. Use configurable workspaces and templates aligned with persona needs to reduce maintenance overhead.
{#dev-get-start-understand-personas__ul_or5_nhv_whc}

