When creating a digital product, it is easy to feel like the goal is to get everything right on the first try. When I started building my digital reading journal in Notion, I was mainly focused on making sure everything actually worked. I wanted users to be able to track their books, organize their TBR, record ratings and reviews, and keep everything in one place. Once I had those features working, it felt like I had made a lot of progress. However, this week taught me that having a product that works does not necessarily mean that it is finished.

One of the biggest parts of product development is iteration. Instead of creating one version of a product and immediately considering it complete, iteration involves creating different versions, identifying what works and what does not, and making changes along the way. Digital.gov describes iteration as creating a series of design versions that allow designers to recognize both the advantages and drawbacks of their ideas.

This became a major part of my process while continuing to develop my digital reading journal. Rather than adding as many new features as possible, I started looking more closely at what I had already created and thinking about how I could make it better.

Going From Functional to Visual

One of the first things I noticed was that my journal was functional, but it did not necessarily feel like a reading journal yet. My Currently Reading and TBR sections were originally displayed as basic tables. They worked exactly how I wanted them to, since books automatically appeared based on their reading status, but visually they were pretty plain.

This week, I changed those sections into gallery views and added book covers. It was a relatively small change, but it made a huge difference in how the journal felt. Instead of looking like a spreadsheet of information, it started to look more like something I would actually want to use as a reader.

I also created a Cover property in my main book database after realizing that using Notion’s page covers caused the images to crop awkwardly in the gallery view. This was something I never would have realized when I originally planned the product. I had to actually build it, see the problem, and find another solution.

This is one of the reasons testing throughout development is so important. Digital.gov explains that an early design is only a starting point and that testing can reveal moments where users hesitate, become confused, or struggle with part of a design. In my case, even testing the product myself revealed small design problems that I could improve before considering the journal finished.

Building Around the User

Another important part of this process was getting feedback from someone other than myself. When you spend so much time creating something, you already know exactly where everything is and how it is supposed to work. That can make it difficult to recognize what might be confusing to someone seeing the product for the first time.

Digital.gov recommends gradually getting feedback from people who are farther removed from a project because someone with fresh eyes may notice problems that people familiar with the design have overlooked.

I asked my mom to look through my reading journal and give me her first impressions. Overall, she liked how organized it was and thought the idea of having everything related to reading in one place was useful. However, she also thought the journal was still pretty bland visually and said that some parts of the layout could be clearer.

That feedback was actually helpful because I had been so focused on making the features work that I had not been thinking as much about the overall experience of looking at the journal. Based on her feedback, one of my priorities moving forward is adding more color and visual elements while also making the homepage easier to understand at a glance.

This also showed me that feedback does not mean completely changing an idea every time someone suggests something. Instead, it can help identify smaller changes that improve the original idea. Digital.gov describes feedback and revision as a cycle in which designers receive feedback and then revise the product based on what they learn.

Working Around Limitations

Iteration also became important when I started creating my Reading Stats section. My original plan was to have several visual charts showing things like books read, pages read, and ratings. I was able to create one chart for completed books, but then I discovered that Notion’s free plan only allows one chart.

At first, this was frustrating because it meant the page could not look exactly how I originally imagined it. Instead of removing the Reading Stats section altogether, I found another way to display the information. I used filtered database views and Notion’s calculation features to automatically count finished books, total pages read, and five-star books.

In some ways, I actually like this solution because the information still updates as the user adds books without requiring them to manually calculate anything. It reminded me that product development is not always about sticking perfectly to the original plan. Sometimes a limitation forces you to find a different solution that still accomplishes the same goal.

Notion’s own product-development guidance describes the build-and-test stage as creating a small working version that can validate the core idea and then iterating from there. That is basically what I have been doing with this project. Each new feature gives me a chance to see what is realistic within Notion and what needs to be adjusted.

A Product Is Supposed to Change

Probably my biggest takeaway from this stage of the project is that changing something does not mean the original version was bad. The point of creating a first version is to have something that can actually be tested.

Human-centered design is meant to be cyclical rather than something that happens once. After creating something, designers can evaluate how well it works, learn from users, and continue adjusting the product.

My reading journal looks different now than it did when I first started building it, and I expect it to look different again by the time I finish. This week alone, I changed how books are displayed, created a Monthly Recap section, developed Reading Stats, experimented with automation, and received feedback about the visual design.

There are still things I want to improve, especially the colors and overall homepage layout. However, I now have a much clearer idea of what the final product should feel like. Instead of trying to make the first version perfect, I can build something, test it, learn from it, and make the next version better.

And honestly, I think that is what makes the development process useful. The first version does not have to be the final version. It just has to give you somewhere to start.

Citations

General Services Administration. (n.d.-a). Feedback. Digital.gov. https://digital.gov/guides/hcd/design-concepts/feedback

General Services Administration. (n.d.-b). Iteration. Digital.gov. https://digital.gov/guides/hcd/design-concepts/iteration

General Services Administration. (n.d.-c). The HCD approach. Digital.gov. https://digital.gov/guides/hcd/introduction/approach

Gowland, M. (2026, April 1). Product development process: 5 key phases & examples. Notion. https://www.notion.com/blog/product-development-process