How can we develop a mobile application where low-literate NT2 citizens get explanations for letters they don't understand?
Wiki • Design Rationale • Prototype
- Props to the way you work together.
- Good job on testing, very useful insights.
- TTS button is quite small.
- Contrast with buttons needs to be checked.
- Explain what the user needs to do when they need to do it, especially when uploading a letter.
- Get help from volunteers who helped you before.
- Buttons are pretty far up on the screen for mobile users.
- Zero state needs a lot of improvement on the home page.
- Are there too many audio buttons?
- Add an "archive" where all resolved letters are put.
- Add deadline to letter, so volunteers know the letters needs a response in X days.
- Think about filter options.
- Underline on Image Buttons need to be removed.
- Images have a weird white background in the onboarding.
- The notification icon needs to be replaced still.
- The footer on upload screen does not look right.
- Amount of organisations to choose from is scarce.
- Submit letter button is not in the right place.
- Sections at the letter summary page can have a little more space, horizontal lines can be removed.
- Arrows in carousel can be made smaller.
- Add page button can be aligned better with the rest of the elements in the footer.
- Audio doesn't work at all in Safari.
- There is no feedback on register and login forms.
- Languages are not shown with letters on the volunteer homescreen.
- Remove underline on image button text.
- Remove image background in onboarding.
- Replace the notification icon.
- Fix footer layout on upload pages screen.
- Add more organisations to the list.
- Fix location of the submit button on the letter summary page.
- Fix the styling on the letter summary page according to Tessa's feedback.
- Make arrows in carousel smaller.
- Update alignment of add page button on upload pages screen.
- Fix audio upload and playback in Safari.
- Add feedback to register and login forms.
- Add languages to letters on the volunteer homescreen.
- Complete flow of user to be able to test it.
- Get a test result.
- Onboarding process is very abrupt for "users". It isn't clear that the app is about to be explained to the user.
- Change text of buttons on page where people are asked to tell their preferred languages.
- Language or multiple languages? Revise text for languages select flow.
- Title.
- Search.
- Ask to put language page.
- Titles on pages can be more descriptive.
- Placeholder on language search input.
- Buttons don't show where you're going in the app.
- Back button on register page, which brings you back to the place you came from.
- Zero-state on the dashboard is non-existent.
- Cannot reorder pages when uploading them.
- Text near the record button on chat page is too big.
- Separate page for summary and adding organisational bodies.
- Summary page links back to previous steps. Previous steps then link back to summary page
- Adding organisational bodies is separate page, has a list of suggestions.
- Needs to be skippable.
- Add missing parts of the UI Stack.
- Loading
- Error
- Zero-state
- Empty state
- Feedback in general
- Update UI stack with loaders, error handlers, empty states, zero-states and other types of useful feedback.
- Reorganise flow of uploading a letter.
- Upload pages.
- Optionally choose/enter organisational body.
- Summary with links to edit parts.
- Resize text on chat page.
- Add ability to reorder pages.
- Update image for letter notification explanation
- Productivity went very well.
- Time management, taking breaks and stopping on time.
- Testing, and what we got out of it.
- We got more done in less time.
- Taking enough breaks.
- Solving issues more invdividually.
- Having more attention to detail, solving small issues that you find while working on others.
- Interfere less with other's work.
- Keeping up with the workflow.
- Expectations.
- Merging features after they are fully completed/implemented.
- Holding your temper, even though it's hot as heck.
- Prepare tests better.
- Keeping all issues up to date.
- Keep up with the healthier schedule.
- Keep expectations realistic.
- Complete features before merging them.
- Create test document in preparation.
- Enter issues for next week on time.
- Detecting languages through the OS. Suggest languages based of country of origin of OS language.
- Don't use flags with languages.
- Feedback Tessa about TTS vs Spoken Audio for spoken text paragraphs.
- Margins between image buttons is confusing.
- Images used with the buttons may be too stereotypical.
- Some text content is unclear, may need some revising.
- For testing: List of contacts from Tessa, classmates who know people, student groups, Refugee volunteering, DUO, Community houses, BIKO as points of contact for the target audiences.
- Help button on upload page needs to stay consistent with other pages, only explain the page that the user is on.
- Skip button on onboarding after first time seeing it.
- Wording of buttons on index page is confusing.
- Add register page back button.
- Change the design of the search languages page.
- Tessa will send examples.
- Slow down TTS speed, prefer certain voices over others.
- Always use page 1 as the thumbnail for a page.
- Apply design onto app.
- Undo help button action on upload pages screen.
- Add skip button to add letter onboarding after going through it once.
- Change text in buttons on index.
- Change speech synthesis voice and playback speed (maybe pitch if necessary).
- Redesign app according to XD design.
- Font weights.
- Margins.
- Paddings.
- Button sizing.
- Colors.
- Layout spacing and alignment.
- Redesign select languages page with design patterns supplied by Tessa.
- Finished everything we could and wanted to do this week.
- Good task delegation and time management.
- Good workflow for seperating issues and pull requests.
- Focussing on what is important.
- Communication went very well.
- Actively giving feedback to each other.
- Clear scope of what needed to be done.
- Attention to detail in terms of the design.
- Lack of breaks.
- Not submitting new issues from things you stumble upon.
- Reassessing task delegation throughout the week.
- Delegate more challenging issues evenly.
- Too much guidance through from peer to peer on issues.
- Make sure the design of new features has been looked over and fixed before feedback sessions.
- Stopping on time.
- Stop working on an issue if you're stuck.
- Not trying to fix an issue if it becomes overbearing.
- More focus on the visual side of features.
- Distribute tasks more evenly.
- Have something to do the entire week/put just enough pressure on yourself to take action.
- Task delegation.
- Less guidance on issues, instead ask for help.
- Delegate challenging tasks more evenly.
- Clear day schedule.
- Enough breaks.
- Step back when you can't seem to fix an issue.
- Testing is important, make time for it.
- Initial planning structure is very impressive, keep it up!
- Don't spend too much time thinking about the tools you use, but spend that time thinking about the features you create.
- Discussed learning goals were well-formulated, don't forget to write them down.
- Selecting language on speech not viable
- Dialects and accents
- Not really necessary for volunteers
- Divide languages by country of origin with country flags as visual aid
- Search for spoken languages
- Autocomplete
- Add multiple languages
- Show country of origin with country flag
- Language is a recommendation, not a rule
- Most volunteers will speak mostly/only Dutch anyway
- Amount of pages to photograph is indeed unnecessary
- Supplying the sender of the letter is a good idea
- Should be optional
- Might help with noticing urgency and quality of explanation
- Volunteers should filter letters they receive on preferred languages
- Should not set them on their profile
- Users
- Language selection
- Select languages by country
- Search for spoken languages
- Letter sending
- Ask if all pages have been photographed or if there are more
- Optionally add the sender of the letter
- Language selection
- Collaboration went well
- Setup of workflow
- Task delegation
- Pushing of opinions
- Stop trying to fix something after a certain point
- Good enough is perfect
- Estimating scope (too ambitious)
- Defining scope
- Seperation of issues and focus
- Task updates
- Eliminating distractions
- Defining tasks/job stories
- Test with the target audiences
- Change job stories to descriptive issues
- Make issues more easily self-contained
- Create issues when you hit a road block on another
- Related issues
- Update issues when you're working on them
- Define a more conscise scope
- Set roadblocks for overworking
- Breaks
- Stopping on time
- Work schedule: Stand-up & wrap-up
- Keep up task delegation
- Improve workflow
- Keep asking for help
Low-literate NT2 people in The Netherlands have a hard time dealing with formal letters they don't but want to understand. It's very difficult for them to assess if the letters require immediate action. They usually have to ask help from community centers, neighbors or family, which may take more time than necessary. Another factor is that more than enough people inside this demographic are ashamed of being low-literate, which makes opening up about it and asking for help difficult.
So the solution to this problem should be fast and anonymous, so that users don't feel uncomfortable asking for help. This is how we formulate the design challenge from the problem statement:
How can we develop a mobile application where low-literate NT2 citizens get explanations for letters they don't understand?
Our client for this project is Tessa De Goede, alumnus of Communication & Multimediadesign. For her graduation project Tessa came up with the idea to create a application for functional illiterate people. The current problem for this target audience is that they don't speak and write the dutch language well and have problems with understanding letters they receive from organisations and bodies. Currently these people are dependent on their neighbours, family or community centers to explain the letters to them. The steps a functinal illiterate person has to take to get the letters explained to them are currently cumbersome and time consuming.
The Wat Zegt Deze Brief application wants to resolve this problem by providing a platform where functional illiterate people can submit the letters they receive from organisaties and bodies. Volunteers will be active on the platform and translate/explain these letters to these people so they know which steps they have to take next. Thus eliminating the time consuming process of finding a person that can help them explain the letter.
The research and design of the application has already been delivered by our client. Our job is to create a web-application for this concept. For this project we will be working with the Scrum methodology, this is an agile development methodology where we, the developers, will working in an iterative process. We will be working in sprints of 1 week to develop the functionalities of the application and present the prototype to our client at the end of the week. This helps us generate value for our client by working in an effective way with clear communication between the client and us (the developers).
For the client it is important that we develop a working application that has the following core functionalities:
- Users need to be able to chat with each other in voice memos through a chat functionality
- Users need to be able to take pictures and submit them
- Users need to be able to provide a spoken explanation with the use of the dictaphone functionality
For the client it is important that she has a clear idea of our progress during this project. To follow the progress of this project it is important to the client that we submit a prototype at the end of every week and discuss the current progress.
This project has been made available to us by the the course Communication & Multimediadesign of the Hogeschool van Amsterdam. For this project we are assigned to a coach (Vasilis van Gemert) that will coach us during the process of this project. Every week we will be meeting with our coach to discuss the current progress of the project and receive feedback and guidance. To be graded at the end of the project we will have to provide the following deliverables:
- Design Rationale
- Product Biography
- Individual reflection on the project
- A happy customers
Based on these 4 deliverables we will be graded.
The target audience consists of two groups. The functional illiterate people and the volunteers that will help them explaining the letters. It is important to the target audience that an application is provided that fullfills their needs. For the functional illiterate people it is important that the application has the following aspects:
- Interface of the application doesn't have to much text
- The application should persist the language level A2
- Text in the application should be provided with an image to make it more clear
- The application should give a spoken explanation of the submitted letters
- The application should take away the shame they experience when they ask for help
- The application should be able to provide explanation in the mother tongue of the user
For the volunteers it is important that the application provides the following aspects:
- Volunteers need to be able to provide a spoken explanation for the letters
- Volunteers should be ale to read the submitted letters of the users
- Volunteers should be be able to choose for which submitted letters they want to provide an explanation
For us, the developers, it is important that we deliver an working application that fulfills the client's and the users needs. To achieve this it is important that we will be making a schedule that we will follow to provide a prototype every week for the client to see and discuss our current progress.
- OCR and redaction for scanned documents
- Dictaphone on the web
- Notifications in web apps
- Kickoff
- Write debriefing
- Think up User Scenarios/Job Stories
- Common reusable atomic components
- Onboarding
- User accounts
- Letter
- Photo
- Sender
- Upload date
- Amount of pages
- Page editing
- Urgency (based on date, maybe on amount of reminders)
- Resolved
- Present iteration 1
- Retrospective and planning (Product biography)
- Process feedback
- Volunteer features
- Review pages
- Respond to letters
- Filters and sorting
- Chat feature
- Automated text responses
- Voice messages
- Present iteration 2
- Retrospective and planning (Product biography)
- Process feedback
- Finish all features
- Present iteration 3
- Retrospective and planning (Product biography)
- Process feedback
- Enhance features
- Present iteration 4
- Retrospective and planning (Product biography)
- Process feedback
- Enhance features
- Present final iteration
- Expo
- Project management & setup
- Documentation
- Front-end
- Creative
- Interaction
- Technical
- Support
- Back-end
- Data flow
- Authentication
- Real-time
- Support
- Project management & setup
- Front-end: Interaction & Creative
- Back-end: Authentication
- Front-end: Technical & Interaction
- Back-end: Data flow & Support
- Documentation
- Front-end: Technical & Creative
- Back-end: Real-time & Support
A working prototype which started from the concept and designs from the client, but has been iterated on to create a unique product which will be of great value to the customers who use it.
A rationale, by the entire team, consisting the following:
- Debriefing
- Problem definition
- The final solution
- Code explanations
A product biography, by all individuals part of the team, consisting the following:
- A weekly log of the work that's been done and the process
- Sketches, tests, code examples and inspiration
A personal reflection, from your perspective and level of expertise, containing the following:
- Which subjects came in handy, and why, by looking back at their rubrics.
- Possible points of improvement on technique, interaction and/or other aspects of the design process.
Volunteers are people who are intrinsically motivated to help others where and when they can. The volunteers using this app have enough knowledge of the Dutch language to help people who are low-literate in explaining more formal Dutch. General knowledge of what formal letters a person might receive is also important.
They want to help explain difficult letters to people who are low-literate or have a hard time understanding formal letters. Generally speaking they want to help society.
- Receive letters from people who want explanations for them.
- See clearly what the letter says.
- Tell the recipient what the letter means through voice, and if action should be taken.
- At a place and time without much environmental noise.
- When they receive a new letter to explain.
- The environment must not be noisy, for the volunteer to be understood clearly.
- The volunteer must have enough time to read, understand and explain the letter in easy-to-understand Dutch.
- The internet connection must be sufficient to send over the voice messages.
Low-literate people have a difficult time reading and understanding formal Dutch. This means that letters from senders that use formal Dutch are hard to understand, like government letters. A lot of low-literate people are quite ashamed of this, which makes seeking help difficult. These people also need help with understanding how to use certain products, as they may not use them the same way as literate Dutch people do.
Low-literate people want their formal letters explained, so they know if action needs to be taken or not. This needs to happen anonymously by default, to prevent shaming.
- Upload a letter.
- Redact personal information.
- Receive and listen to explanations.
- Ask for further explanation if wanted.
- Take action on the letter if it's required.
- Thank the volunteer for their help.
- At home, where they receive their letters.
- With their phones, so they can photograph their letters.
- General knowledge of technology.
- A phone with good camera quality for good legibility.
- A well-lit environment to take clear pictures.