Design Process

Date of the meeting: 11/07/2023

In the story of LiteFarm we have had different types of requirements notes, some more high-level some not so much.

Ivan mention what he showed the last retro (high-level requirements note), so the developers would be able to have more context about the tickets. This will allow us to understand why we are building the new feature and what are the technical considerations.

We want to be able to reach a consensus between the requirements and what we can actually build.

He talked about Finances 2.0 note and how this doc can be helpful.

Joyce mentioned that until she gets into the implementation sometimes is hard to tell if something is going to be difficult to work on.

Iván mention that Jira tickets are for tracking progress to get to that goal (which will be set on this document, eg: Finances 2.0)

Kevin talked about the history of PRDs and how they evolved because these documents were very long and mind-numbing and that’s how agile became very popular. Agile is fluent, where only epics and issues are updated and sent to development, without a requirements note.

The doc on Finances 2.0 is an example of Kevin’s idea of how this in-between would look like.

Module level, Group of requirements, includes various epics and finally tickets.

The idea is that Kevin puts up this document and then the designer and engineer team will go through it, make questions, change requirements, etc. And then the designer will create the prototypes.

Joyce mention that we need to have another document, just for technical requirements as the high-level requirements note will look very different to the one from a Product and UX/UI point of view. She mentions this document is not really helpful for the developers as there is no specification about the technical side of the new feature. Finances 2.0 is a good example since the base code is outdated and there is a lot to be reviewed.

What does the QA team think about theses docs?

They think they need to see it in action to have an opinion.

Caro: does the fact that the base code is outdated is it realistic to make these release on summer?

Tech team will talk about it on the Tech daily.

Duncan mention that it would be good for developers to be involved throught the whole design process to be able to own that feature

Figma meeting for developers might be useful. They would be able to view the prototype and flows and leave comments.

Grooming should still happen.

Caro and Kevin agreed that that is hard to imagine how that will work since the design process of a feautre is caotic and wouldn’t be that helpful for the developers. The team agreed that being able to review the features from earlier stages would be very helpful.

Actions to be taken: Still unclear.