Comment by 10u152
2 years ago
Related, I work with industrial control systems. We’d call this “smoke and mirrors”. Sometimes the client would insist on seeing a small portion of a large project working well before it was ready. They’d misunderstand that 90% of the bulk of the work is not visible to the user but they’d want to see a finished state.
We’d set up a dummy HMI and have someone pressing buttons on it for the demo, and someone in the next room manually driving outputs and inputs to make it seem like it was working. Very common.
I, too, work with industrial control systems. If any of us did that sort of thing, we'd be fired instantly -- and rightfully so.
There would be no problem if you told the client that you were faking the back end behavior and if the client's motivation is that they wanted to see the workflow to make sure that there wasn't a misunderstanding on what you were supposed to be implementing, then a mocked backend would be perfectly fine for their purposes.
Absolutely true. The comment, however, very, very strongly implied that the client wasn't made aware that the demo was faked. If the client was made aware, then why would they have someone hiding in the next room to "make it seem like it was working"?
To me it sounds like a useful thing, for communicating your vision and getting early feedback on whether you are building the right thing. Like uh, a live action blueprint. Let's say the client is like "Email???? That's no good. It needs to be a text message". Now you have saved yourself the trouble of implementing email.
> To me it sounds like a useful thing
To me it sounds like lying...
Context matters a ton though. Are you presenting the demo as if the events are being automatically triggered (as in the OP) or are you presenting as this is your plan? Explicitly. If it is implicit, it's deceptive. If you explicitly do not say what parts are faked, it is lying. Of course in a magic show this is totally okay because you're going to the show with the explicit intention to be lied to, but I'm not convinced the same is true for business but I'm sure someone could make a compelling argument.
There have literally been people sued over this because they used it to get funding; the most extreme example, where they kept doing it well beyond demo purposes, is Theranos.
And yet, you’ll still have people here acting like it’s totally fine.
As you said, it’s one thing to demonstrate a prototype, a “this is how we intend for it to work.” It’s a whole other thing to present it as the real deal.
How about in the original iPhone keynote, when Steve says “this cable is just here for it to work on our projector” - if you follow closely, there was no phone demo’d that day with screen on and no cable. I’m sure the main board was still external.
1 reply →
Definitely a useful thing to do to validate UI/UX/fitness.
Relying on blackbox components first mocked then later swapped (or kept for testing) with the real implementation is also a thing, especially when dealing with hardware. It's a bit hard to put moisture sensors on CI!
That said...
I would have recommended at least being open about it being a mockup, but even when doing so I've had customers telling me "so why can't you release this tomorrow since it's basically done!? why is there still two months worth of work, you're trying to rip us off!!!"
It definitely is a thing, we literally teach this to CS students as part of the design process in the UX design course.
It’s called prototyping, in this case it would be a hi-fi prototype, and it lets you communicate ideas, test the implementation and try out alternatives before committing to your final product.
Lo-fi prototyping usually precedes it and is done on pen and paper, Figma, or similar very basic approaches.
Google (unsurprisingly) uses it and has instructional videos about it: https://youtu.be/lusOgox4xMI
I've done similar things by manually inserting and updating rows in the database etc to "demo" some process.
Like you say it can be useful as a way to uncover overall process or UX issues before all the internals are coded.
I'm quite open about what I'm doing though, as most of our clients are reasonable.
the phrase I've heard is "dog and pony show" lol
Or “Wizard of Oz” — as a standard HCI practice for understanding human experience
The industry term is “art of the possible”.