How a UI Designer UI works

Your UI isn't a pile of Frames saved in StarterGui. It's a design stored as data (the blueprint), and the BloxUI runtime builds the real ScreenGuis from it on each player's screen when the game runs. Knowing this saves you a lot of confusion.

The three parts#

Part	Where it lives	What it does
The blueprint	`ReplicatedStorage > BloxUI_Blueprints > <Name>` (a StringValue)	Your design as JSON text: the screens and tabs, the HUD, currencies, shop items and prices, colours, fonts and sounds.
The runtime	`ReplicatedStorage > BloxUI` (a ModuleScript)	The library that turns a blueprint into a finished UI, with animations, sounds, phone layouts and the server side (`UI.Server`).
The loader	`StarterPlayer > StarterPlayerScripts > BloxUI_BlueprintLoader`	Runs on each player's device. It builds every blueprint in `BloxUI_Blueprints` and opens its start screen.

What happens when a player joins#

Roblox copies BloxUI_BlueprintLoader to the player, like any script in StarterPlayerScripts.
The loader waits for ReplicatedStorage.BloxUI and the BloxUI_Blueprints folder.
For every StringValue in that folder, it reads the JSON and repairs anything broken (a missing value gets a safe default). If it had to repair something, Output shows a line like [BloxUI] BlueprintLoader: "NeonStrike" was repaired in 2 place(s).
It builds the UI into the player's PlayerGui as a few ScreenGuis: BloxUI_Hud, BloxUI_Screens, BloxUI_Popups, BloxUI_Menus, plus a few more while effects play.
It registers the UI under its name, so your scripts can get it with UI.Blueprint.waitFor("<Name>"), and opens the start screen.

A blueprint whose Enabled attribute is false is skipped. A blueprint added to the folder while the game is running is built too.

On the server, UI.Server (started by the last line of <Name>_ServerHooks) reads its own copy of the same blueprints. That's how it knows the real prices and rewards, so it never has to believe what a player's device says. It also creates the BloxUI_Action RemoteEvent the buttons talk through.

Why you change the design, not the instances#

The Frames and buttons you see while playing are made fresh every time the game runs. That means:

They don't exist in edit mode. StarterGui is empty, and there's nothing to click on in the Explorer until you press Play.
Edits made during Play are thrown away. Change a button's colour in the Properties window while playing and it's gone when you stop.
A script that digs into them breaks easily. PlayerGui.BloxUI_Screens.Canvas... paths can change when the design or the runtime changes. The runtime gives you handles instead.

So you change what the UI is in the blueprint, and what it does in your scripts.

What's safe to edit#

Thing	Safe?	How
The hook scripts `<Name>_UIHooks` and `<Name>_ServerHooks`	Yes	Fill in the handlers. This is your code, and new installs never overwrite a hook script you've edited (Updating).
Your own LocalScripts and Scripts	Yes	Talk to the UI through the runtime (below).
The blueprint StringValue	With care	Change it with a Command Bar script that decodes the JSON, changes a field and saves it back, for example to add real product ids, the logo text or the main colour. Scripting your UI has a ready block. Keep a copy of your changes: installing a new version replaces this StringValue, so run your block again afterwards.
The `Enabled` attribute on a blueprint	Yes	Set it to `false` to stop the loader building that UI.
`ReplicatedStorage.BloxUI` (the runtime)	No	Updates replace it, and your changes would be lost.
`BloxUI_BlueprintLoader`	No	It must stay in StarterPlayerScripts and enabled.
The ScreenGuis in PlayerGui during Play	No	They're rebuilt every time. Use the runtime's handles instead.

Talking to the UI from code#

Your LocalScripts get the built UI from the runtime and work with it by name and id, never by digging through PlayerGui:

LocalScript in StarterPlayerScripts

local ReplicatedStorage = game:GetService("ReplicatedStorage")
local UI = require(ReplicatedStorage:WaitForChild("BloxUI"))

-- the loader builds the UI and registers it under its name
local ui = UI.Blueprint.waitFor("NeonStrike")

ui:on("Rebirth", function(context) -- a button's event
	print("Pressed", context.id, "on", context.screen)
end)
ui:open("shop")                    -- open a screen by its id

<Name>_UIHooks already starts like this, with a handler ready for every event your design fires. The full list of what you can do is in Scripting your UI.