Estos son algunos ejemplos de problemas que hemos ayudado a solucionar o crear:

Si la mayor parte de la información para la presentación está en las propias listas, ¿porqué repetirla en cada una de las pantallas? Igual como las pantallas base saben presentar los campos, pueden generarse pantallas que ellas mismas sepan qué campos presentar, en función de qué usuario la visualice, relacionándose con el resto de listas, presentando unos u otros controles, filtrando o no según datos anteriores, usuario o grupo al que pertenece, etc.

Para organizar mejor la información de los formularios sin necesitar un cliente especializado en formularios.
Pestañas y subpestañas que no cargan ni renderizan su contenido si no están visibles o que lo cargan igualmente por tener la información disponible al instante y/o evitar el postback. Que recuerdan cuál de ellas estaba activa y con scroll independiente.

Ya sea para tener el contenido en múltiples idiomas como para presentar la interface en varios idiomas sin replicarla.
Pudiendo utilizar un único diccionario o archivo de recursos para toda la aplicación y sus assemblies.
Pudiendo disponer de un sistema de excepciones para personalizar el diccionario al cliente sin perder su actualización genérica (y es que siempre hay quien utiliza otra palabra para nombrar lo mismo).

No siempre se llega a una pantalla desde el mismo lugar y por lo tanto no siempre al terminar debe volverse al mismo punto de origen. Cada pantalla debe saber de dónde se la ha llamado y finalizada su funcionalidad debe saber a dónde debe redirigir el usuario, conservando la vista, filtros, pestaña activa, etc. que tenía en el momento de entrar, pero actualizando su contenido.