This is a SM function which allows you to "cheat".
If you want to do a proper refit, you have to make a new design, not edit the existing one, tool a shipyard to the new design (if the changes are small, you might be able to build both versions from the same yard, i.e. you can use the yard tooled to build the old design) and start a refit for the ships you want to change.
There is also a computer science issue here. Each Ship instance effectively points to (in a relational DB sort of way) a Class Design instance. It also has some cached local data that depends on the design data.
When you change a design, you're changing the corresponding class instance. Since the ships point to that instance, you've just changed their state. This is why "locking" is present for designs - it effectively puts the design instance into a read-only state, so you don't get a side-effect on the ships if you change it. When you unlock the design and modify it, you're doing something the program doesn't really intend for you to do. The way it's intended for you to change the design of a ship is to do a refit to a new, modified design.
The reason this is important is the cached local data in the ships. It does NOT get updated when you change the design. Instead, it gets refreshed at other spots in the code. This is why (I'm 99% sure) Brian told you to look at each ship - the act of viewing the ship updates the local cache.
So one thing to be aware of: please do NOT log bugs if you've unlocked a design and modified it and the ships that are using it are acting weird. You're skiing out of bounds the moment you modified a design that ships are using....
John