Case Study · 2025 Shipped Q2 2025
Good Lock Redesign for One UI 7
Samsung’s deep-customization app could change almost everything about a Galaxy device, and users still couldn’t find the one thing they came for. I ran the research that isolated why, proposed the architectural fix, and when it wouldn’t fit the release window, shipped a feature set that delivered most of its value at a fraction of the cost.
What Good Lock is, and why the timing mattered.
Good Lock is Samsung’s playground for power users: a hub of modules that let you rewire almost every surface of a Galaxy device. Lock screen, navigation bar, quick panel, keyboard, S Pen, gestures. Its strength is the sheer breadth of what it can change.
That same breadth was the problem. The library had grown faster than the structure holding it, and the app now asked every user to learn its internal logic before it would give them anything.
One UI 7 raised the stakes. The same release took Good Lock global for the first time, so a much larger and far less specialised audience was about to meet an app built around the habits of people who already knew their way around it.
The brief
Identify the critical UX issues and user complaints holding Good Lock back, and get the experience ready for a global One UI 7 release.
Three methods, deliberately chosen to disagree with each other.
Good Lock had years of accumulated complaints sitting in public. That is an unusual luxury, and an unusual trap, because the loudest complaints are rarely the most costly ones. I wanted evidence from three directions so I could tell the difference.
- Heuristic evaluation A structured pass across every module, scored against usability heuristics. This separated design debt from feature gaps: where the product was broken, versus where it simply didn’t do something yet.
- Secondary research on community forums Systematic mining of Good Lock discussion across community forums, cataloguing complaints and feature requests in users’ own words rather than in ours. This is where the emotional register of the problems showed up.
- User interviews Sessions with active Good Lock users, walking through their real device setups and reconstructing how they got there. Artifact-anchored, so we discussed what they had actually done rather than what they thought they did.
Triangulating the three did the real work. The heuristic pass told me where the design broke. The forums told me where users noticed. The interviews told me why it mattered enough to leave a review about.
Five requirements, drawn from three problem areas and two behavioural patterns nobody had complained about.
Once every complaint was on one wall, three problem areas separated out from the noise. Each is stated below with the requirement it generated, because a finding that doesn’t become a requirement is just an observation.
Problem 01
Modules don’t say what they do
Module names carried no clue about the surface they touched. Users couldn’t tell what a module was for without installing and opening it, which meant exploration cost real effort and produced mostly dead ends.
R1. A user must be able to identify what a module changes without opening it.
Problem 02
You can’t find the feature you came for
User flows showed a consistent pattern. People install Good Lock for one specific thing, a lock screen clock or a nav bar gesture, and then get lost in a maze of menus, submenus and module names that map to none of it. There was no search of any kind.
R2. Features must be findable by the part of the phone they change, not only by the module that happens to ship them.
Problem 03
Active features are invisible, and silently overridden
Turning a feature on left no trace anywhere. Active customizations vanished into the architecture. Worse, modules could override each other without saying so: a lock screen animation would simply stop working because a different lock screen module had claimed the same surface.
Users reported features “randomly” switching on and off. In interviews this was the most emotionally charged issue by some distance. Their device had stopped behaving the way they had told it to, and they had no way to find out why.
R3. Every active feature needs one honest home, including when it is being blocked by something else.
Two requirements nobody filed a complaint about
The forums surfaced what users were annoyed by. The interviews surfaced two things they had simply accepted, and those turned out to shape the roadmap more than any of the complaints did.
Behavioural pattern 04
Customization was permanent, but users’ needs weren’t
Power users, the core of Good Lock’s audience, didn’t only want to change how their phone behaved. They wanted to control when it behaved that way. Good Lock offered enormous control over the what and none at all over the when. Nobody asked for this in a support thread. It showed up as people manually reconfiguring their device around their day.
R4. Customizations should be conditional, not permanent.
Behavioural pattern 05
The library was the best thing about the product, and the least used
Most users arrived for a single feature and left with exactly that, leaving the rest of the library untouched. Yet the users who did explore consistently found more than they came for. The depth of the catalogue is what turns a Good Lock user into a Good Lock advocate.
The tension is that pushing discovery harder risks interrupting the one task that brought someone in. Discovery had to be offered, not imposed.
R5. Surface the library without interrupting the errand.
And the reframing that produced the one that did.
If the architecture was the root cause, the honest fix was to rebuild it. I proposed reorganising Good Lock around touchpoints rather than modules: a virtual device mirroring your own, where you navigate to the part of the phone you want to change and see every feature that touches it, regardless of which module ships it.
It answered R1, R2 and most of R3 in a single move, and gave the app a genuinely distinctive interaction model in the process.
Why it didn’t survive
In review, the engineering overhead came back as incompatible with a three-month development window ahead of a global release. The concept was right. The timing wasn’t.
The reframing
Rather than spend the window arguing for the rebuild, I changed the question: which outcomes of that architecture could be delivered without rebuilding the architecture?
That reframing produced the shipped feature set. Each one is an independent, buildable answer to one of the five requirements, and each could be cut without taking the others down with it, which is exactly what you want going into a fixed release window.
Six features. Each one traceable to a requirement.
Feature 01
Good Lock Search
A single search spanning every module at once, matching on module name, feature description, and the touchpoint being customized. Whichever of those three mental models a user arrives with, the same query works, which mattered because research showed users arrive with all three.
Answers R2. Findability
Feature 02
My Device
One page listing every active customization on the device, with explicit indicators when a feature is blocked by another module or can’t function as intended. The “random” behaviour users described was never random. It was a conflict with no interface. This gave it one.
Answers R3. Transparency and conflict visibility
Feature 03
Module filters
Filter chips on the home screen that group modules by the touchpoint they customize or the kind of feature they offer. This is the touchpoint model from the rejected architecture, delivered as a filter layer rather than a rebuild. Most of the navigational benefit, a fraction of the engineering cost.
Answers R1. Exploration, and reinforces R2
Feature 04
Announcements & Recommendations
A card in the app bar surfacing new features and module updates. The behaviour is the design: it sits above all functions for people who are browsing, and disappears on a slight scroll for people on an errand. Discovery offered, never imposed.
Answers R5. Discovery without interruption
Feature 05
Samsung Routines integration
Customization presets that bind to Samsung Routines and Modes. One configuration at home, another at work, another when Sleep Mode triggers. This is the change that moves Good Lock from a settings app toward a rules engine, making the customizations as controllable as they are impactful.
Answers R4. Conditional customization
Under NDAFeature 06
Good Lock NLP Search
A conversational layer over search, intended to merge into it. Describe what you want your phone to do, and an LLM assembles the feature set and the preset to get you there. It reached the Good Lock beta, region-locked to Korean devices.
It was cut before the final release. Under test, the model’s results weren’t reliable enough to earn a place in the flow, and a conversational search that is worse than the deterministic one is a downgrade wearing a new coat.
Extends R2. Findability, conversationally
Under NDAEvery requirement, and the thing that answered it.
- R1. Identify a module without opening it Module filters, grouped by touchpoint and feature type
- R2. Find features by surface, not by module Good Lock Search across name, description and touchpoint. NLP Search (cut)
- R3. One honest home for active features My Device, with explicit blocked and conflicted states
- R4. Conditional, not permanent, customization Samsung Routines and Modes integration
- R5. Discovery without interrupting the errand Announcements card, dismissed by scroll
Including the number I can’t claim.
Good Lock for One UI 7 shipped in Q2 2025. The same release made the app globally available for the first time.
Which means install growth is not a number I can honestly attribute to this work. Two variables changed at once, and I would rather say so than take credit for a distribution decision. What the redesign can be measured against is reception, and reception moved.
Coverage
The new experience was picked up in independent reviews and walkthroughs, with the commentary landing on the things the research had targeted: findability, and being able to see what your phone is actually doing.
The architecture proposal still stands
The filters bought most of its navigational value inside the window, but they treat a symptom. A touchpoint-first Good Lock remains the right long-term answer, and the shipped feature set is a much better argument for it than a deck was, because users are now demonstrably navigating by surface.
Cutting the AI feature was the right call
NLP Search was the most exciting thing on the list and the first thing to go. An AI surface only earns a place in a flow when it beats the deterministic version of itself, and at that point it didn’t. That test has shaped how I scope AI features since.
Complaints tell you where it hurts, not where to operate
The two requirements that changed the roadmap most, conditional customization and non-intrusive discovery, appeared in exactly zero support threads. They only showed up when we looked at what people had already built on their own devices.
Roles, collaborations, or the parts of this project I can only walk you through in person.
- amanibnsalim@hotmail.com
- linkedin.com/in/aman-salim1
- Phone
- +91 91676 09846
- Based in
- Bengaluru, India
Replace each of these with your real details. Anything under NDA is best handled over a call rather than a link.