Fair enough that my initial comment wasn’t super constructive. I was making some assumptions, and I apologize. Let me start over. Please hear my words with a friendly, constructive voice! I love your products. I currently own two of your 7u cases and 15 of your modules, so I clearly wish you only the most success.
Now that it’s been stated, I understand what the intention was with the manual, which for clarity I will refer to as the “document” for the rest of my comments. However, I would call what you intended a tutorial, not a manual. Both are super valuable things to have, but they don’t mix well together. A manual gives a concise, extremely clear and easy to use reference about all aspects of a device’s functionality. A tutorial instructs a user on a particular use case, and when done well, also builds upon previous tutorials to reinforce user knowledge.
Another modern way to think about this is the “browse vs search” argument. Using a search engine, a user can rapidly find specific answers to specific questions. But search interfaces hide so much from us that is also valuable, which only comes from having the ability to “browse”. If one enters a public library and walks among the stacks of physical books, they will find things that would never emerge during a search. Both are valid, and both are very different.
As a tutorial, the document is OK. For improvements I would suggest the following:
Avoid Rote Repetition We have mountains of evidence over decades that proves this technique is rarely successful. Instead, create simple “early use” tutorials that provide basic working knowledge, step by step. Then in later, more advanced tutorials, assume the user knows some of those things, which gives them a hands-on opportunity to use and thereby reinforce that earlier knowledge, which they will be motivated to do because they have the newer more complex task/feature to explore and learn. This also builds user efficacy, because they feel confident in using older knowledge while simultaneously learning something new… this is crucial to keep users from just stopping at some point out of frustration or boredom, and then never returning to the material (or your future products!).
Use Case Presentation - I get it now that you never intended anyone to read the manual cover to cover. But the table of contents reflects a traditional manual format. Since you are doing tutorials instead, I would recommend changing the table of contents to reflect use cases, not features, since this is how you want users to approach it. “I want to learn a new thing”, or “I have a particular problem I want to solve” are great ways to approach thinking about this. So is extensive user research on how your users behave when in problem or learning spaces.
Functionality Presentation - Another approach to the tutorials is to focus these on the features themselves, rather than use cases. This is often necessary when a user simply won’t know enough to expose themselves to it, as no use case will emerge on it’s own. This allows you to package functionality documentation in one place, and then build upon it in multiple other tutorials. This solves the problem your document currently has, where out of 30+ pages, at least 15 repeat the same information about the five modes. There are some unique things to know peppered throughout, but the user has to ingest a large volume of redundant information to find it, as opposed to getting a quick overview somewhere that allows them to gain a quick mental model of the full range of features, even if they don’t currently possess mastery over them.) Side note - An extremely poor example of this is the Octatrack manual, which in multiple places refers to topics as if the user is familiar, many pages before that topic is actually introduced!)
Embrace Multiple Learning Modalities - You could also more widely embrace multiple learning modalities by doing tutorials in a format such as YouTube. This would allow people who center around learning styles of visual, kinesthetic, and auditory to all connect better. It would also allow users to more fully embrace their learning styles by watching alone in quiet areas, or watch multiple times, or with a group of friends for discussion, or whatever else they may most need to learn at their best. I think it’s safe to assume that anyone buying one of your modules will have a heavy auditory competent to their learning style, so presenting repetitive text-only content is already sub-optimal.
Consistency - Some of your document reads like a manual, other areas read like a tutorial. There is no clear distinction between the two, which led me to my initial conclusion and statement. I was honestly baffled when I would start reading nearly the same words again just one or two pages later. Perhaps you could create two distinct sections for the two different methods of presenting material.
To summarize, I would love to see both a proper, clean, concise “manual”, AND a set of supporting tutorials! But right now, I personally find the existing document to be a frustrating, redundant read. Your intentions were great, I just think you could go further with the design implementation of it and have a vastly superior result, on par with the excellent hardware you produce!
As for where these comments are coming from… I was a professional musician for many years, and now I write and record purely for the joy of it. For the last decade I have been teaching students in colleges and online in a variety of topics, and currently do so at one of the world’s premier institutions for design and game development. So I do have some experience in this. I don’t say that as if you should do what I’m suggesting, but please do give it some consideration because my views are not half baked opinions.
Thanks, and all the best to you!
