Mayara Castro
← All case studies

Product · Internal tool · Permissions

One calendar for three brands’ content

I designed and built an internal tool for the marketing content team to plan posts, emails, videos and events for three brands in one place, with each piece’s status coming from Jira. About 12 people use it every day.

Company
Appmax, internal marketing tool
Role
Discovery, flows, interface and development
Team
Just me, with the team’s project manager
Timeline
August to October 2026
Tools
FigJam, Vue, Firebase, Jira
Outcome
Used every day by about 12 people on the content team

Context

Appmax’s marketing content team planned posts, emails, videos and events for three brands. The planning lived in spreadsheets, and each piece’s status lived in Jira. The request came from the team itself.

The interface is in Portuguese, as it was built for a team in Brazil.

Problem

Each brand had its own plan, and each channel had its own list. To know what was going out that week, someone had to put everything together by hand, and the status of each piece sat in Jira, outside the spreadsheet.

My role

Calendário 360 was one of the internal tools I was responsible for, from design to code. I did the discovery, the flows, the interface and the development on my own. I gathered the users’ needs together with the team’s project manager.

Process

Discovery

Before designing any screen, I started from what the team already used, to see where the information lived:

  • The semester’s project spreadsheet, with the owner, priority and dates of each project for the three brands.
  • The Jira board, which held the copy, assignee and progress of each piece.

Permissions before screens

Before the interface, I mapped out in FigJam who can see, create and edit what. The flow below comes from that board, redrawn with the people replaced by their areas.

Permissions flow: the question about the person’s role (management, scoped editor or viewer), the scope by work area and the category check, through to the real-time save
The permissions flow, from roles to the real-time save. Open the full flow ↗
  1. The person opens the calendar
  2. Already signed in? If not, they sign in with the company Google account. Anyone using an email from outside the company gets “access denied”.
  3. The calendar identifies the person’s role and the area they work in
  4. AdminCreates, edits and deletes any content. Manages people and permissions.
    Scoped editorCreates and edits only what belongs to their area (social media, public relations, content and email, design). Outside it, view only.
    ViewerSees the calendar, roadmap and lists, without editing.
  5. Every change shows up instantly for everyone

In the code, the three roles (admin, editor and viewer) are also enforced in the database rules.

Six releases

The first three releases were ready between August 5 and 10. Two later improvements came from the team’s requests: the project name on top of each piece (September 29) and creating pieces from Jira tasks (October 8).

ReleaseWhat it added
1Calendar by week, month and day; sign-in restricted to the company domain and roles enforced in the database
2Screens to manage channels and people, combined filters by project, channel and brand
3Each piece’s status pulled from Jira every 30 minutes
4Projects with type, owner and phases, and a weekly roadmap view
5Jira epics in the sidebar, with status and due date
6Pieces created automatically from Jira tasks
Roadmap view: each project on a row, with a duration bar, phases and the number of pieces per week. Interface in Portuguese
Roadmap: a solid bar has a start and an end; a gradient tip means an open date. The number in each week is the count of pieces.

The interactive demo

The demo runs the same code as the product, with fictional brands, projects and people and no database. Everything runs in the browser and resets when the page reloads. The interface is in Portuguese.

Live demo: create and edit pieces, switch views and roles in the bottom bar Open Calendário 360 in full screen ↗

Decisions

  1. Jira stays the source of status What I saw

    Each piece’s copy, assignee and status already lived in Jira, where the team works.

    What I decided

    The status shown in the calendar comes from Jira, updated every 30 minutes, and only Jira can change it.

    Why

    That way there is a single version of each piece of data, and the team doesn’t have to update the same status in two places.

  2. Open dates show up on the roadmap What I saw

    Not every project has a set end date, and the team needs to see what is planned week by week.

    What I decided

    On the roadmap, a solid bar marks a project with a start and an end, a gradient tip marks an open date and each week shows the number of pieces.

    Why

    At a glance, the team can tell what already has a deadline from what still needs a date.

  3. Three levels of access roles What I saw

    Social, press, content and design each look after different parts of the calendar, and many people only need to look things up.

    What I decided

    Three roles: admin, who manages everything; editor, who creates and edits; and viewer, who sees the calendar, roadmap and lists without editing. In the designed flow, editors work within a scope by area. In the code, roles are also enforced in the database rules.

    Why

    People who only look things up can see everything with no risk of changing anything, and permissions don’t depend on the interface alone.

Outcome

The marketing content team, about 12 people, uses Calendário 360 every day. Two improvements came from requests made after the team started using the tool: the project name on each piece and creating pieces from Jira.