When you use sprints to develop software, the idea is that after each sprint you should have some new - working - version of your application. You incrementally add something useful to the product with each iteration, it's not just about organizing work.
What Mike Cohn is saying there is related to the difference between vertical and horizontal development. You should try to build features vertically, that means something that traverses all the layers of your application and can be used by users. It might not be full featured, it might just be something basic, but it's something users can use and provide you feedback on. Then, in the next iteration you add some more functionality, and some more, and so on. But at each step it's something that exercises all the layers of your application.
When you do horizontal development, what tends to happen is that people think like "this sprint we do the database, next sprint we do the service layer, next sprint we do the API, and next sprint we do the UI", or something like that. When you do this, not only do you risk having to do some rework because you assumed some things at each step and when you integrate you realize that you still have a lot to do, or you have to change something, but also the feedback loop gets bigger and bigger, and you need to wait more for users to provide input on what you are building.
If it's important for you to build the UI first, to reduce uncertainty and to collect feedback, then that's not necessarily a problem as long as you are doing that mindfully, being aware of the differences between vertical and horizontal approaches. Call it a discovery phase, or an exploratory phase, or prototyping, or investigation spike, or whatever, just be aware what you are doing, and let users know that what they are seeing is not an working increment because the UI is not connecting anywhere to do useful stuff.
A better approach would be to figure out how to put an UI in front of the users to gather feedback while investing the smallest amount of effort in it. There are tools like Invision that can help you do this without actually spending time building the real thing with developers and all (it's a bunch of interactive wireframes). Once you gather your data and build your understanding on what's needed and what's the less risky approach, you can then go build the real thing.