Before you code, write.


I speak from experience. Multiple times I’ve sat down to write a knowledge base article while basking in the warm glow of a post-development battle. I’d start with an introduction summarizing a feature’s usefulness, followed by a real-world example, followed by a 1–2–3 walkthrough. Sometimes the writing would be easy and fluid. Other times I’d get halfway through, my progress would slow, and I’d realize the unfortunate reality of my situation. (许多次我将编写knowledge base文章放在接近开发尾声时期. 有时候writing过程非常顺利, 但是有时候却中途卡壳)

Concepting application features in the abstract is typically a process involving PSDs, InVision prototypes, vanilla HTML markup, flowcharts, wireframes, or some combination of the above. All are incredibly useful when capturing how a feature might look and feel. But the real test comes when your target audience attempts to use it. (虽然一些工具可以capture一个feature看起来如何以及如何工作的, 但是这并不一定是用户使用时候的真实效果. real test最终是来自于用户的)

This discovery process is similar to writing taglines, advertising copy or elevator pitches. Your goal is to succinctly communicate with your audience a central message, call to action or idea in the most efficient manner possible. The relative success or failure or your communication isn’t simply a measure of verbosity, but rather how compact and clear you can compress your message into a form the end user can understand. (这个过程类似于writing taglines, 撰写广告文案, 或者是elevator pitches. 你的目标是准确地向用户传递一个消息, 告诉他们feature是什么以及如何工作的, 然后将这个feature转换成为一个有效的UI和实现)

comments powered by Disqus