Na základě požadavků, které by měly být do řešení v dané iteraci zahrnuty, jsou následně identifikovány typy objektů, kterými by měl být systém tvořen a jejich vzájemné vztahy. Vývojář může do značné míry vycházet z definice byznys a návrhových tříd vytvářených při návrhu architektury, nicméně obvykle je nutné je podrobněji vymezit a rozšířit o třídy další, které při návrhu architektury nebyly brány v úvahu jako např. třídy uživatelského rozhraní (presentation classes) a třídy obsluhující systémové události (control classes).

Na základě požadavků, které by měly být do řešení v dané iteraci zahrnuty, jsou následně identifikovány typy objektů, kterými by měl být systém tvořen a jejich vzájemné vztahy. Vývojář může do značné míry vycházet z definice byznys a návrhových tříd vytvářených při návrhu architektury, nicméně obvykle je nutné je podrobněji vymezit a rozšířit o třídy další, které při návrhu architektury nebyly brány v úvahu jako např. třídy uživatelského rozhraní (presentation classes) a třídy obsluhující systémové události (control classes).

Za účelem ověření, zda byly opravdu definovány veškeré vazby mezi jednotlivými třídami, včetně metod, prostřednictvím kterých je jejich interakce prováděna, je vhodné krok po kroku projít jednotlivé případy užití a zkontrolovat, zda navrhované řešení podporuje opravdu veškerou požadovanou funkcionalitu.

Pokud se v návrhu vyskytují komplexní prvky, nebo prvky s komplikovanějším chováním, je vhodné je detailněji popsat. Za tímto účelem může být využit například stavový diagram jazyka UML 2, který umožňuje zachytit stavy jednotlivých objektů a přechodů mezi nimi.

V průběhu všech dílčích kroků návrhu je vhodné navrhované řešení zaznamenávat např. prostřednictvím diagramů jazyka UML, datových modelů či částí navrženého kódů a návrh konzultovat s ostatními členy týmu. Je tak zajištěno, že budou včas identifikovány jakékoliv změny architektury a požadavků, které návrh ovlivní, a zároveň je získávána rychlá zpětná vazba.