working on the server backend, and developing the UI

Server-side backend development and user interface work differ in more than just technologies. There is a noticeable difference in rhythm, and the interactivity levels.

With UI-oriented changes testing is often manual, goals are less than clear since they usually involve look-and-feel, and it takes a product owner's gut feeling to accept changes. While it is relatively quick and easy to get a thumbs-up or -down on an implemented feature, it is a lot harder to get a decision on a designed but not yet implemented idea. (Unless you build realistic-looking prototypes and/or mock-ups, but that could take amount of work similar to doing the actual implementation.)

The mini-iteration of working closely with a product owner is very tight - a short conversation, sometimes an attempt to replicate a problem, an hour of coding, a delivery followed by a quick test by the product owner, a decision, start over. Four of those in a day give a feeling of being productive. However, the actual changes delivered can vary widely - from user-experience-altering updates to the interface to tiny modifications.

Backend work is usually specified in large chunks by one or two short sentences. (Such as, "Make the system handle 1mln users.") It takes more than one conversation with the product owner about the task, and the implications of various design decisions. Visual aids require significant creativity, but are well worth the trouble as your conversation with the product owner will go so much better.

Once a task is defined and a design has emerged, the test are needed to "lock down" system behavior and verify the new features. Bugs come out of the woodwork, inconsistencies start to shine through, begging for refactoring. It takes discipline to stick to the narrowest definition of the problem at hand, and not resort to hacking your way through.

It helps tremendously to have a test suite that can detect regressions, and does not take too long, so that it can be run early and often. Prepare to spend hours to figure out why a particular test is broken in a particular way. (Count yourself lucky, and your team brilliant, if your tests are short, self-explanatory, and the reasons for errors can be easily traced.)

The mini-iteration starts with some implementation design, writing a test, then code, then getting the test to work. Then run the test suite, fix what's broken, run all tests again. After a few of those, integrate with the client. A mini-iteration can last a couple or more days, and that feels slow and unproductive. Add to that the frustration of trying and failing to explain to a product owner why the task is taking so much time. (If a task is not done in a week, it may make sense to cut down scope.) Once the task is completed, the product owner will completely forget it was ever a work item.