I build financial software and medical practice/treatment management software.

70 screens isn't so bad, try building a commercial system with hundreds upon hundreds of screens and permutations.

There are a lot of comments already, some of which just seem to be flexing, but I'll add another opinion in anyway.

I think it depends on the goal.. A full product prototype might be useful in some circumstances, but also might be someone just asking for a full prototype because they haven't thought a whole lot about the goal. I'd do some discovery around what the goal of the prototype is, and then make a collective judgement call with your peers.

If it's for usability testing - maybe suggest a leaner approach where you build prototypes based on smaller tasks.

If it's for something like internal communication so that everyone understands how a new product will link together then it might be very much worth it. A whole team of people who all understand a common goal will work much more effectively.

As for how you're doing this - I guess that depends on a few factors as well, like what products you work well in. Personally I would do this all in Figma - because I already work in Figma, and the prototyping functionality is the same as InVision. If this is a prototype that required higher functionality like working dropdowns, or authentic data input and storage, then I would go to Axure - this also depends on timeframes as well.. If you are in a startup I'm guessing you'll have to opt for the quick approach - but if you're at an established corporate gig you might have a week or a few weeks to put something together.

So - is it madness? Depends entirely on your circumstances.

70 screens is fine. I'd suggest Axure 9 if you need to really act like a prototype instead of a bunch of linked screenshots.

Not that bad. I work with Healthcare products and some of our software has over 700 screens... Make sure you keep your files, symbols, and screens neatly organized!

If you have to do it, I suggest to look into UX Pin as a tool.

It has states and logic for prototypes, which means you might not have to use 70 screens or even more for various flows. Instead you can have multiple interactions on one screen that happen on component level.

How is the prototype gonna get used? Sounds like they don't know what they want to test with the prototype and just want everything. Maybe try suggesting a leaner approach. :)

It depends on the prototype. I've been building out more and more larger and larger prototypes where the PM would rather spend UX time than engineering time to validate an idea with users (which is valid). It is not as effective when you need to go that deep to validate mouseover behaviors on every screen where you don't have component states. I've had to do this in Sketch/InVision and it's not great.

A 70+ page fully interactive prototype is not standard for proper product development. It's overkill.

As Rhys Merritt has suggested, it's normal and cost effective to create interactive prototypes for specific parts of a larger product, especially when it's a new type of flow, or a transition between flows.

Anyone creating fully interactive prototypes - with no code - of a whole product is wasting money.

You must be new.

70+ page wireframes is standard for real software. Real software with complex workflows and deep functionality is hard to design and harder to maintain.

It does sound like there isn't a clear goal behind the request, I'd clarify that first. It only makes sense if half of the screens are dropdown, input, radio/checkbox and modal states.

Secondly, I'd definitely break it down into separate task flows.

Keep us updated on how it goes.

"It is a very complex site." -- This is why they want a prototype! It doesn't sound like an unreasonable task and 70 pages doesn't seem like a lot.

70 screens not much of a problem

I have made very complex prototypes. I would try Invision for linking them together. It is so good I have had upper management think I had already built the application.

Page count can increase quickly with variants. It really depends on the scope and direction of the project.

If they pay for it, why not?

The difficulty with multiple screens are the states involved, and the logic of multiple possible paths per button.

Proto.io (https://proto.io/) has component states you can utilize in prototyping. It's quite a good tool. Used it to mock up a one page checkout experience with multiple states per section. That may be of use to your challenge!

But to your point, I'm with you. Though, it really depends on the client (how much money is involved) and resources. If anything, take it up as a challenge :)

yup. just finished 140 page prototype about a month ago. massive project. Doing that many pages was getting a bit ridiculous in my opinion, but when the client wants it, and is paying you to provide it, you usually just go ahead and say '...uh...ok'.... :)

that said, I'm hoping to not have to do that again for a long while ;)

I've got another project brewing that's going to require a lot of prototyping, but I'm fairly confident that a) there's way less screens, and b) I'm working with a terrific senior software architect that will put the kibosh on that kind of thing.

That is a lot dude. UX Pin is a good alternative for doing this job.