Our focus since we last spoke has been on the sign-in experience on the Designer Portal. We’ve updated the credentials so that after you sign in, your username and email are automatically shown. That way, it’s very clear that you’ve signed into the correct account and can proceed with updating your listings.
In addition, we wanted to make the sign-in layout consistent so that designers can easily and quickly sign-in across different devices. We also spent a bit of time to ensure that you won’t need to sign in each and every time to access the Fiber Club Designer Portal, unless you’ve intentionally signed out. While we are in the process of developing the site, we have prioritized user convenience. However, we are aware of the importance of security and plan to enhance the sign-in persistence in the future.
Since beginning work on the Designer Portal, we’ve focused on the point of view from the Designer. However, we realized we would need to work in conjunction with other views, such as the Admin perspective. This week, we created API endpoints for admins to approve, reject, and add comments when an enrollment is ready for review.
Lastly, we continue to read through the Lean Startup and gain insights into how we should be thinking of and experimenting with Fiber Club. A really interesting perspective was learning that small batching seems to work better than working in larger batches because you can more quickly identify issues and resolve them without delays.
The example in the book outlined a graphic designer working on mockups for the engineering team to work on. In the large batch work scenario, the designer would create all of the designs and then hand them over to engineering after they were complete. Afterwards, the designer would then move onto the next project, while engineering starts work on the current project.
However, this process assumes that once the designs are handed over to engineering, the work of the designer is completely done. In reality, there are often questions that need answers and sometimes even conflicts with the design that need to be redone. In those instances, the designer then has to pause the work that they’re doing on the new project and go back to their previous designs, re-doing work that was already complete.
If the designer does not have time to go back and redo their work, then the engineers will proceed with redoing the designs themselves. Either way, this process is not the most efficient and can lead to unnecessary delays.
After reading this section, it was clear that we’ve been working with large batches instead of small batches. We’ve made some changes in our work process in order to shift more towards small batches, such as more frequent updates, and we’re continuing to think of other ways in which we can apply this same logic.