I'm a bit of a cutlery snob. Most high grade consumer brands are way too expensive. We finally found Salvinelli Grand Hotel, after dining at a small Italian restaurant in Amsterdam. I actually called them back the next day to find out which line they had. Salvinelli only sells b2b, as far as I can tell, per dozen an item. Their Grand Hotel line is a heavy 4mm. 2 dozen sets of 6 only set me back €480.
Being THE term is the holy grail for consumer brands. You can only get huge when your brand is the synonym for a whole concept or industry. Like ColaCola, Uber, Facebook, Tweet etc etc. For example Mark's explanation of Facebook [1] or the Photocopier sketch [2]
Indeed. We have simple process to create maximum support impact with minimal effort in documentation.
With every support request we ask ourselves: Why is this person contacting us? Is there a simple ui change or wording to prevent confusion. Basecamp coined the term "wordsmithing" for this endless process of fine tuning. [1]
Only after we are happy with the amount of support request a feature generates, we document it.
Doing it this way has a couple benefits. You kind of create a long term user test. You can't spoil the user with knowledge from documentation. There is no way you can give hits to the user to perform a the task. With every support request you can multi variant test your explanation.
What we've learned is that you can roll the how-to guides and tutorials into one. Once a users has learned how to use a service, they only need some inspiration on how to use it in different scenario's
Van der Meij, H Wrote a nice article [1] about minimalism in documentation referring to the first how-to guide (First_Minimal_Manual) [2] on how to use smalltalk for an IBM Displaywriter System (1980). This guide is all about just getting started, and if something goes totally wrong, you just reboot the machine.
People learn by doing. For new user, unfamiliar with your service, you have to reassure them that they can undo everything. This allows them to explore the system freely without any anxiety of doing something permanently wrong.
People prefer to be shown what todo instead of being told what to do. Ikea and Lego manuals for instance never tell you to put screw B1 into hole 7A in the right side of panel 14B Screenshots in your help center articles help a great deal with this. But these are hard to maintain, that is why we created Cliperado [3]
That is interesting - my experience is the opposite, that how-to guides and tutorials are the most-commonly confused types of documentation. My aim is to make the serve totally different needs:
* tutorials: I'm in charge (the teacher) and I know what the new learner needs to grasp and become comfortable with so that they gain sufficient basic confidence and skills. In the tutorials, the beginner doesn't even know what questions to ask or what language to us when asking questions
* how-to guides: the user is in charge; they are able to formulate the questions, and have the basic confidence and skills. What they need from me are the recipes.
As described, it's the difference between teaching a child to cook, and a book of recipes for somebody who already knows the basics of cooking and the kitchen but wants to know how to cook a particular thing.
If you get teaching a child to cook mixed up with a book of recipes everybody concerned will have a bad time. It matters most for the child, they will never want to learn how to cook with you again.
With https://cliperado.com we go a step further. It will keep your screenshots up to date for you, and notify you of any changes. We created it to keep our step by step screenshot guides updated with every deploy.
You can use it for testing as well. Cliperado runs headless chrome for the refreshes.
For Cliperado we run a full screenshot refresh before every deploy. We've caught various bugs that way. After the deploy, a full refresh and screenshot update for the site and docs takes maybe 5 minutes.
Both slack and email are awesome and horrible in their own way. The same goes for IM, WhatsApp, Intercom etc etc. Most productivity is actually lost by cross channel communication.
As mentioned in the article "... that company communicated almost entirely via Slack" So where do I digg up the rest? It might be in a voicemail of a colleague.
If slack would implement a push-IMAP api. I could at least drop one app :)
I don't see anything wrong with the majority of asynchornous communication methods. Mind you, I'm a fan of slack and a lot of people aren't. The issue though, I think, and the reason why slack is so widely used despite the fact that most users tend not to like it is because of the UI. It's friendly and easy, for surface level tasks, and that's far more important to people than the fact that it's synchronous (based off of my own experience, can't cite any stats so I'm not making a claim here). Email could very well work for this, and several apps have tried to "IM-ify" email, but none have really caught on. It's a UI and UX issue fundamentally, not a capability issue, once again according to my experience.
Cliperado | Senior Engineers | Amsterdam | FULL TIME , ONSITE, SALARY: €48k-€60k, cliperado.com - Senior backed engineer - Senior frontend engineer
Cliperado is looking for great engineers, who like to think about why and what they are building and iterate over the solution a couple of times. To make something that actually makes sense, both from a user and from a technical point.
Cliperado wants to make it as easy as possible for user to understand a service and creators to educate their users.
If you’ve ever created an online service, you know how much work it is to put screenshots in your documentation. You know it makes your service way easier to understand, reduces your churn and even increases signups. But it is just too much manual labor to keep the shots up to date.
We are creating a solution to fix this and it is coming along pretty nicely.
Our stack includes PHP, Python, VueJS, MySQL, Docker, Selenium, Browser Extensions, Bugs, Performance Issues and a sense of humor.
If you have any questions or you are interested - Please reach out to me arjen@cliperado.com
Cliperado is looking for great engineers, who also like to think about why and what they are building and iterate over the solution a couple of times to make something that actually makes sense, both from a user and from a technical point.
So the pitch goes something like this: (needs some work though)
If you’ve ever created an online service, you know how much work it is to put screenshots in your documentation. You know it makes your service way easier to understand, reduces your churn and even increases signups. But it is just too much manual labor to keep the shots up to date.
We are creating a solution to fix this and it is coming along pretty nicely.
Our stack includes PHP, Python, VueJS, MySQL, Docker, Selenium, Browser Extensions, Bugs, Performance Issues and a sense of humor.
If you have any questions or you are interested - Please reach out to me arjen@cliperado.com
