Hacker News Reader

Comment by meric | Hacker News Reader

We've been moving to high-fidelity prototypes from PSD-design, it's good.

The days before we moved to PSD-driven development, it was "We need a page with a list of X's, so the user can Y each. It should look sort of like the list of Z's on ABC.com. Build a prototype for next week"... one week of back and forth and a bunch of hacks later..."Ok, the prototype looks good, let's put this in production by Friday."

Bringing in a full time designer and bringing in PSD-driven development was very welcome relief. We still had a week and a Friday, and didn't need to allocate time for prototyping.

View on HN

Interactive first has the same problem as design first.

I believe both design, interaction and logic could be done agile.

Simplified: The use must login. So we need a screen with a login method. What fields are needed? What should happen on interaction with the form elements? How should the form elements look?

The whole team of graphic, interaction and logic designers work together with the client to make this happen.

We are moving away from high fidelity prototypes to low-fi whiteboard sketches and prototyping in the actual application.

Occasionally we do pixel perfect prototypes with clickable simulated logic and all but we can't maintain it all, and we try to use it only when something is logically complex to reason about without pictures...

It's about as fast to do in the real code with mocked services when you have the application already there.

It requires more collaboration but that can only be a good thing.

I agree going without prototypes or PSD can be a fast way to grow - that's how our company built it's initial MVPs and became profitable in the first place. The PSD's and pixel perfect prototypes come in handy when the non-engineering parts of the company are so intimate with customer's wants, they are very precise about the requirements (especially to fit in an existing market).

Hmm so, it looks to me precise prototypes are good for precise requirements, while vague requirements are better when engineering is also customer development, and customer requirements are not known precisely yet.

In our company we have 1.5 designers and 5 in engineering and we're good with maintaining the prototypes. The designers have to do other non-digital stuff like print media too...Maybe our web applications are mostly CRUD's with permissions so it's easy to maintain?

Aha.

We have 6 teams with full stack developers and testers, sharing a (too) small group of UX experts. Each group have a product owner focusing on a specific area, but there is a lot of overlap.

But the general idea is to avoid big upfront design and instead try and retry the design.

Reply on news.ycombinator.com