Note: This post was drafte on 5/27/2021 and finalized today.
Last week I got a lot done. This week has not been as productive. Let’s review what’s been going on. I’m not clear on my process and the steps are getting jumbled. I’m going to discuss my development process.
My Development Process
Two common design /development processes are:
• Design, Build, Test, Learn
• Emphathize, Define, Ideate, Prototype, Test
My process is similar but I need to use slightly different language to make sure I am clear on the boundaries of the work and the primary motivations.
- Test + Learn
- Design tests on paper
- Build prototype in Final Cut
I’ve put “test + learn” first. Obviously you need something to test so this can’t be first. But I don’t care as much about that fact as I do about making the idea of Testing and Learning primary. These three steps are repeated in a cycle so I think the trade-off of logic for attention is worth it.
1. Test + Learn
I combine Test and Learn because much of the testing and the learning happen in parallel. Obviously there is reflection on the tests afterward, but remembering that the tests are for LEARNING helps me stay focused on what I’m trying to learn. Without that top-line reminder I can get carried away with making things enjoyable for the testers. For example, if I can see people are having fun and the test script says “stop now and ask this”, I know I’m going to be a buzzkill for the testers. Remembering that the primary focus is testing and learning is more important than making sure they have fun. (As much as that kills me to say…)
2. Design Tests On Paper
For “Design” I added the word “Tests” to make sure I design for testing, not for some final product/narrative. My aim is to ask specific questions of the testers, so I design specific and discrete things to test.
I added the “on paper” part to design to keep me from getting into the tools. Mixing design and build is a time waster. I can “build” them on paper and save a lot of time.
3. Build Prototype In Final Cut
Again I use the word Tests here so that I don’t start adding in things that don’t serve the purpose: TESTING something specific. Examples of getting off track include: finding the “perfect” tone or adding cool visuals or fixing little blips or mis-alignments. Unless I have a test for it, I don’t build it. Too often have I polished the look of something that just got thrown in the wastebasket because it was flawed at a deeper level.
Making The Best Use Of Time
Each stage I have been having issues making best use of time. Here’s the problems and proposed solutions. Some of these problems and solutions might seem obvious, but there’s a power in acknowledging them and bringing them into the light and I can use that power to give me the focus and energy to implement the (usually obvious) solutions.
Keep an eye on the time
Problem: I’ve been going past the time I told testers they would be there.
Solution: Set a timer. Don’t talk so much. Read a book on how to run tests like this (since I haven’t done these before).
Use the time wisely during the designing of the tests
Problem: Work time often feels like languishing because the possibilities are infinite and feel untackleable.
Solution: Timebox it. Accept that there are infinite ideas I could have. Also do not start building things.
Use the time wisely during the building of the tests
Problem: I get hung up on one tricky item that is hard to build. Or I go into too much detail.
Solution: Estimate the time needed to build each part and sum the times (instead of a ballpark guess). Only allow that much time per item.
Use the time wisely – all stages
Problem: Keep running out of time.
Solution: Pomodoro my time. I was doing this when I was making great strides last week. I think it will help all the areas if I can keep this practice going. Also: Find a book on how to run the sort of testing that I want to run. I want to improve how I set up tests, prepare and run the testing sessions, and also talking to testers to get the best out of them.