Folio Mobile concept 2026
The daily sales report, before the first meeting of the day
Folio is a report library: shelves of folders holding every pack, deck and dashboard a finance team publishes, with access managed per folder. I designed the desktop library, then extended it into an iOS app as my own concept.
- Role
- Product Designer (sole designer)
- Timeline
- Month to Month 2026
- Team
- N engineers, me
- Skills
- Mobile design, Information architecture, Access UX, Component design
My role
So my job was to get the right report open before the meeting starts.
I redesigned the desktop library (shelves, folders, report info, request access and admin mode), then designed the iOS app, its folder component and its states on my own.
- Problem
- Reports sat several folders deep in a desktop portal, and the leaders who needed them on the move had no good way in.
- What I did
- Designed shelves of folders that show what's inside before you open them, report details in a sheet, and access requests in two taps.
- Result
- A concept built so a leader can get from a notification to the right report, and ask for access, without a laptop.
The desktop library is client work, shown with a new name, made-up data and a new visual identity. The iOS app is my own concept built on it.
Problem
The report was always there…
Folders were deep, names were long, and access was all or nothing: a locked report only said so after you'd found it. On a phone, the desktop portal meant pinching and guessing.
…but finding it, and getting into it, on a phone was the hard part.
Leaders read these packs before meetings. A report you can't open in time might as well not exist, and asking for access by email meant waiting with no idea where the request had got to.
Who it’s for
- LeadersRead packs and dashboards, often on a phone before a meeting.
- PublishersUpload new versions and keep folders tidy.
- Business ownersDecide who can open a folder, and approve requests.
From a desktop portal on a small screen to an app made for it.
Before: Deep folders and long names
After: Shelves of folders that show what’s inside
Before: A locked report only said so after you’d found it
After: The lock shows before you tap, with who manages access
Before: Access was all or nothing
After: A request in two taps, with a status you can track
Before: Pinching and guessing on the desktop portal
After: Details in a sheet, favourites one tap away
Discovery
How do people use reports on a phone?
On a phone people rarely browse. They come back to the same few reports, and they want to know they can open one before they tap it.
I started from the desktop library's structure (shelves, folders, report info, access) and the two iOS screens that already existed, then designed the rest of the app around three moments: finding a report, checking it, and opening it. Add any feedback you had from people who use the library.
- Structure
- The same shelves, folders and permissions as the desktop library. Mobile couldn't invent its own.
- Access
- Folders and reports can be restricted. Owners approve requests; the app can only ask.
- Files
- PDFs, decks, spreadsheets and Power BI dashboards, which open in different places.
Core idea
A report is only useful if you know three things before you tap it.
Every screen answers them in the same order: what it is, who stands behind it, and whether you can open it.
The report checklist
- The file
- Its name, its type and the folder it lives in.
- The owner
- Who publishes it, how often, and when it last went out.
- The access
- Its security level, and a request if it’s locked.
- A report you can trust
- Found, checked and opened from a phone.
Decisions
Three calls shaped the app.
Decision 1: Folders show what's inside before you open them
The folder component has states for closed, peek (its files rise when you press) and open, plus a locked variant that shows who manages access. You know what you'll find, and whether you can open it, before you commit to a tap.
One folder, four states Decision 2: Report details live in a sheet
The info button opens a sheet over the folder: owner, publish date, frequency, security level and versions. Close it and you're exactly where you were.
Report details in a sheet Decision 3: Access in two taps, with a status you can see
Request access opens a short form with the approver already filled in. The report then shows Pending, the Requests tab tracks it, and a notification says when it's approved.
Request, pending, approved
Solution
A leader can find a report, check it, and ask for access, all from a phone.
Here are the home shelves, then the flow from folder to report and the states around it.
From the home shelf to an open report.
- 1Open the shelfFolders peek to show what’s inside before you open them.
- 2Find the reportBrowse sub-folders by year, or search.
- 3Check the detailsOwner, publish date, frequency and security, in a sheet.
- 4Ask for accessThe approver is filled in, and the report shows Pending.
- 5Get notifiedA notification says it’s approved, and the report opens.
- 1Search, and a switch between all reports and the ones you can open.
- 2Shelves of folders, each showing how many reports are inside.
- 3A locked folder says so before you tap it.
- 4Tabs for reports, favourites and your access requests.
Every dead end says what to do next
No search results suggests a broader term. An empty favourites list explains the star. Offline, saved reports still open and the rest are marked, instead of failing when you tap them.
Open it, save it for offline, or keep it close
Documents open in a viewer with share and save-offline actions; dashboards hand off to the browser, and the row says so before you tap. Favourites keep the few reports people return to one tap away, and a swipe removes one.
The same library, at a desk
On desktop, report info opens in a modal with the full path, owners and version history, and admins switch into a mode for publishing and editing reports. The mobile app reuses its structure and its access rules.
Before and after
From two screens to a whole app
The iOS work started from two screens: a report list and its detail sheet. The concept keeps their structure, then rebuilds them around the folder, the sheet and an access state you can see.
Before
After
More screens
Requests, dead ends and the moments in between
Outcome
Built so the report is open before the meeting starts.
These are the effects the design was built for, not measured results. Next to each is the signal that would show it.
Leaders open reports from their phones, not only at a desk
What would show it: Share of report opens that come from mobile.
Access requests stop going by email
What would show it: Requests raised in the app, and the time from request to approval.
Fewer dead ends on locked reports
What would show it: Taps on locked folders that turn into requests instead of exits.
Reflection
What did I learn?
Designing the folder as one component with states made the whole app simpler. The same object appears on the shelves, in search and in the access flow, and it behaves the same way everywhere.
What would I change?
This is a concept. Before building it I'd test the peek state with real users: a press that previews content feels natural on iOS, but it must never slow down someone who just wants to open the folder.
Next case study
Leanburn