I spent a decade of my career writing manuals as part of my job. First in Professional Audio and Lighting, where I was writing for professional installers, then in HVAC where I was writing for the general public, who might not even be familiar with the acronym "LED" ("indicator" is the term to use!) I use to imagine that I was writing instructions for my mother to follow - she's almost 90.
We still managed to have a customer who assembled an oil-filled radiator the wrong way up, and another would couldn't see that the mains plug was packed with a protective cover on it, and couldn't get it to go in the socket.
This may be a bit off-topic, but an ability to write manuals is essential for anyone embarking on a career in a small company, or could even be a career in itself.

I wouldn’t give humans to much credit, sometimes even if shown or verbally directed to perform some action, some of these creatures will ultimately eat the paper you wrote it on. Seemingly with that said, never under estimate the stupidity of people. Ignorance is acceptable but sheer dumb is always the choice for these walking examples of darwinism. lol

I don’t mean to be cruel, but some of the things people do while I’m directing them over the phone, leaves me dumbfounded.

kv

 

It is at least tangentially related to the advice in my original post. The problem that frequently occurs in such cases is a person without enough knowledge to know what is wrong assumes they have enough knowledge to pare down the system they are working on to the parts relevant to solving the problem. So often, it turns out they have removed essential things and created an imaginary version that can’t be used to model the problem at all because it lies elsewhere.

So, a case of unwarranted assumptions, often based on the very ignorance that has created their problem in the first place.

Learning to model something in your mind, over and over deconstructing then reconstructing is possibly one of the best skills I have known while working in the service and manufacturing industry. I enjoy creative activities, to an observer quietly modeling things in my mind, will sometimes breakdown limitations in my design, not often seen in the real world. My wife knows I’m not listening to her, learning to grab me by the face to bring me back from the space between my ears. Design objectives, creative thought will win out long before it hits a breadboard.


kv

 

So why did this thread pop up on "new posts" after being dormant for 8 months?

 

It probably got spammed and the offending message was deleted by our ever vigilant moderators.

 

Re: Writing manuals

A common question I get asked: When you need to design and create a product, where do you begin?

My answer has always been: Write the User Manual.

 

Re: Writing manuals

A common question I get asked: When you need to design and create a product, where do you begin?

My answer has always been: Write the User Manual.

There was an author in a French magazine (Radio Plans Loisirs or Electronique Pratique) that always started with a list of the functional details: Cahier des charges.

 

Re: Writing manuals

A common question I get asked: When you need to design and create a product, where do you begin?

My answer has always been: Write the User Manual.

This is one way to approach Use Case Methodology, and it is very powerful. It changes the focus from creating something the user has to work for, with arbitrary names and oddball procedures, to something that works for the user with familiar terminology and procedures they already use, made simpler.

For many products, if someone had actually written the user manual first and that's what was intended, you'd say the designers were completely inept.

 

When the designer/engineer writes the User Manual they see it from the designer's perspective after the fact.
When you write the User Manual first you see it from the perspective of the user, what the user wants and how the user expects to interact with the device.

It also lays out the design specifications and the user interface which the engineer is expected to fulfill.

 

When the designer/engineer writes the User Manual they see it from the designer's perspective after the fact.
When you write the User Manual first you see it from the perspective of the user, what the user wants and how the user expects to interact with the device.

It also lays out the design specifications and the user interface which the engineer is expected to fulfill.

That's the nature of Use Case Methodology. It focuses on gather requirements from a UX perspective, using language familiar to the user rather than coining terms convenient to the programmer. This naming part is not just cosmetic, it drives the functionality by naming the working parts according to what they are.

The critical bit to doing it right is for the expert in automating tasks not to reproduce the old system and just make it automatic but to refine and optimize the process at the same time as sticking to the idea that the computer is meant to work for the user, not the other way around.

If users immediately invent workarounds when using the system, product, etc. it's time to reiterate the design.

 

At two companies I took groups of engineers out to see the products being used and to talk with those who use the products. The first time I did that I felt shocked that the way our product was being used had nothing to do with how clever my circuits were, and I think the others learned new things as well. Most customers don't understand what goes on behind the blinking lights and don't really care. Customer visits can be a much more revealing experience than merely asking the marketing product manager what they want.

 

I am glad to see this thread reawakened. It seems that lately we have had several firist-time thread starters poorly describe what they need and maybe more importantly why they need it. Most of them read the "before you post" notice and as noted earlier in this thread many of the people who end up conducting a game of 20 questions have not even been registered here for more than a day, and will not directly benefit from this thread.

It seems that the best way to improve things if for us to get better at getting the essential details up front before many replies get generated by people who are anxious to lend a had but do so based on assumptions about what the TS needs.

I hope to that end the regular contributors here put a little thought into how to extract the information needed with only a few posts. (That's not asking much, is it?

 

Lately? You mean, they haven't always done that?

 

I hope to that end the regular contributors here put a little thought into how to extract the information needed with only a few posts. (That's not asking much, is it?

i agree. This whole thread speaks to the wrong audience.

 

I like reading what people tried and failed - it helps me determine their level of electronic understanding. More info is better (until it's not).