Background
As an academic project, I worked in a team of UX Designers and Software Engineers to develop LakerLogs, a Web-based work log system that standardizes how students document and submit their weekly progress, and gives instructors a clear, organized way to review student submissions. I helped develop LakerLogs using the Agile Methodology. As the team leader, I reported on progress three times a week and presented a demonstration at the end of every two weeks. The process was incredibly informative of real-world software development experiences and it was a fantastic opportunity to work with other aspiring designers and developers.
Process
As leader of the Requirements team, I met with my team at the beginning of each sprint and I assigned tasks. We discussed progress and asked questions to our stakeholders regularly. Our mission was to the uncover the features that our stakeholders wanted, inform the design team, and document the software progress done by the full stack team. In tandem, I was the point of contact for whenever other teams had questions about our documentation or regarding stakeholder demands.
In addition, I was a member of the UX Design team. We started by learning about required features from the Requirements team and brainstorming how we could organize them. I created the information architecture diagram that served as the basis for our interface design. Whenever we discovered something new in our user testing or by the Requirements team, I amended the diagram and discussed with members as to where that feature should go.
Deliverables
The Software Requirements Specification Document
For the Requirements team, our contributions to the development of LakerLogs culminated into the Software Requirements Specification (SRS) document. The SRS documents all critical aspects of the software, including software dependencies, function requirements, and design constraints. For a team wanting to understand the inner workings of LakerLogs, the SRS serves that exact purpose.
The User Guide
As the intended audience of the SRS document is for software engineers, the User Guide is the companion for the end user. It serves as a manual that explains how to operate the interface and complete tasks such as submitting a work log, creating a class, and reviewing student work logs.
The LakerLogs Web Application
The LakerLogs Web Application is the end product we delivered to our stakeholders. LakerLogs solves the problem of students lacking an organized method of recording their weekly contributions and professors lacking an ability to overview student contributions for grading while ensuring students properly fill out work logs. It uses a microservice architecture powered by OpenLiberty and an interface designed using React to deliver a user-friendly experience on any web browser.
The Stakeholder Presentation
At the end of the process, each team contributed to a final presentation that explained how we got from stakeholder demands to an end product. I supervised the development of the presentation and harmonized the design to create a cohesive narrative that demonstrated our technical expertise from start to finish. We finished the presentation with a live demonstration of LakerLogs, and the stakeholders loved it.
Reflection
By the end of the process, the development of LakerLogs and my contributions overcame many challenges that arose throughout development. As a leader, I learned the importance of checking-in with team members and having regular meetings so that everyone is onboard with the tasks ahead. As a team member, I learned the importance of listening to feedback and recognizing when an idea becomes astray from the goals of the development and removing it. But most importantly, as a UX designer, I learned the importance of starting strong and conducting user testing as soon as possible to have a solid bedrock to build the rest of the software for the stakeholders and end users.