Launching and Closure: Procrastination, Creativity and Productivity
I have a big major problem going on — it’s not that I am procrastinating, but I find difficult to resolve the challenges going on with FastClip towards a launch for a business. I am trying to launch a functional online experience and in working on this I have the database, the organization of the backend infrastructure, the UI, UX, making sure there are situations that allows room for the use cases related to the user which may hopefully allow room for more learning, interviews, etc.
It’s a lot in my plate and of course the more I read it helps but at the same time I fear it is never launched because things becomes more clear. It’s a happiness and fear at the same time — it’s light and darkness.
To make things worse (or better, so I am here writing this in an attempt to get to the end with more light) this week I am reading a chapter of the book Originals, by Adam Grant; and I am now under the section that talks about *Why pioneers fails more in contrast with colonizers* and so he brought the subject of a certain role like the creative procrastinators.
Adam brought the aspect of procrastination to point out that original creative people tend to establish a certain “it’s never closed” situation. In fact a bit of disambiguation here is necessary: it’s not that these people don’t produce or don’t engage. In fact they seem to engage in the challenge but they don’t really finish the challenge too soon: like the example he pointed of the Mona Lisa that Da Vinci kept “open” and working on it for about 16 years.
Procrastination that Adam talks about relates also with timing — that is why the connection with pioneers (or rushers in his view) with the colonizers (the creative ones maintaining or sustaining the situation aiming the long term win.)
Back to the Challenge: The dilemma between Launching versus Editing
Friends and stakeholders, of course are by now mad. A side of me too. They even limit sometimes their feedback, biasing the note towards the point *you have to launch something*.
With that of course I engage in the focused mode, working on the important things, trying to narrow by “some launch” project — not matter exactly what but trying to have something meaningful and at the same time something that would allow the future, other problems to be taken.
But then when I engage, and produce, it seems that end up concretizing mistakes more precisely — that even costs more, like a detour — in a week later I had to rewrite something. This is really complex, it seems that a rush leads to some launch but comes with a cost. What I am really launching? launching an opportunity to rewrite? Launching and not really launching. So the point should not be about launching; also because not many will be able to see. With that it’s important to recollect major points of this project:
Organizing the basics
Action - avoid launching for launching
So action one seems to make sense — to avoid launching for the sake of launching.
Action — launching for engagement, for learning
Any launched effort, since it wont target the right answer; plus, because the situation seems to relate to a new kind of experience; and, because learning is key; should be aiming engagement in learning opportunities. So, we should close the projects that don’t have any kind of engagement.
Action — aiming constructiveness
Launched milestones needs to sum something to the business proposal or thesis: Being a) learnings b) new lights such as c) understanding of the market d) understanding trends e) understanding timing f) understanding a possible persona / customer profile g) engaging with researcher, experts, smart feedback h) engaging with potential smart investor, anything.
Delivery vs Open design discussions
In parallel, while coding, prototyping, and engaging in the system development, at this point a Web UI for watching lectures; it feels pretty important that this artifact should exist, so to be used to engage others in the discussion and the experience potential.
But being something new, with some new theories in it such as use cases with new opportunities in collaboration — for example it may be about the problem of fake news, the problem of polarization, or it may relate to journalism and transparency, or investigative news journalism; All these things are forces creating a great deal of confusion to a potential milestone of delivery.
Part of the problem here is that I may be engaged in a open design discussion which is making the delivery attempts to be incredibly more challenging.
When allowed the Dilemma is Open While Coding — Closure vs Uncertainty and Parallel Learnings
So then when trying to develop to close, when trying to be more precise in launching a functional prototype, I end up hitting (like visualizing) some real experiences, more clear use cases. When moving, when implementing it, I was able to feel the achievement of amazing cases, more clarity, plus with some discussions with peers and frequently hit redesign situations. (Most of these may be in my head in fact. )
The following list is an x-ray of this fuzzy complex way of coding and trying “to launch” :
- Widened experience — it seems that working in more than one use case, such as beyond the original simple view that slides are hierarchically children of videos, is helping. It made me aware of major problems with the strict view, such as the possibility that I was solving a personal use case only — a video + synchronous slides.
- Narrowing experience — On the other hand, once I prototyped and recorded videos with a variety of use cases, it seemed that the specific individual use cases became stronger. It also seemed that I reached a variety of more specific cases that could be better in fact presented to professionals such as professors, book/video authors, publishers — it would allow them to have different views of possible realities.
- Coding was learning at the same time — I was coding, checking UX cases, learning code and at the same time thinking in use cases. A complex situation that I can’t really say good or bad things. It feels that I end up taking a challenge and the approach was wrong, but after widening and narrowing more than one use case helped with a lot of clarity, such as to have a better sensation that I need multiple UXs here for engaging in real discussions.
The Need To Separate Design Experiments and Allow Failure/Learning In a More Scientific Approach Aiming Speed Later
From the above, not exactly blaming anything and recognizing it was confusing but useful it seems that is pretty important to:
Keeping multiple UX experiments is fine
An UI for annotating videos (advanced author), an UI for navigating cards of a single video (slides for a video), an UI for reaching out into a single citation of a video in the middle of an article (marcio’s mother case) and an UI for reaching out a video section with multiple slides within an article.
Experiments need to work and generate discussion learning
It’s quite important to avoid having 3–5 different UI that suck. Via allowing these multiple ones to exist, at the same time we should not allow to not exist one good one and real engaging discussions.
The level of engagement precision needs to be higher
When looking the following work, and when working on it, I had a feeling that was new and important. First, it was quite important to see that the emergence of A/B, something that before I feared, actually helped and allowed the brain to reason more quickly, and discussions to be more precise.
Second, I noticed that the experiments of having multiple demos ended-up being weak, or lazy, such as I end up filling data with “nonnono ono “ such as “lorem ipsum”. Right after doing that I had the realization that I needed to be more precise, that case A needed to have its own text based in the use case, the same to case B, etc.
The above section is the north to Marcio’s agenda the following week. The result may look like this:
- Make 3 example cases, one for portuguese, one for math, one in the field of psychology. Related to the A/B cases here https://medium.com/@mgalli_81316/fast-clip-design-ux-when-the-user-finds-a-synchronous-video-slide-section-suddenly-c8dfc5ee8a3a
