Witam, aktualnie pisze pewna aplikacje i potrzebuje pomocy jak to dalej rozplanować.

Mam już schemat bazy danych:
3 tabele razem ze strukturami.
Mam zaplanowane co będę wyświatlał na konkretnej podstronie. Nawet już sobie rozpisałem formularz dodawania danych do bazy, jakie potrzebuje pola, walidacja itd.

I teraz pytanko, czy zajać się grafika na stronie czy może napisać sobie na kartce funkcje(co ma robić, jakie dane zwracać) które potrzebuję do obsługi aplikacji?
Czy może jeszcze coś innego? Nie chce usiaść i zaczać kodzić, bo dojdę to takiego momentu w którym powiem sobie "kurde, co teraz?". Chce mieć to wszystko rozplanowane.
Jak coś to używam Code Ignitera

Proponował bym najpierw rozpisać funkcjonalność. Podczas projektowania mogą wyjść jeszcze jakieś szczegóły, które będziesz mógł uwzględnić w projekcie graficznym i w bazie danych. Wiadomo, im więcej uda Ci się rozpisać tym lepiej. Pamiętaj, żeby od razu nie skupiać się na szczegółach, tylko na ogóle, bo sie pogubisz. Oczywiście jak wpadnie Ci coś do głowy, nad czym akurat nie pracujesz, dobrze jest to gdzieś zapisać na późniejszy użytek. Postępuj w myśl zasady od ogółu do szczegółu i nie powinno być problemów

Zacząłbym od narysowania sobie wszystkich przypadków użycia jakie mogą wystąpić. A później spróbował zrobić sobie kolejne powszechnie używane diagramy UML. Jeśli nie miałeś dotąd doczynienia z UML, a masz dużo czasu lub robisz ten projekt dla własnej satysfakcji, to polecam zapoznać się w Internecie UML'em. Pozwoli to zrobić Ci usnadaryzowaną dokumentację z której być może za kilka miesięcy jeszcze da się korzystać, czego nie zawsze można oczekiwać od luźnych notatek.

No może tak nie przesadzajmy na pewno nie wszystkich, bo tego nie jesteś w stanie przewidzieć... ale na pewno diagram UML to bardzo dobry pomysł

No tak, w wymaganiach projektowych pewne jest jedynie to, że się zmienią

Jak nie wiesz o czym mówisz to się lepiej nie wypowiadaj

Brałem udział w opracowywaniu wymagań do kilku większych projektów informatycznych i zwykle bywało tak, że wymagania zmieniały się z czasem. Klient często ma nieodpartą pokusę dorzucenia swoich dwóch groszy w najmniej spodziewanym momencie. Dlatego zarządzanie wymaganiami to proces ciągły, w większych projektach wymaga systematycznego podejścia do pozyskiwania, dokumentowania, śledzenia zmian w wymaganiach. Cały proces zarządzania wymaganiami pochłania czasem sporo czasu, ale dzięki można uniknąć sytuacji w której budzimy się z ręką w nocniku, bo nikt już nie wie po co i dla czego robimy system, kto i kiedy zgłosił nowe wymaganie i czy jest ono jeszcze aktualne czy nie.

Trudno o coś mądrzejszego niż napisał Lion powyżej, tylko że to się ma do pytania jak piernik do wiatraka.
Po jaką cholerę mieszać UML do trzech tabelek, to ja nie wiem. :-)

A odpowiadając na pytanie: Im więcej jesteś w stanie zaprojektować "na kartce", tym sprawniej ,pójdzie "kodzenie".
Przy czym im lepiej znamy daną technologię, specyfikę aplikacji im większe mamy doświadczenie tym dalej możemy zajść projektując. Jeśli to nasze początki, to pozostaje rozpoznanie przez atak, czyli "kodzenie". Próby większego projektowania zakończa się frustracją. Jak to zwykle bywa z rozpoznaniem przez atak, należy się nastawiać na czekających nas kilka przegrupować. Np. pisania od nowa fragmentów aplikacji bądź jej całości.

Jeśli chodzi o bazę danych, to ja wolę sobie ją zaprojektować w programie - w razie czego klikam dwa razy w tabelkę i usuwam/dodaję kolumny, a nie bazgrolę po kartce (choć kartki także lubię!). ; )

A koledze polecam wykonanie uproszczonych diagramów UML klas jego aplikacji.

Usiądź sobie wygodnie, weź kartę papieru i wypisz funkcjonalności serwisu, np:
- logowanie,
- administracja,
- itd...

Następnie zaprojektuj dla każdej funkcjonalności klasy i metody, w najprostszy sposób, np.

[PHP] pobierz, plaintext 
Klasa Konto
utworzKonto() - tworzy konto uzytkownia
usunKonto() - usuwa konto uzytkownika
zmienHaslo() - zmienia haslo uzytkownika
[PHP] pobierz, plaintext 

nie bój się także pisać w pseudokodzie! Przykład:

[PHP] pobierz, plaintext 
usunKonto($userID)
//pobierz id użytkownika
// jesli id istnieje w bazie danych
    // usun konto
// jesli id nie istnieje
    // wyswietl info
[PHP] pobierz, plaintext 

PHP się nie obrazi, jeśli rozpiszesz sobie metody w pseudkodzie jako komentarze, a później zaczniesz pisać prawdziwy kod.

Temat który powinien Cię zainteresować to: Object Oriented Design.

Projektuj, baw się przy tym, gdy wszytko będzie gotowe, wtedy usiądziesz i będziesz jechał z kodem jak po maśle. ; )