This raises a question about the order of events in design. Design is a path-dependent process. That means the early moves constrain the later moves. Think about the cycle. On the very first iteration the design possibilities are wide open. The designer defines some screens and workflows and then the programmer builds those. On the next iteration, it's not wide open anymore. The new design has to fit into the existing design, and the new code needs to fit into the existing code. Old code can be changed, but you don't want to scrap everything. There is a pressure to keep moving with what is already there.

Our early design decisions are like bets whose outcome we will have to live with iteration after iteration. Since that's the case, there is a strong incentive to be sure about our early bets. In other words, we want to reduce uncertainty on the first iterations. 

Uncertainty and scope are the same thing. The more scope, the more uncertainty and vice versa. So a good strategy is to reduce your scope on the first iteration so your design/build cycle is centered on a very well understood problem. Build one little feature and nail it. Then build the next one, so your path-dependent process is always moving forward from a state you are proud of.

The alternative is to make many decisions at once, with higher uncertainty, and all those so-so decisions are multiplying as they constraint future decisions. You can never really catch up.

Every feature can be better. It doesn't have to be perfect the first time. But each element should be solid and well thought-out before you move on to the next.

Should I focus on getting a good UX or getting something quick out of the door?

When Rebekah Cox first described the product design process at Quora, one of the biggest surprises was the absence of Photoshop. She said that every part of Quora.com was designed in code from Day 1. I asked a few incredulous questions, nodded politely, and figured that once I started work I would surely continue my love affair with the Creative Suite.

6 months later, I'm a convert. Almost every feature I've worked on at Quora has been designed exclusively in code, from concept to iteration to launch. As my copy of Photoshop accumulates dust, I've come to see the myriad benefits of this system:

Consistency and Re-usability
If a design can be effectively realized using existing site styles and interactions, it probably should be. The benefits range from a consistent user experience to more maintainable code. When I prototyped in Photoshop, especially without a good library of site assets, it was all too easy to fudge this rule: Colors, paddings and margins were similar, but not identical, to existing ones; interactions would differ slightly, a discrepancy that seemed acceptable in the vacuum of Photoshop but felt off when integrated into the full site experience. Prototyping in live code, and designing with an asset library of real, pre-existing components, enforces the design principle of consistency.

Try The Simplest Design First
A corollary to easy re-usability is the incentive to try the simplest solution first. If I can use existing interactions in a new design, it's almost guaranteed that I will, due to the sheer ease of doing so. It's only after seeing these simple solutions come up short that I consider more disruptive approaches. As with consistency, the principles of what we consider good design are reinforced through the tools used to create those designs.

Code Structure Begets Design Structure
A good site will have a design scaffold, the basic architecture of each page upon which new components are hung. With any luck this scaffold is codified, both in CSS and server-side view code. Prototyping within this structure guarantees that new designs conform to the world they'll eventually be living in. Gone are the temptations to widen a Photoshop layer by 10px, even though it breaks the grid. Designing in and with well-structured code ensures that every part of the site is aware of its surroundings from its first moment of life.

Understand Interaction Details
There are countless details of a successful design that only become apparent after it's fully interactive: How responsive is it? How does a button feel when pressed? How fluid are the animations? The best Photoshop design in the world can't prototype the details that make or break a design. The faster I can answer these questions, the faster I know if a design is working.

Prototype is Halfway to Completion
At Quora, we write the view code for our designs, while the backend is written by the stellar engineers. A thoughtfully-architected prototype can become the foundation for the eventual production code. Though the process involves multiple re-writes, re-factors, additions and deletions, the re-usability of that code gives a project momentum that moves from initial exploration to launch.

In fairness to my old flame, Photoshop has tremendous benefits in any design process, even ours: working with our image resources, prototyping interactions on other platforms, work with color palettes, and more. But for the day-to-day work of iterating on new website features, I'm now happy to stick to my browser and text editor.

Post on Quora