O design de qualquer API requer um equilíbrio entre vários factores, tais como a simplicidade na realização de operações comuns versus generalização, ou muitos comandos com poucos argumentos versus poucos comandos com muitos argumentos. Nesta secção pretende-se descrever as considerações peculiares ao design de um API 3D que influenciaram o desenvolvimento do OpenGL.

Desempenho
   Uma questão fundamental em gráficos tridimensionais interactivos é a do desempenho. São necessários inúmeros cálculos para renderizar um cenário 3D de modesta complexidade e, numa aplicação interactiva, um cenário é redesenhado várias vezes por segundo. Desta forma, um API desenvolvido para ser utilizado em aplicações 3D interactivas, deve oferecer um acesso eficiente às funcionalidades do hardware gráfico que utiliza. No entanto, diferentes subsistemas gráficos oferecem diferentes funcionalidades, pelo que deve ser encontrada uma interface comum.
   A interface deve igualmente oferecer meios para a activação ou desactivação das várias funcionalidades de renderização. Este requisito é importante porque algum hardware pode não suportar algumas funcionalidades com um desempenho aceitável e mesmo com o suporte por hardware, a activação de certas funcionalidades, ou de combinações de funcionalidades, pode afectar significativamente o desempenho. Uma renderização lento pode ser aceitável na produção de uma imagem final de uma cena, mas quando há manipulação de objectos num cenário ou o ajuste de um ponto de vista, é necessário um desempenho razoável para tornar a interactividade positiva. Nestes casos, podem ser desejáveis funcionalidades com fraco desempenho para a imagem final mas são indesejáveis durante a manipulação de um cenário.

Ortogonalidade
   Uma vez que é desejável a possibilidade de activar ou desactivar funcionalidades, é também importante que esta não tenha efeitos colaterais sobre outras funcionalidades. Se, por exemplo, é desejável que cada polígono possa ser desenhado com apenas uma cor em vez de uma interpolação de cores sob os seus lados, isto não deve afectar a forma como as texturas ou a iluminação são aplicadas. De forma similar, activar ou desactivar uma funcionalidade não deve conduzir a um estado inconsistente, no qual os resultados da renderização sejam indefinidos. Este tipo de independência de funcionalidades é necessária para permitir ao programador a sua fácil manipulação. Outro benefício da independência de funcionalidades é que estas podem ser combinadas de forma útil, gerando situações diferentes das idealizadas aquando da projecção da interface.

Completo
   Um API gráfico 3D a correr num sistema com um subsistema gráfico deve oferecer alguns meios para aceder a grande parte das funcionalidades desse subsistema. Se uma funcionalidade disponível não for oferecida, o programador vê-se obrigado a recorrer a um API diferente para obter as funcionalidades que faltam. Isto pode inviabilizar uma aplicação por causa da interacção entre duas interfaces.
   Da mesma forma, se a implementação de um API fornece certas funcionalidades numa plataforma de hardware, então estas devem estar presentes em qualquer plataforma, que ofereça o API. Caso esta regra seja quebrada, torna-se difícil usar um API num programa multi-plataforma sem saber quais as funcionalidades suportadas por cada plataforma. Em plataformas sem a aceleração apropriada, algumas funcionalidades podem ter um fraco desempenho mas, pelo menos, uma dada imagem deverá, eventualmente, aparecer.

Interoperabilidade
   Muitos ambientes de computação consistem em vários computadores ligados em rede. Num ambiente deste tipo, é extremamente útil ser capaz de enviar comandos gráficos de uma máquina, para serem executados noutra (este é um dos principais factores do sucesso dos sistemas de janelas). Esta interoperabilidade requer que o modelo de execução dos comandos do API seja do tipo cliente-servidor: o cliente endereça comandos e o servidor executa-os. (Este conceito requer simultaneamente que cliente e servidor partilhem a noção, de como os comandos da interface são codificados, para transmissão através da rede.) Claro que cliente e servidor podem estar na mesma máquina.
   Uma vez que os comandos da interface podem ser enviados através de uma rede, torna-se impraticável requerer grandes semelhanças entre cliente e servidor. Um cliente pode ter que esperar algum tempo por uma resposta a um pedido devido aos atrasos da rede. Assim pedidos simples ao servidor que não necessitam de reconhecimento podem ser guardados num buffer e enviados em grupos e executados pelo servidor, aumentando a eficiência da transmissão.

Extensibilidade
   Uma interface de gráficos 3D deve ser extensível, para poder incorporar novas funcionalidades de hardware ou novos algoritmos tornados populares no futuro. Embora garantir que esta meta seja alcançada possa ser difícil antes de decorrido um período de tempo considerável, alguns passos podem ser dados para atingi-la. A ortogonalidade de um API, é um elemento que ajuda a alcançar este objectivo. Outro é simular a forma como a interface pode ser afectada pela introdução de funcionalidades extra.

Aceitação
   Pode parecer que o desenvolvimento limpo e consistente de um API de gráficos 3D é um objectivo suficiente, em si mesmo. Contudo, a menos que os programadores decidam usar o API numa variedade de aplicações, o desenvolvimento deste não faz sentido. É portanto extremamente importante considerar os efeitos das decisões ao nível do design na aceitação por parte dos programadores.