Member Avatar for YOLO87

Hi guys, I can really use some advice about becoming a web designer. At the moment I'm currently sharpening my skills.

What I would like to know is how a typical Web Designer works over a day and a project.

I'm assuming after you received the initial design, during the development stage:

  1. You visualise the initial design, by creating the html frame, is this hand coded or done in WYSIWYG editor?
  2. Then, create/optimise graphics in Photoshop.
  3. Layout the objects with CSS, again, is it hand coded or done by WYSIWYG editor?
  4. Then code the front end functionality through JS.
  5. Design and code the database through MySQl.
  6. Add backend functionality.

Any advice would be grateful, best practices, time management - basically, how likely its done in the real world. Any books and links would also be cool.

  • 3 Contributors
  • 2 Replies
  • 237 Views
  • 3 Days Discussion Span
  • Latest Post Latest Post by EvolutionFallen

Dani AI

Generated

In response to ’s question: modern web design is usually iterative rather than strictly linear. A practical pattern that reduces rework is: clarify goals and content, model the data and content types, prototype (wireframes or low-fidelity HTML), create a visual system (style guide/components), implement componentized front‑end, integrate with backend/APIs, then test/optimize and deploy. Individual days alternate focused coding blocks, reviews, and short syncs rather than a single “slice everything in order.”

Project-level deliverables that help teams move fast: a one-page brief, content inventory, annotated wireframes, interactive prototype, a component library or pattern sheet, and an accessibility checklist. Rough time split (varies by scope): discovery 10–15%, prototyping/design 20–30%, front-end + integration 35–45%, QA/polish 10–15%, deploy/docs 5–10%. These make estimates and handoffs cleaner whether working solo or with a team.

Practical daily habits and tech practices that pay off: use version control and small pull requests, time‑block 2–3 hour deep work windows, run CI/staging, and do regular code reviews. Build components with semantic HTML, mobile‑first CSS, and modular JS; keep a living style guide. Prioritize accessibility, performance (image optimization, lazy loading, minimal critical CSS), and cross‑browser checks early. Quick troubleshooting tip: isolate a failing layout into a minimal HTML file to rule out cascade and inheritance problems before chasing framework issues.

Picking up skills: ship small projects, clone real UIs, maintain a public portfolio, and contribute to tiny open‑source tasks. As noted, IDEs can scaffold boilerplate; and as hinted, platform vs custom choices matter — the key differentiators are clear requirements, good component thinking, and reliable handoff artifacts.

Recommended Answers

All 2 Replies

Member Avatar for slavica.k

Webmatrix and visual studio will do basick html structure for you, (like head and body)but css you have to write yourself.

Member Avatar for EvolutionFallen

Good topic. I haven't worked on too many big "from scratch" projects so I'm looking forward to some interesting responses here.
For me, the first item is figuring out what the project is about, and if there's a cost-effective platform out there that I can use as a framework. This way I don't have to reinvent the wheel; oftentimes it's easy for the client to learn to use, and they're happy 'cause they don't have to pay me for a custom CMS. WordPress has often been my weapon of choice. I'm also trying to learn CakePHP.
If the project DOES have to be from scratch, I'd actually say that the database is one of the first things I'll work on. You need to know what kind of information you want to store and relay before you can decide how you want to present it. Plus I think this helps because while you're already building the DB you can insert dummy content for testing later on. If the client already has the schema figured out and has provided you with a site design based on it, awesome.

Once I have the design I prefer to break it down into its HTML structure. I usually do this by hand-coding. This way I'm very familiar with the elements I may need to reference in CSS and JS. Then yes, slice and dice in PS and start figuring out your CSS. Again, I prefer hand-coding.

For the rest I'd say you're pretty spot on with what I do.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.