mockup (pset 2)

2024-10-01

@carboxyl: this page is available on my blog if you're interested in following any of the hyperlinks: https://blog.npry.dev/class/smallmfg/mockup.

The goal of this problem set is to help converge upon functional requirements for your product. Build a quick mock-up of your product, and interview at least 2 users on a few aspects of its design, functions, or uses. Be very specific about what your aims are, and try to glean that information from the user without biasing them in any way. Do not pick too many aspects of the design to test on, as it may overwhelm the test subjects. Write up a short report indicating what questions you were trying to answer, whether those were answered, and what unexpected things you learned from your user study. Please include a picture of your mock-up in the report, and turn in a hard copy in class on the due date.

I 3d-printed a couple of models with different functionality for my mockup, an "A" variant and a "B" variant.

The A variant is larger (100x100mm) and has an integrated clamp for holding a part -- the idea behind this one is that the project is more of a fully-integrated workstation that carries the DUT. It would be relatively easy to add more battery capacity to this one, but the final product is likely to be more expensive.

A unit (clamp disassembled)

The B variant is smaller (50x50mm) and in my mind is conceptually an object that goes along with your project (rather than holding it), or embeds into it for testing.

B unit

Drawings here (attached to physical turnin)

cad (onshape)

user study

I asked a couple of electrical engineers in my group for feedback on the designs. The questions I was hoping to answer were:

user 1

This user gave a lot of unexpected feedback. The most important functionality for her to see was basic bus sanity-checking functionality and support for bringup, e.g. she wanted to see an i2c bus scan, indicator LEDs for the bus being high, and a hardware switch to enable i2c bus pull-ups. She expressed a strong preference for connectors other than DuPont because of their flakiness and eventual degredation.

She was overall neutral on the larger unit -- once I told her what the clamp was meant to do, she said that it didn't feel justified without additional functionality (e.g., bracketing the logistical difficulty of doing this, the clamp supplying power to the board). She mentioned that it would be nice to be able to configure pogo pins or similar to probe the board as it's held in place.

user 2

This user gave very different feedback from the first user. He preferred the larger unit with the clamp and found that a very compelling feature. He echoed my sentiment (unprimed) that it could really help him reduce clutter on his desk during bringup by keeping all the wires in one place. He said he would use the wireless functionality and that the battery should last about 4 hours -- he would be fine charging it during lunch, just as long as it lasted a full work session for him. He indicated that it was annoying that there are so many separate tools to perform EE work: workholding, analyzers, oscilloscopes, etc. and encouraged me to make the unit physically bigger and add more functionality to it. I asked if he would use an embedded breadboard or perfboard, and he said he might but it would also be fine to leave the top area unpopulated as a worksurface.

His feedback on the smaller unit was that he could make use of it best as a communication station attached to a host computer that could talk to his embedded projects, rather than as a bus sniffer at all -- he feels logic analyzers serve this need sufficiently and wasn't moved much by the wireless functionality in this domain. Rather, he wants something that helps him solve his problem of reinventing communications protocols. He imagined that this smaller node could help with this.