Permission Manager
Make app access easier to read, review and act on. A component-based redesign explored through a custom interface and a native direction based on Material 3.
- Year
- 2025–2026
- Scope
- Android app redesign, UI/UX and component system
A rebuild, with a clear constraint.
The task was to turn the existing app into a coherent system of reusable components, then explore two ways to express it. The feature set provided the starting point: risk categories, installed apps, permission groups, special access and settings.
There was no user base to learn from. I worked from the supplied interface and Android conventions; the decisions presented here are design hypotheses, without interviews, usability-test results or adoption metrics.
Give attention a clear order.
The original home screen gave four risk levels similar visual weight, followed by separate entry points into app access. My design reading was that the next step could be clearer: lead with access that needs a closer look, then keep the full app list within reach.
The redesign keeps the original categories and the sponsored placement while changing their hierarchy. Risk labels describe the app’s access categories; they do not establish that an app is malicious.
One structure. Two expressions.
The custom dashboard uses a large access count, a blue header and a wide green action to make the review route prominent. The Material 3 direction uses a quieter app bar, tonal surfaces and labelled list rows. Both keep the same tasks and information model.
- Custom
- A more expressive hierarchy: a prominent summary above a white content surface, compact secondary categories and a full-width primary action.
- Material 3
- A native visual direction: familiar headers, filled buttons, consistent list anatomy and text alongside each risk indicator.
Two ways to enter the same review flow.
Start with the apps that need a closer look.
Then inspect one app’s access.
App names, counts and sponsored content are part of the supplied example screens. They illustrate interface states, rather than measured product outcomes.
Build patterns that can repeat.
The component requirement shaped the redesign beyond the dashboard. App lists, permission details and settings share predictable structures, with content and state changing inside each pattern.
- App and access rows
- A leading icon, name, supporting text or permission count, and a clear next action. The same row anatomy carries different types of content.
- Headers and actions
- A consistent return path, page title and primary action establish a repeatable hierarchy across the two directions.
- Permission status
- Granted access is written out as “Allowed”, so the state remains understandable beyond the colour treatment.
- Sponsored placement
- The existing advertising area stays separate from permission information and the action used to open Android settings.
An empty category still has a next step.
No apps in a category is a valid state, not a broken screen. Both directions explain what is empty and offer a route back to all apps. The examples show different empty categories with the same underlying pattern.
Special access, in a familiar pattern.
Display over other apps, usage access and other system-level controls have a dedicated list. Each row names the access type and presents it as a route to the corresponding Android-owned control.
Know where the app ends.
The redesign explains granted access and provides an explicit “Open Android settings” action. Android remains responsible for its own permission controls; the app’s interface should make that handoff clear.
The Android capture is a platform reference. It shows Permission Manager’s own App info page, not the destination of Telegram’s button.
A clearer foundation to build on.
The work brings the original feature set into two component-based design directions, with app review, access details and empty states presented consistently. The case documents the design work; native implementation and validation with users are the next steps, rather than claimed results.
