How to write an article using UX and GTD
Immediately make a reservation: this is just an article on how to write an article. From which side any cuts will be understood a little later.
Many (me so accurately) periodically have a desire to organize and coherently express their scattered thoughts about some soft, project ideas, improvements in the workflow, and a lot more. However, not all desires turn into finished articles or presentations. So what's the problem?
It happens like this: sort of figured out the topic, and there is no problem with the formulation of thoughts, and there are plenty of thoughts. You make an approximate plan, you make a list of topics you want to discuss, you dig in the Internet, you write a dozen paragraphs of text. In the process of ripening new ideas - add them to the plan. Tomorrow you write a few more paragraphs, expand and clarify the plan and understand that this is starting to resemble a small book. 2-3 such iterations and enthusiasm subsides somewhat, leaving behind a bunch of references found, a dozen or two paragraphs covering a third of the planned topics and a feeling of incomplete work.
')
Of course, if you have already invited your co-workers, superiors, or, especially, clients for your tomorrow's presentation, then you will end up as pretty. But if you write for the soul, thinking: “if it works out well, I’ll post it on the blog, if it doesn’t work out, it’s not fatal,” then the risk that it “won’t work out” is much more.
As a lyrical digression, I will say that lately I have been especially interested in the design of user interaction with “ UX ” and bringing matters to the end of “ GTD ”. Both that and another is a cool mix of principles, ideas, methodology and its philosophy.
That's what happened after digesting this problem from the point of view of UX and GTD.
Does this recipe remind you anything? If you take a closer look, this is practically a standard GTD scenario: make a list of necessary tasks, break too large tasks into subtasks, prioritize by urgency / importance, and complete the most priority tasks. Look at what happened, re-prioritize the remaining cases, perhaps refuse or postpone the low-priority ones and proceed to the next case in the first place in the list.
Where did the UX come from? One of the design principles “focus on the specific goal of the user” worked. As a starting point, there was a “tool” - a rather abstract approach of GTD requiring some experience to be used effectively. Having set a goal to make an article, and thus setting a certain context, the abstract advice was overgrown with specifics and began to resemble a guide to action much more. In addition, it is understood that the main goal is not to write an article, namely to publish it. This allowed for better prioritization.
The influence of the principles of agile development is also well seen here: the resulting recipe “supports” iterative work on the article, puts priority on the timing of the final result, even to the detriment of the volume / functionality and helps to decide what to include in the “current release” and what to postpone on the second version / part.
Actually, in addition to the desire to share the recipe for writing articles and presentations that worked for me, there was also Goal # 2 - to show that the technology of organizing work on programs works in the application to “non-software” things.
You judge how it was possible.
Many (me so accurately) periodically have a desire to organize and coherently express their scattered thoughts about some soft, project ideas, improvements in the workflow, and a lot more. However, not all desires turn into finished articles or presentations. So what's the problem?
It happens like this: sort of figured out the topic, and there is no problem with the formulation of thoughts, and there are plenty of thoughts. You make an approximate plan, you make a list of topics you want to discuss, you dig in the Internet, you write a dozen paragraphs of text. In the process of ripening new ideas - add them to the plan. Tomorrow you write a few more paragraphs, expand and clarify the plan and understand that this is starting to resemble a small book. 2-3 such iterations and enthusiasm subsides somewhat, leaving behind a bunch of references found, a dozen or two paragraphs covering a third of the planned topics and a feeling of incomplete work.
')
Of course, if you have already invited your co-workers, superiors, or, especially, clients for your tomorrow's presentation, then you will end up as pretty. But if you write for the soul, thinking: “if it works out well, I’ll post it on the blog, if it doesn’t work out, it’s not fatal,” then the risk that it “won’t work out” is much more.
As a lyrical digression, I will say that lately I have been especially interested in the design of user interaction with “ UX ” and bringing matters to the end of “ GTD ”. Both that and another is a cool mix of principles, ideas, methodology and its philosophy.
That's what happened after digesting this problem from the point of view of UX and GTD.
The recipe for flexible writing articles
- Planning: general plans do not work.
- Break the future article into specific points and separate thoughts with an eye to 1-3 paragraphs for each.
- Rank the items, select the 3-7 most important and interesting ones in the “main” list. This will be the “core” of the article that you write today.
- The rest of the list, "for the future."
- Writing: Start simple.
- Briefly and easily formulate thoughts from the “main” list.
- Do not pursue perfection. First make the core of the article. Distracted by bringing the wording to the ideal can be when the whole article before your eyes.
- If a thought grows, for example, it requires clarification, see whether it is possible to postpone the explanation for later or without it the article will lose its meaning. In the second case, there is no getting around - expand the topic, but move something from the end of the “main” to the “for the future” list.
- Do not let an article swell. If the topic pulls all new ideas, thoughts and explanations - select it in a separate article.
- What's next?
- And actually everything. Topics from the main list are disclosed, the kernel is ready.
Even if by this time the fuse passed or other things distracted you, then the article is already there - you tried for a reason. But if you, like most good programmers, periodically itch for optimization, they can be refilled.
- And actually everything. Topics from the main list are disclosed, the kernel is ready.
- Improvement
- Look at the sequence of sentences and the order of the paragraphs. Is the main idea of ​​the article easy to follow? Is it not necessary to clarify certain points?
- Prefer simple language. If you used the word “infinitesimal” (Stop! Read the paragraph to the end), then your reader may need to digress to find its meaning. Escape with the risk of getting lost on the Internet and forget about your article. (You can google “infinitesimal” if you want, but there is nothing interesting there, honestly).
- Avoid complex sentences and large paragraphs. Break up or simplify long sentences.
- Check out the writing style
- on evenness: a sharp transition from a trustful style to an academically dry one can easily confuse the reader.
- to saturation: a lot of water and extraneous reasoning are not well combined with the frantic rhythm of our days.
- on liveliness: imagery and humor will not harm even the technical text. The main thing - do not overdo it.
- Test the article on friends. If someone fell asleep in the process of reading - this is an alarming sign.
- These recommendations, of course, are not a complete recipe for success, but they will keep the article in good shape. If you like the article yourself well, or you notice that the hour planned for polishing has long passed and it dawns outside - it's time to publish. Your real goal is not to write an article, but to share it with readers.
- Continuation
- What if there is still a lot of material and enthusiasm? Look at the reaction of readers, select the most important and interesting thoughts from the list “for the future” to “main” and proceed to the next iteration - write the second part.
- Remember that plans and ideas can change along with changing your interests and assessing the article by the audience.
- ^ Z
Back to GTD and UX
Does this recipe remind you anything? If you take a closer look, this is practically a standard GTD scenario: make a list of necessary tasks, break too large tasks into subtasks, prioritize by urgency / importance, and complete the most priority tasks. Look at what happened, re-prioritize the remaining cases, perhaps refuse or postpone the low-priority ones and proceed to the next case in the first place in the list.
Where did the UX come from? One of the design principles “focus on the specific goal of the user” worked. As a starting point, there was a “tool” - a rather abstract approach of GTD requiring some experience to be used effectively. Having set a goal to make an article, and thus setting a certain context, the abstract advice was overgrown with specifics and began to resemble a guide to action much more. In addition, it is understood that the main goal is not to write an article, namely to publish it. This allowed for better prioritization.
- Intermediate Objective # 1: Formulate the main points and write the finished text. We try to achieve the goal in the shortest possible time, for which we restrict, and if necessary, we cut down the volume of the article.
- Intermediate goal # 2: achieve good quality. This goal is auxiliary - it does not affect whether you get the result or not, but it determines how much you yourself will like your article. Focus on it when the first goal has already been achieved and spend the remaining time and enthusiasm on it.
- The ultimate goal: publish an article or hold a presentation.
The influence of the principles of agile development is also well seen here: the resulting recipe “supports” iterative work on the article, puts priority on the timing of the final result, even to the detriment of the volume / functionality and helps to decide what to include in the “current release” and what to postpone on the second version / part.
Actually, in addition to the desire to share the recipe for writing articles and presentations that worked for me, there was also Goal # 2 - to show that the technology of organizing work on programs works in the application to “non-software” things.
You judge how it was possible.
Source: https://habr.com/ru/post/138979/
All Articles