Role: Research, Design, & Prototyping
Duration: October - November 2022 (2 Months)
Tools: Figma, Figjam, and Discord
Readio is a mobile application that allows users to convert text into audio files. With its features to scan, import, export, and translate documents, it provides a convenient way for users to access and listen to information on the go.
Minimum Viable Product (MVP) is a small experience (like a testing).
Lean User Experience (Lean UX) is a design philosophy that emphasizes the real essence of a product in a collaborative, cross-functional, and user-centered manner.
Readio is the name of our app. The prototype is a mobile text-to-speech application. I am the sort of person that enjoys having someone read things to me. When Marconi, the team leader presented the idea for a class project, I was intrigued because I already use text-to-speech apps/websites/extensions when I am doing something or don't have time to read a big pdf document. When I finish reading a document or a long text, I may not recall what I read because it was a long text. We utilized the Lean UX technique to construct our prototype. Lean UX is a method that focuses on the idea of assumptions and testing the assumption when designing apps.
Lean UX is a method that fouces on the ideas of assumptions, testing assumptions, deciding as a group if those assumption are good or bad. Lean UX is more concerned with the experience under design than with the deliverables, and it necessitates a higher level of team involvement. Lean UX aims to collect input as quickly as possible so that it may be used to create a rapid prototype iteration. We utilized assumptions to address difficulties with our prototype which we, then tested it to see whether it worked. Lean UX assumes that your original product designs will be at least partially erroneous, thus the team's goal should be to figure out what went wrong as soon as feasible. When the team determines what works and what doesn't, they adjust their feedback and retest it, which keeps them on track.
Lean User experience (UX) is a thorough grasp of a user's needs, values, abilities, and restrictions (UX + Lean + Scrum). Lean is a strategy and a technique that aids in the elimination of waste in our UX design. Scrum is defined as the concept of completion. Scrum demands that all work done during a sprint be finished by the end of that sprint. We adopted scrum because it compels everyone to submit their efforts and presume that the final product is appreciated (While this is not always the case, it is the aim). Scrum is an agile framework that is adaptive, fast, and flexible in giving value throughout the project's development and "delivering value every sprint" (Gothelf & Seiden, 141 & 158). This was a class project, and we used the standup to modify Lean UX for this class. Sprint 1 and Sprint 2 of our app approach included the lean UX process.
We used Agile Sprint 1 and Sprint 2 in our class to adopt the Lean UX. First, we gathered and analyzed app-related data. Second, we generate hypotheses regarding our application. Third, we devised a strategy for each hypothesis. Four, we developed personalities. Five, we categorize features into ship & measure, test, don't test, usually don't build, and discard according to the value they give. Sixth, as a group, we voted on which aspects were significant and which were not. We prioritized the aspects that were critical to our app. Seventh once we had finished prioritizing our feature and drawing concepts. The solution is then improved for our features and tested. Finally, we conduct user interviews and get feedback on our features and prototypes. Remember that "Lean UX encourages you to reframe your work as a problem to solve rather than a “thing to build.” Don’t go into a sprint thinking, “What can we build?” Instead, use your sprint to figure out “How can we solve our problem?” (Gothelf & Seiden, 123).
Design week zero is a where as a team we discuss the Lean UX canvas, proto-persona, product backlog, prioritize, sprint backlog, prioritize, and spring backlog. With the help for the Lean UX canvas as a team we was able to created assumptions of our app. It called week zero because it where as a team it give us a set of different viewpoints, and build a shared understanding. So that before we move foraward to design, we need to make sure that week one is clear and we understand what we are doing. It guides as a conversation from the current state of our product and design to our end state.
The Lean UX Canvas is a set of exercises that allow teams to express their project assumptions. The canvas is designed to guide the debate from the present state or current condition of the product or system to its planned future state or target condition. Remember, that a design week is a week before developing, designing, testing, and prototyping, and is where designers put out all information in the open.
Our first step in creating our app, we first had to decide what our business problem statement was going to be. As a group, we came up with an assumption for our "yet-to-be-made” interactive UI-based design. As a team, we listed out ideas for our business domain. A business domain is a "company’s overall area of activity. Generally speaking, it’s the service the company provides to its clients". We the help for Our Business Problem “Brainstorm-dot-voting” we created Our Product Problem Statement.
Our business outcomes section was a way for us to figure out the solutions to our business problems in Lean UX Canvas 1. First, we needed to identify what our business-oriented impact metrics for our product's high-level strategic objective would be, such as profitability, growth, customer satisfaction, customer acquisition and/or retention, etc... Then, as a team, we did the Outcome-to-Impact Mapping together to better understand our product and to make some assumptions about how we will know that our design is “successful” for our users.
During our Outcome-to-Impact Mapping, as a team, we identify our outcome Metrics - lagging and outcome Metrics - leading order metrics that helped to create our business-oriented Impact Metrics.
After we were done with our business outcomes, we created two proto-persona, which were based on our team's assumption. This means that our proto-persona was based on doing no research and it was determined what sorts of user and customer persona we will focus on as a team. Our Proto-persona #1 was based on a Gen X person (40s) who alternative to listening to podcasts (consuming info in audio form). Our Proto-persona #2 was based on people with visual impairments / Learning disabilities.
After we were done creating our users, we had to understand why our users will seek out our product. In order to figure out that, we answered some questions to help us with our Proto-persona #1 and #2. So, that we could better understand our user outcomes and benefits for each of our personas.
.png)
After we were done with our User Outcomes and Benefits. Now, we need to seek solutions. So, as a team, we all did an affinity map together to figure out what solutions we can design and build that will serve our proto-personas and create their desired outcomes. During our solutions-affinity map, we all individually listed out solving will help our targeted proto-personas, and At the end, we collected insights together.
When we was done with solution, we combined all of our assumptions from business outcomes, users, user outcomes and benefits, and solutions into a hypothesis statement: “We believe that [business outcome] will be achieved if [user] attains [benefit] with [feature].”
when we was done with, creating our hypothesis table. We mapped out all our assumptions into a hypothesis prioritization canvas, and we divided our assumptions into four categories: Ship & Measure, Test, Don’t Test, Usually don’t build, and Discard.
%20(4).png)
After we was done with our hypotheses, we reorder our Hypothesis Table based off the riskiness of our assumptions. So, that we can better understand the most important thing that we need to learn first about our hypothesis
%20(6).png)
Then, for our hypotheses for the business result, proto-persona, user outcome, and feature, we built the product backlog and our sprint 1 backlog. The product backlog is a prioritized list of work items or features that help teams fulfill product goals and set team expectations. A sprint backlog is a list of work items that your team wants to do throughout a project sprint. These items are frequently pulled from the product backlog during the sprint planning session.
%20(5).png)
%20(4).png)
%20(6).png)
For, Design week 1, we have just gone through design week 0. In sprint week 1, We completed three user research interviews/usability tests for our assumptions during sprint 1 week 1 and held two 2-day stand-up sessions. Before each of our interviews, we had to have each interviewer sign a permission form. We had two moderators and facilitators for each interview. The moderator was in charge of asking questions and keeping the conversation going with our interviewees. During the interviews, the facilitator was in charge of taking notes and might ask questions that were not in the interview script.
%20(10).png)
Before our interviews, we wrote interview scripts to keep us on track, as well as questions to ask interviewers about our prototype MVP A. For sprint 1 week 1, we interviewed three people: D.L., J.M., and M.D., and created an affinity map. We produced an MVP A flow prototype to test the waters with our product's Premium and Reward Systems features for sprint 1 week 1. We performed an interview/usability test, as well as user interviews through Discord and in person. We conducted an Affinity Map session for each interview. The team then went over the new framework for prototyping and iteration. We listed interview findings from our last interview and ideas to iterate MVP after all three interviews (A).
%20(9).png)
For, Design week 2, we did a 2-day stand-up meetings, interviews, affinity maps for our interviews, and the retrospective during sprint 1 week 2. We discuss each person who was there for the interview that week, what we did each day for that week for each member, and a summary of what happened last week at our two-day stand-ups meeting. We completed a summary, done since, to-do, and what will happen in the next meeting on the 2-day stand-ups worksheet. Prior to our interviews, we wrote interview scripts to keep us on track, as well as questions to ask interviewees about our prototype MVP (B).
%20(11).png)
For our sprint 1 week 2, we interviewed three people: A.L., A.M., and R.G., and created an affinity map. Before each of our interviews, we had to have each interviewer sign a permission form. We had two moderators and facilitators for each interview. The moderator was in charge of asking questions and keeping the conversation going with our interviewees. During the interviews, the facilitator was in charge of taking notes and might ask questions that were not in the interview script. Finally, for the affinity maps for the interviews, we conducted a Sprint Retrospective on our prototype MVP (B). We gather as a team to discuss what went well, what went wrong, and what can be improved in our prototype MVP (B). The idea behind a retrospective was to talk about what happened throughout the product design and development process to improve things in the future based on feedback and conversations with all group members. The lessons we acquired in Week 1 affected what we did in Week 2 since we were testing new MVPs and trying not to repeat the mistakes we made in Week 1.
%20(15).png)
We did a Sprint Retrospective meeting at the end of our Sprint 1 . A Sprint Retrospective is when a meeting is held at the end of a sprint and before the start of the next sprint. it where teams reflect on their past design to see what went right, wrong, and need improved so that their are able to improve their next sprint.
%20(12).png)
For Design week zero, We all gathered in class this week in Design Week Zero to discuss the Lean UX canvas, proto-persona, product backlog, prioritize, sprint backlog, prioritize, and spring backlog to see whether we kept the same detail from sprint 1 but changed anything around as a team. Revalidation is the process or act of reaccepting or approving major modifications. We revalidated our proto-persona #1 and dropped the Proto-Persona #2 to reflect data from user research interviews, hypothesis table, hypothesis table (ordered by risk), and business problem statement, and dropped one for our hypothesis table MVP and business outcomes (outcome-to-impact mapping). We also updated our product backlog and sprint 2 backlog.
%20(20).png)
%20(23).png)
%20(24).png)
%20(17).png)
%20(16).png)
%20(30).png)
%20(27).png)
%20(28).png)
%20(29).png)
This approach taught me that it is alright to go back and revalidate what you did in sprint 1 and shift things around and delete stuff to make it better. Our proto-persona(s) have changed since our first sprint. Sam Castillo, a 45-year-old lawyer, is our first Proto-Persona change. who enjoys spending time on hobbies and working out. To Sam Kobayashi, a 21-year-old full-time college student who enjoys playing video games and scrolling through social media. We changed proto-persona #1 to match our findings from user research interviews. Our second proto-persona was changed from spirit 1 persona after our teams reviewed the results from our user research interviews. We opted as a group to remove the second proto-persona in order to reflect findings from our user research interviews.
We executed three user research interviews/usability tests for our assumptions during sprint 2 week 1 and held two two-day stand-up sessions. For sprint 1 week 1, we interviewed three people: M.D., J.W., and F.B., and created an affinity map. This week's procedures differed from sprint 1 in that we addressed the style, design, colors, and typography for our app's hi-fidelity version prototypes. We made some judgments on what to keep and what to remove from our app. And we started thinking about our next interview. We test our voice library, icon, and hi-fidelity version, generate a new file, translate different sorts of languages, premium, and advertisements, and customize our software throughout our user research/testing sessions. Following each affinity map, we had a two-day stand-up and walked over design styles that we might include in our app.
%20(32).png)
%20(34).png)
We had 2-day stand-up meetings, interviews, affinity maps for interviews, and the retrospective during sprint 2 weeks 2. For sprint 2 weeks 2, we developed MVP (C) prototypes, three interviewees, and an affinity map for each. At the start of the sprint, there would be two proto-personas: a 45-year-old lawyer and a 21-year-old full-time college student who was dyslexic. As we conducted user testing and interviews, we decided to update our proto-persona and just have one proto-persona to reflect the new information we discovered about our app. Sam Yasuda, a 21-year-old full-time college student who enjoys playing video games and reading social media, is one of the three proto-personas. I learned that your first proto-persona will not be the same thing at the conclusion of the project since we were able to refine our proto-persona through the tiny version for prototype, interviews, and user testing we completed throughout our project.
%20(36).png)
%20(35).png)
%20(37).png)
After we are done with sprint 1 and sprint 2 as a group we stared working on our Final prototype with the feedback we get from the interviews and our testing.
I was able to apply the Lean UX strategy to design a product and deliver it on time before the next sprint began at the conclusion of this project. MVP, user research, and testing were enormous assistance since we produced a little version of what we went about and how the app appeared to test. If we did not get any important data or saw that it was unnecessary, we abandoned the notion. Understanding the Lean UX process and working with a team to complete tasks rather than a single individual working on the entire project. Our teams were able to design an efficient project that enhanced our goods. The difficulties I encountered were in finding persons to interview and in completing past work before moving forward to the next meeting. I cope with these problems by attempting to complete the task before the next meeting. The lesson I learnt was that when they say no, I just go with folks I know are working or students. As they are pressed for time. I learned a lot about hypotheses, Lean UX, Lean UX Canvas, Adapting Lean UX, product backlog, and sprint backlog. This project taught me that Lean UX is about constant learning and reviewing a design through a process.
