Eu acredito que elaborar os Protótipos da Interface de Usuário (também chamados de mockups ou esquemas) seja algo muito interessante de se fazer antes mesmo de começar a codificar ou fazer o design de classes; porque os esquemas são uma forma muito fácil e rápida de idealizar todo o funcionamento do software e de verificar se ele atenderá ao seu cliente, é fácil mudá-los e eles podem ser feitos sem que código (que é mais difícil de mudar) tenha que ser implementado.
Os Esquemas são praticamente uma especificação bem detalhada dos Requisitos, você pode usá-los para se guiar ao definir a Arquitetura do Sistema (design de classes, pacotes/módulos, etc.) e ao codificar, pois você sabe que precisa simplesmente criar um Software que faça o que está nos Esquemas.
Esquemas também facilitam encontrar divergências nos Requisitos (requisitos conflitantes, sendo logicamente impossível atender a todos eles pois atender a um faz com que outro seja violado), que precisarão ser resolvidas antes de continuar.
Ao meu ver, é bem melhor esquematizar as telas do software antes de começar a criar classes.
Mas esquemas de GUI só são realmente úteis nos softwares baseados em GUI que simplesmente respondem ao que o usuário faz nela (a maioria dos softwares de gestão é assim); os esquemas de GUI não serão muito úteis em softwares que tem poucas Telas (ou nenhuma) mas fazem muita coisa (por exemplo, um software que Comprimi arquivos pode ter uma única Tela e um monte de código Complexo para fazer a melhor e mais rápida Compressão possível).
Você terá dificuldade em fazer os esquemas se não tiver noção dos Requisitos a serem atendidos, por isso, antes de fazer os esquemas pode ser necessário levantar os Requisitos em Alto Nível, com User Stories, diagramas de Caso de Uso, ou documentos de Texto que expliquem o que o Software precisa fazer. Esses Requisitos descritos em Texto (e possivelmente em tópicos e subtópicos) irão lhe guiar na criação dos esquemas de GUI, e, os esquemas de GUI (que poderão ser uma versão mais especificada dos mesmos Requisitos) poderão lhe guiar na Arquitetura do Software (Classes, Atributos, Métodos, Pacotes, etc.) e até na Modelagem do Banco de Dados.
Agora, sobre modelar a Arquitetura em O.O., você precisa tomar cuidados extras que não aparecem na esquematização e no levantamento de Requisitos em geral; você precisa verificar se sua Arquitetura será fácil de alterar e de crescer (estender), se é fácil de entendê-la, se é fácil e seguro de trabalhar com ela. Você pode estudar os príncipios SOLID, DRY, Programação para Interface, Injeção de Dependência, conhecer os Bad Smells, conhecer técnicas de Refatoração, Padrões de Projeto, TDD, etc., tudo isso existe pra te ajudar a entender como fazer uma Arquitetura que seja mais fácil de alterar depois e que seja capaz de crescer de forma sustentável e segura.
Uma Arquitetura ruim vai mostrar seus problemas ao crescer ou quando se tentar alterá-la, vai ser fácil surgirem Bugs (pois ela não é segura, pois não é seguro fazê-la crescer), vai ser fácil que coisas que funcionavam parem de funcionar (também por não ser segura, ou seja, não é seguro alterá-la), quando você visitar os códigos já feitos nem mesmo você terá a mínima ideia do que eles fazem e como fazem (códigos não claros em sua intenção, nomes ruins, métodos e classes fazendo muita coisa, um monte de ifs/loops aninhados, muito código num mesmo método/classe, falta de documentação, etc.), ficará cada vez mais difícil fazê-la crescer (adicionar uma coisa nova exige editar códigos em vários locais diferentes, que funcionavam antes de serem editados mas você não sabe se continuaram funcionando depois de serem editados, além do mais, se você esquecer de editar em um desses locais terá Bugs), e será mais fácil fazer o Software crescer criando gambiarras que só vão te trazer mais problemas como esses do que fazê-lo crescer simplesmente adicionando novas classes através de um Padrão bem estabelecido, que é claro e seguro.
Com uma boa Arquitetura, as coisas estarão bem organizadas, será fácil entender como as elas funcionam, será mais fácil alterar e estender o Software (o ideal é que você pudesse estender apenas adicionando Classes, e, talvez, tendo uma Classe “sempre aberta para edição” para instanciar e montar [popular] os Objetos, que te permitiria instanciar as novas Classes ou usar as Novas Classes no lugar das Antigas [afim de mudar comportamentos]). Com Testes automatizados, Interfaces que limitam o acesso somente ao necessário, e encapsulamento você conseguirá tornar o Software mais seguro contra Bugs, porque dificultará (ou impedirá) que sejam feitas gambiarras que iriam comprometer o Padrão que você criou para o crescimento do Software.
Mas dê enfase em manter o princípio DRY, procure mantê-lo na Documentação, na Arquitetura, e no Código dentro das Classes. Ficar violando esse princípio vai tornar seu Projeto extremamente inseguro (em relação a bugs e inconsistências) e difícil de crescer e de alterar.
