Daily Stand Up #6 - Ticketing System
Yesterday: Apply link structure to existing design and clean up the look of it a little more.
Today: Originally I had planned to continue with the wireframes in Sketch but got a strange feeling that everything was very disorganised. A lot of the planning I did when decided what elements to put on each page were missing a number of links after I reorganised the sitemap yesterday.
I decided to change what I was doing today and build a spreadsheet with each page and component with brief notes on what they contain. This will put me in a better place for continuing the wireframes tomorrow.
With this being my first large solo project I am struggling mostly with the scale of it and keeping things organised so trying to be as fluid as possible with what I am doing. I think my best approach is to just start wireframing stuff for now and keeping on top of updating documents as things change. This will help me see potential problems with my systems design earlier on and tackle individual problems in small chunks rather than trying to plan everything all at once.
First lesson learned here is that when designing something new, never start off with the navigation structure as it's most likely to change as the project evolves!
Tomorrow: Continue with the mockups in Sketch picking off 1 - 2 single components.
The purpose of a stand-up being to identify roadblocks...
"With this being my first large solo project I am struggling mostly with the scale of it and keeping things organized"
---------------------------------------
There's a great 4-part blog on functional specs: https://www.joelonsoftware.com/2000/10/02/painless-functional-specifications-part-1-why-bother/
I really like the approach of doing as much functional spec up-front as possible, recognizing they will change/grow/adapt. I then typically tease the functional specs out into user-stories, or tasks, or key deliverables, or TDD tests.
I like the idea of functional specs before UI/UX or at least in parallel because good UI/UX is informed by good specs.
---------------------------------------
I've started building the habit of going through each component of the software and building a user or data flow. So for example:
I typically create a spreadsheet with columns for the user, the server, and any microservices/APIs to define which action each will perform. That helps to define what inputs are used on each view, data stored, and variable names.
---------------------------------------
And finally, I appreciate yodiz.com for project management. It's a bit more robust than Trello so takes some configuration work to make it as "sexy". But I like the ability to tag a user story as applying to multiple components. I also like managing releases, epics, and sprints to go from macro to micro and pare down the backlog. By doing the upfront organization of user stories I can then go through and select all user stories relating to a given component and work on them so I'm not switching between multiple components.
Hope that helps.
---------------------------------------
P.S. I'm idly considering doing remote software product management (SPM) so let me know if you'd like a bit of help setting any of that up.
Thanks for the comprehensive reply here, there are some great pieces of advice! I'll definitely give the article attached a read.
In regards to functional specs I have a trello list of acceptance criteria/features the system should have but it doesn't go into great amounts of detail.
I think the majority of the issues I have is that at the moment I just have a bunch of words and things to do. I think that having words etc are great for a checklist of things you can cross off but in terms of dependency and very specific things such as "fields on each page etc" it's difficult to visualise in my mind.
I like the concept of just having a very rough idea and a basic set of components that should appear on each page. I feel like once I start building these out it will force me think about the decisions I need to make and the dependencies of each component and how they affect each other.
I do backend web development at my day job so a lot of this stuff has already been discussed, figured out and signed off before it hits my desk. This part of a project is relatively new to me (at least at this scale) so it's challenging but I do love a good challenge.
After looking quickly into Yodiz I'm definitely going to give it a try as I've felt like Trello is great for small notes and things that come to mind but struggles with dependency and properly grouping things. Seems like Yodiz follows a more Agile structure which is what I probably need/want to build.
Thanks again for your comment above, it's been a great help!