One of the most creatively liberating stages of the design process is the sketching and mockup phase. This, to me, is an exciting time for exploration, discussion, and thought (three ingredients that should be present at every iteration, but especially so here).
During this phase of the process, it's also fun to make super-beautiful, idyllic interface mockups that look just dazzling on paper/your computer screen. But when you're working on something people will actually use, I've learned it's important to keep "practical ugliness" in mind.
Practical ugliness is essentially any element that could be made ugly or ruined simply by the practice of using the interface. This includes any element that requires input from a source outside your control, including media libraries and text fields. Hot spots for practical ugliness are event titles, album titles, band names, movies, filenames, descriptions, variable actions, etc. etc. Even things like album art can conflict with carefully crafted transitions or super subtle background protection.
Keeping PU in mind can add another fun challenge to your design workflow, though. Before you present an interface or experience design, find the areas that could end up looking gross, and make them gross on purpose. Then zoom out a little bit and figure out how these areas can be improved so not even PU can stop your train of awesome interface design. In my experience, there's almost always a solution to these spots - finding what that solution is is the fun part.
Sometimes the answer is simple. Sometimes PU isn't strictly "ugly," just less than ideal. In the sketch above, two album covers are already pretty close to pure black-and-white, making the transition/loading animation almost invisible. This is fine, because it benefits the interface in other areas, but doesn't detract from the experience in this situation. The radio station's name is too long for the third card, but that's okay too because the solution is as simple as truncating the text.
For Today Calendar, we had a more interesting challenge with long titles. Letting the title take over multiple lines on top of the illustration would not only look messy, it would also cause problems in transitioning to the toolbar as the user scrolled downward.
This was immediately evident, and the solution we came up with was two-fold. First, titles would be automatically truncated, but users can double-tap to shrink down the text and see the rest of the title. When the user scrolls, the title merges into a tall header, as it aligns with the 72dp key line and scales to fit everything in.
This is an issue we would have faced eventually, but purposely demonstrating the issue (and possible solutions) in the first mockups clears it up immediately, and being thoughtful about potential PU on the front end of the process feels like a cleaner, more efficient way to work.
Braden Kowitz recently stated his rule for prototypes, which I think applies here: "make them as real as possible, as fast as possible."
Getting practical ugliness out of the way quickly and thoughtfully in your mockups, in this observer's opinion, can certainly help make designs that are realer faster.