This website · lailaarslan.github.io
The site you're reading is the case study.
I wanted a portfolio that looked like my work rather than a template — but I'm a designer, not a developer. So I used AI as the implementation layer and kept every design decision myself. This page documents how that actually worked: the loop, the division of labour, and where AI stopped being useful.
no template.
no developer.
no waiting.
Every portfolio tool asked me to design less.
Template builders give you speed and take away art direction. Hiring a developer gives you control and takes away iteration speed. Neither fit: I had a visual-design background I wanted the site to show, and case studies that needed unusual layouts — before/after spreads, journey maps, a finding-to-response ledger. Those don't survive a template.
Describe the intent, review the result, correct in words.
The workflow is closer to art-directing than to coding. I describe what a section needs to do and feel like, AI produces the implementation, and I judge it the way I'd judge any handoff — in the browser, at real sizes, on real content.
Decide before prompting
What is this section for, what should the eye hit first, what does it need to prove? Vague prompts produce generic layouts — the quality of the output tracks the quality of the design thinking behind it.
Describe intent, not implementation
"An editorial before/after spread where the messy artefact is visibly heavier than the resolved one" gets further than naming CSS properties. Intent leaves room for a better solution than the one I'd have specified.
Judge it in the browser, not in the code
Reading the diff tells me little. Looking at the rendered page at desktop and phone widths tells me everything — spacing rhythm, hierarchy, where a line breaks badly.
Correct in design language
"The heading competes with the artefact — pull it back a step" is a faster, more accurate instruction than a pixel value. This is the part that felt most like existing craft rather than a new skill.
Commit small, ship often
One section per commit, pushed live immediately. Working on the real site rather than a mockup meant every decision was tested against real content and real rendering from the start.
AI removed the execution barrier — not the judgement.
The honest split. Everything on the left was work I could not have done alone in this timeframe. Everything on the right is work AI could not do for me, because it depends on knowing what the site is for and who it's talking to.
Turning a described layout into working, responsive HTML and CSS.
Chose the layout, the hierarchy, and what each section had to communicate before a single line was written.
Producing three or four variations of a section faster than I could sketch one.
Variations are cheap; taste isn't. Picking the right one — and rejecting three good-looking wrong ones — stayed the designer's job.
Accessibility scaffolding, focus states, reduced-motion handling, responsive breakpoints.
AI only builds what you ask for. Knowing to ask for reduced-motion support and keyboard access came from design practice, not from the tool.
Deciding what each case study should prove, and which project leads.
The reasoning in every case study is mine — what the problem was, why the decision was made, and what I'd claim honestly about the outcome.
The gap between idea and artefact got very short.
This is the part that carries back into product work. When a concept can be a working, clickable thing in an afternoon instead of a sprint, you stop defending ideas in the abstract and start testing them.
Prototypes became testable, not just presentable
On the Keystone map-search study I used the same approach: concept to a hosted mobile prototype, then straight into 13 remote usability sessions. The prototype existed to be tested, not to be admired in a review.
More time on the part that matters
Less time on production, more on framing the problem, writing the research questions, and reading what users actually did. The thinking didn't get automated — it got more room.
Fluency with developers improved
Reviewing generated code taught me what's cheap to change and what's structural — which makes handoff conversations sharper, even when I'm not the one building.
The site shipped, and it's the one you're reading — design directed by me, built with AI, live and maintained rather than perpetually almost-ready.
It runs as a static site on GitHub Pages with no framework and no build step, which means I can keep changing it myself. Every case study on it was written, structured and art-directed by me; AI turned those decisions into working pages.
AI rewards clear thinking
The output is only as good as the brief. Being able to articulate what a section must achieve — an old design skill — turned out to be the whole game.
Review like a designer, not a coder
I can't audit every line, but I can judge the rendered result rigorously. Evaluating output against intent is the skill that keeps quality up.
Execution speed isn't the point
Fast production is only valuable if it buys more time for research, framing and iteration. Used otherwise, it just produces the wrong thing sooner.
AI doesn't replace the thinking. It gives me more time to focus on it.