This weeks agenda:

The team standup is a meeting, typically lasting 15 minutes, held at the start of the day where everyone gives a brief status update on what they did yesterday, what they’re doing today and raise any issues that may impede completing their task. Everyone stands to keep the meetings short. This project transparency allows the team to anticipate any challenges that could arise further down the track and work together on solving difficulties.

As tasks aren’t ready to be assigned yet, we were given a short rundown on each of the roles instead. The role of experience design (XD) can be broken down into several parts:

• visual/graphic design - the look-and-feel of the user interface consisting of colours, images, type, space and symbols whose purpose is to visually communicate a message.

• information architecture - structure and organisation of information. Information denotes objects like people, documents, web sites, images or more broadly speaking, represents metadata. Decomposing these down to their essence into simple labels and grouping them so that users can easily find the information they want and navigate through the system.

• interactive design - intuitive consistent interface, adding features and information important for the user, ease of use

Afterwards, all the BAs and XDs met in the kitchen area to discuss one story with a ThoughtWorks BA. Our team chose As Allen, I want to send a message to an emergency contact so that I can immediately get the help that I need to stop drinking. The acceptance criteria was:

• When Allen chooses the emergency option, a message should be sent to his emergency contact.
• When Allen chooses the emergency option, Allen should be able to cancel the message if he decides it is unnecessary to bother the contact
• If the network is down, an error message is shown as well as the emergency contact information

The BA felt the acceptance criteria reached beyond the scope of the story and suggested we split them up. We decided to keep the original story but move the cancellation acceptance criteria into it’s own story.

The next activity was wireframing and mapping out the user interface. After brainstorming the emergency contact story, we came up with several ideas. Once Allen presses the button, he sees a confirmation screen before sending the message. Another idea was to instead have a timer count down and send the message once it reached zero. This had the added benefit of being able to cancel the message but Rujia wanted the app to be simple, minimalistic, quick to use without extraneous steps. In the end, the idea that prevailed was when Allen held the button down for X seconds, the message is sent. A screen tells Allen that the emergency person has been contacted and after 5s, goes back to the main menu.

For the rest of the evening, we drew mock ups for the default, home, services and jokes screen.

To round out the end of the class, the developers joined us for a retrospective, writing on post-its what we did well, what needs improvement and any ideas/suggestions. The group prioritised that our app needed a name and that there needs to be more free flow of ideas. Gabe nominated that we all submit app name proposals on slack chat and Anna suggested we come up with a phrase/action to inspire better team cohesion. Since we were team ghost, someone said we should all cheer ‘wooooooh’ so we gave it a shot but ended up sounding like an alarm running out of battery. I guess we need more practice.

Slide decks

• Continuous Integration
• Creating a watch page