Only really experienced developers are able to estimate properly. The reason is that the repetitive comparison between his estimations and what really happened (errors) teach him intuitively to increase his abilities.
Very few experienced developers or managers are able to estimate for others. Estimating for a whole team is even more complicated, and I personally believe it's impossible without proper tools.
That's why collective estimation such as planning poker coupled to velocity tracking is the way to go.
Planning Poker helps team avoid being affected by cognitive bias (thoughts being influenced by beliefs, environment, etc), while velocity tracking, later used in planning helps the manager to convert subjective estimations to realistic estimations.
UI design is no different than architecture or coding or testing -- it's part of the scrum process. Some say that in an ideal world the team will do all of that in a sprint -- but only enough UI design for that sprint. Others are more pragmatic and say it can't be done, and will do design in one sprint and coding and testing in another, or design and coding in one and testing in another.
A common pattern is to do design work / UI stories in one sprint and code in the next. After all, if you don't know what the UI is like there's no way you can estimate how much effort will be involved in coding. Consider the difference in the home page for google.com vs bing.com -- both have the same primary function, but bing.com has a considerably more elaborate UI design.
That being said, estimates are just that: estimates. Nothing in scrum requires that they are accurate only that they are consistent over time. Whether you estimate a story as a 5 or a 13 doesn't matter as long as similar stories are estimated the same way from sprint to sprint.
So, do what the team thinks is right -- do a UI story before doing the development, or do them together. If the PO says they have to be done at the same time, make sure you factor into your estimates all of the uncertainty. Do your best to estimate, knowing it will be wrong. Learn from that in your retrospective and talk about what worked and what didn't. Then, adjust your procedures going forward.
Above all, don't expect the estimates for the first half-dozen sprints or so to be the least bit accurate. Over time, however, regardless of the strategy you should start to do approximately the same number of points each sprint, which the PO can then use to predict how many stories you can do in a sprint.
Best Answer
Unless you are estimating something very similar to that which you and your co-workers have done before, +/-10% is ridiculously optimistic. Your management either doesn't have a lot of experience with software, or they're not aware of Large Limits to Software Estimation. That paper has some accompanying supporting material, and a lot of punditry can be found.
Let's examine a far simpler system than a typical software project: Rubik's Cube. You can solve any position in 20 moves, max. But since you're estimating, you can only look at a given cube for a few minutes before giving the solution. Can you give a good estimate? No, sometimes estimating a process takes longer than doing the process.
Another simple system: Pinocchio. A wooden automaton, his nose-piece grows when he utters a lie. What happens when Pinocchio is at rest, and then says "My nose is growing"? Some systems aren't amenable to prediction, they're undecidable.
These two problems are built-in to most software systems. Because of that, you'll never get estimates close to +/-10%.
My advice is to give a heavily padded estimate, work like a slave to get the project done as fast as you can, and then look busy until you're within 10% under or over. At that point, announce a spectacular success.