Hacker News Reader

Comment by kgermino | Hacker News Reader

> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done.

I take a different but similar approach when I run into situations where I want to get something small in front of a business user before it’s completely ready: I make sure it’s visibly broken in a way that doesn’t detract from my goal for the meeting.

For example: I have a registration form that I want to talk through. The state drop down will only have 3 entries, one validation error will always display, and on final submit you get a “failed” alert instead of a dummy page.

It lets me walk through the page and get whatever feedback I need, but it feels completely broken so non-technical users expect it to take more time to conplete.

View on HN

While I agree, the feedback I get from a session like that is useless:

"While you mentioned this during the demo, I noted: 1. Your state-drop down has only 3 entries. 2. There is a validation error 3. You get an error at the end.

We need you to fix this ASAP !!!"

Yup, that'll happen, and if you omit it entirely you can get comments going "I'm not seeing this field!".

Would it be better to show no progress at all until it's completely done? I know agile methodologies tell you to demo regularly, but I'm more and more under the impression that they are to provide progress feedback / reports to management.

I remember someone suggesting using deliberately crude and hand-drawn looking UI elements in the demo. That communicates to non-technical users that it's just a prototype.

Something like https://wiredjs.com/ might work, if you are building a web-ui.

Fabulous idea. I will definitely use this for future early-stage demos.

I did this, but by not fine tuning the CSS until the end. Just use black and white, leave off the border radius, and make it look "unfinished".

Honestly, that feels like a huge waste of your own time to game a broken system. And I'm guessing it is, but that it's a defensive move because the darker timeline is miserable.

Sucks it has to be this way so often.

If hes talking about JavaScript an alert dialog is a single line of code so I dont think its that bad. Also as long as frontend and backend have agreed on what certain objects structures will be hardcoding shouldnt be an issue.

I've done this on quite a few occasions as well. It isn't necessarily time wasted, as you evoke a positive view from the client (progress towards the solution) and often get valuable feedback.

The alternative is that they think you are done, adding more pressure, and requiring more wasted time later explaining the mis-aligned expectations.

What's broken are humans. For some psychological reason, a thing that looks unfinished gets much higher quality feedback than something that looks polished. There's no way around that flaw in people, so making prototypes look unfinished is something we have to do anyway!

> For some psychological reason, a thing that looks unfinished gets much higher quality feedback than something that looks polished.

Does this really imply “humans are broken”? We all have limited resources and I think this could just be a first order prioritization mechanism. Of course one has to be aware of the bias but that’s a different problem.

Perhaps because “unfinished” offers stakeholders the opportunity to make major contributions, whereas “finished” means it’s already too late to make changes now so anything they do say will just be ignored.

Yeah it’s all perception, but cultivating the right perception is vital to effective, productive communication.

It's an example of the Doorway Effect: brains are wired to work in modes related to context cues. Change the context, and you'll change the memories and trains-of-thought easily accessed.

Polished things have a context of "use", not "evaluate", because we use so many polished things every day, but very rarely have any need to evaluate them (mostly only when we're buying them, or when a repair person asks us to describe what's wrong with them.) Whereas unpolished things are mostly "for" evaluating; it's rare that people use unpolished things (outside of, say, disaster-relief infrastructure.)

Here's another way of thinking about this:

it's not a way of gaming the system, but a way of prompting better feedback. For instance, in a Design Thinking process prototypes are more useful when they look rough/unfinished. A more polished piece of work might result in people being afraid to break things.

I use both approaches in my work:

1) demo small, tested bits during show and tells and any meetings where the point is to demonstrate progress. 2) demo large, unfinished and barely stable pieces of work when ideating, trying to figure out the next steps

2) is hard and works only if: - we know what the unstable parts are (because we have tests, so we know the gaps) - we know the audience and how much context they have

Spot on! I like the “conplete”. I hope it was intentional.

Or even better: a Freudian slip!

I don't do that. When I demo something I need feedback on, I demo the best version I've got. If it still requires work, I say so. This seems to work quite well for me.

Reply on news.ycombinator.com