- Source Code & Resources PRO
- Lesson 1: Introduction PUBLIC
- Lesson 2: The Agile Methodology PUBLIC
- Lesson 3: Project Planning PUBLIC
- Lesson 4: Initial Client Meeting PRO
- Lesson 5: Planning and Prototyping PRO
- Lesson 6: Diagrams and Documentation PRO
- Lesson 7: User Stories PRO
- Lesson 8: Project Management Overview PRO
- Lesson 9: Setting up the Project PRO
- Lesson 10: Continuous Integration PRO
- Lesson 11: Cypress Dashboard PRO
- Lesson 12: Continuous Deployment PRO
- Lesson 13: A Change Request PRO
- Lesson 14: Planning the First Sprint PRO
- Lesson 15: Merging with Pull Requests PRO
- Lesson 16: Configuring CI for Firebase PRO
- Lesson 17: Sprint One Review PRO
- Lesson 18: Sprint Two Review PRO
- Lesson 19: Sprint Three Review PRO
- Lesson 20: Conclusion PRO
Once again, according to the Agile manifesto:
Working software over comprehensive documentation
But this doesn't mean that we shouldn't create any documentation. We've discussed this quite a bit already, so to cut right to the chase, what we will be doing in this lesson is creating documentation/artifacts that will be immediately useful to us at this stage of the project.
The artifacts we will create in this lesson are:
- Wireframes illustrating the various screens
- A more formal data model
- Sequence diagrams that cover the more novel features of the app
Let's get into it.
You can use whatever you like to put together a wireframe, or maybe you even decide that a wireframe isn't needed for your circumstances, but a great tool to use is Figma.
You might want to create flashy and realistic wireframes that look impressive to show stakeholders, but in general I prefer to make the wireframe less realistic and more like a rough sketch. The point of this stage isn't to design exactly what the application will look like in the end, it is just to capture our current rough understanding of where we are heading. We just want to capture some key layout/placement ideas.
If you prefer, you can use a design system like Material Design in Figma to create more accurate wireframes and you can even create clickable prototypes. But one of the key reasons I think it is a good idea to use one of the more rough/sketchy looking wireframes is because it more accurately conveys what its purpose is to the client - a rough sketch of what we are building. You don't really want to create the impression with the client at this stage that this is specifically what is being built (that is an approach that would suit a waterfall model better).
If you want to follow along and try Figma for yourself, you can just go to this page and find the Mobile wireframe and click Try Figma for free. Once you are inside of Figma you will need to download a UI Kit - you can choose the Mobile Wireframe UI Kit or something else if you prefer.
If you have never used Figma before then you might want to watch a few YouTube tutorials to get a sense of how the interface works.
Before we get into actually building a wireframe, we need to have a sense of what it is we want to create. We will take all of our initial draft user stories, and come up with a basic plan of where each bit of functionality will fit into the page layout. For more specific advice on some things you might want to consider when designing the page layout/navigation, you might want to check out the navigation concepts lesson from the Improving User Interface & User Experience module.
Let's start by just dot pointing some pages that we think might satisfy our user stories:
- Log in with Google (not prominent as only admin will use this link, likely just have in bottom right corner)
- Leave feedback / get in touch options
Tab 1 (Clients)
List of clients
- Client details
- Upcoming appointments
- Previous appointments
- Add appointment
- View/Edit survey
- Notes for client
Tab 2 (Checklists)
List of checklists
- View/Edit checklist