Lean UX Startup Design
In one of my earliest projects, I worked with a cross-functional team of UX designers and developers to build a proof-of-concept app from scratch in less than ten weeks, using the Lean Startup methodology.
Applying the Build - Measure - Learn cycle we identified the target audience, defined the user problem, and ideated a possible solution. Then we collaborated using Scrum to design and develop a fully functioning single page application (SPA) built with Google Maps API.
Overall, the project taught us the importance of understanding the user's needs and taking time to explore the problem space before moving onto the solution space.
Assignment
Developing a fully functioning POC for a novel service solving a validated user problem, using the Build - Measure - Learn cycle of Lean Startup methodology.
Engineering
Design & Research
Project Title
Lean Startup UX Design
Introduction
This was one of the earliest projects undertaken during my UX design education at Stockholm Technological Institute (STI). I chose to showcase it due to the valuable insights gained and the satisfaction derived from working on it.
A key challenge was validating our hypotheses at each step of the way to ensure we were designing the right thing for the right users. We applied the Build - Measure - Learn cycle to identify the target audience, define the user problem, and ideate a possible solution. Transitioning from problem space to solution space, we collaborated using Scrum with a team of developers from our sister class of Java students to develop a fully functioning single page application (SPA) built using Google Maps API.
This project taught me the significance of thoroughly exploring the problem space and validating one's assumptions and hypotheses before progressing to the solution space.
Insight work
In this phase of the project, we applied Lean Startup methodologies to find a target group, identify one of their problems, and ideate a possible solution. We conducted workshops and quick studies to validate our hypotheses every step of the way.
Finding the target audience
We began by brainstorming and suggesting target groups, such as smokers, horse enthusiasts, and people who enjoy working out. We then narrowed them down through a voting process and selected the target audience: people who enjoy taking walks but were unable to do so during the pandemic. This enabled us to specify both the target group and their inherent problem.
We formulated the following problem statement or base assumption:
"There are people who enjoy going for walks but have been locked indoors due to the pandemic.”
To validate the hypothesis, we conducted research by reading reports and interviewing people who belonged to the target group. We did this to understand how the pandemic had affected people's routines for going out in nature. We drew conclusions and updated our hypothesis as we learned new lessons during the problem space phase to be agile in our approach.
Defining the Problem and Solution Space
To ensure that we developed a product that met the needs of our target audience, we followed a user-centered design process. We started by creating a persona and an empathy map (fig. 2-3), which helped us gain insights into our target users' background, needs, and desires. We then formulated a problem description to clarify how we could help the user, and used this to set goals such as vision, mission, objectives, and key results.
Based on this groundwork, we developed the following solution hypothesis:
"By creating a service for finding new routes for walks, we can help the members of the target group get out of the house and move."
After contacting individuals in the target group, we found that 17 out of 25 respondents in the small survey indicated that they would 'probably' or 'definitely' benefit from the proposed service. Based on this validation, we proceeded.
Figure 2. Our persona 'Alexandra', who feels locked indoors as a result of the Covid 19 pandemic and being forced to work from home. Lacks the initiative to get out and take walks.
Figure 3. Empathy map describing what our persona says, thinks, does and feels relating to the internal conflict of not going outdoors anymore.
Solution work
We collaborated using Scrum on a rotating, weekly schedule, where each team member got a chance to take on the roles of the Scrum Master and the Product Owner at least once or twice. This approach enabled each of us to gain insight into the responsibilities and roles of both Scrum Master and Product Owner, fostering mutual understanding and collaboration between the team members.
Working with the developer team, we took lead and planned the work through a backlog in Jira to ensure that all tasks and requirements were tracked and addressed in a timely manner. We conducted daily stand-up meetings to discuss progress, identify any blockers or challenges, and determine potential solutions. As new feature requests or changes were identified, we evaluated them in collaboration with the product owner and Scrum master to prioritize and adjust the backlog accordingly.
The team divided the work into tasks based on the story map, which we had drawn up and prioritized together earlier (fig. 4). The story map consisted of an overall user journey, which was broken down into smaller user journeys and functional requirements. Each sprint lasted a week, during which one person from the UX team assumed the role of Product Owner, while another took on the role of Scrum Master. The Product Owner led the team's planning and organized the tasks in Jira, while the Scrum Master ensured group cohesion and smooth workflow.
Figure 4. Our Story Map visual tool for user stories, helping us organize and prioritize the various features, ensuring that we focused on the most critical aspects first.
Double diamond workflow
Throughout each sprint, both within and between the two teams, we adhered to the double diamond structure. At the start of each week, we began with separate brainstorming and idea generation sessions, allowing for free exploration and collaboration. As the week progressed, we progressively narrowed down our focus, converging on a shared objective and developing concrete solutions by the end of the sprint.
We also applied the same iterative process to our intra-team collaboration during each workday. We diverged to perform individual ideation, converging to share our ideas and agree upon a direction through the use of dotmocracy. Having fostered a culture of divergent thinking, our team members felt free to express their design ideas and viewpoints. Through constructive dialogue and feedback, we converged on a shared understanding and refined our ideas towards a common goal.
By following this approach, we were able to harness the collective creativity and expertise of our team members, resulting in innovative and effective solutions that met our project objectives.
Design system (UI)
We developed a comprehensive design system that served as a crucial reference for both the interface design and the development tasks carried out by the Java team (fig. 5).
Our design system had an agile approach, which allowed us to update and improve it as we progressed through the project. This approach ensured that the system remained a dynamic entity that evolved with our needs, rather than a static set of rules that we blindly followed. This experience taught me the value of flexible and adaptable design systems, which I have since applied to all my work with similar projects.
Figure 5a. Our agile UI design system, showing color palette, typography, etc., along with a table organizing our active Figma component library.
Figure 5b. Our agile UI design system, gathering composite components made up of smaller components for easy access and editing.
Accessible map design
Following an exploration phase, we identified the potential of utilizing the Google Maps API for our app's map feature. To investigate further, I was tasked with leading a two-person team to determine the feasibility of customizing the map's color scheme. After conducting comprehensive research, I confirmed that customization was indeed possible.
Working as a sub-team, we carefully selected a color scheme that not only looked aesthetically pleasing but also fulfilled all AAA requirements for the Web Content Accessibility Guidelines (WCAG) contrast standard (fig. 6). We then translated our design into a code format that we passed on to the development team for implementation.
This process enabled us to create a visually appealing map feature that met all accessibility requirements, thereby improving the overall user experience of the app.
Figure 6. The WCAG AAA-standard color scheme and customized map appearance we created for the Google Maps API, ensuring optimal accessability and ease of use.
Cross-functional collaboration
Our design team worked in close collaboration with the developer team to build the product. We facilitated cross-functional communication by sharing our prototypes and design components with the developers, allowing them to understand the requirements and dependencies of the design.
By engaging in this approach, we were able to identify potential issues and address them before development started. This proactive process helped to ensure a smooth development phase and reduced the likelihood of delays or complications.
Throughout the project, we maintained regular stand-up meetings with the developers to discuss progress, address any issues, and ensure that the project was on track. This open line of communication helped us to stay aligned and work towards shared goals effectively. Overall, our cross-functional collaboration approach enabled us to create a high-quality product that met user needs and exceeded expectations.
Usability testing
To ensure that we were designing the right thing for the right user every step of the way, we conducted usability testing on several stages: on the wireframe stage, on the design prototype stage, and on the final coded product.
Wireframe Stage
During the wireframe stage, we tested the basic layout and functionality of the product with a small group of users. The users were asked to perform specific tasks, and we observed how we interacted with the wireframes. Based on their feedback, we made necessary changes to the wireframes before moving onto the design prototype stage.
Design prototype stage
In the design prototype stage, we conducted more extensive usability testing, testing the visual design and user experience of the product. We used a larger group of users, representative of our target audience, and provided them with realistic scenarios to test. During these tests, we observed how the users interacted with the product and collected their feedback on its usability, design, and functionality. We used this feedback to make improvements to the design and functionality of the product.
Final coded product
When the final coded product was ready, we conducted one more round of usability testing to ensure that the product was ready for release. We used a focused group of trusted users, who tested the product on various devices and operating systems. We asked them to perform specific tasks while thinking aloud and provided them with realistic scenarios to test. We observed their behavior and collected their feedback on the product's usability, design, and functionality.
Insights and advancements
Through these usability tests, we gained valuable insights into how users interacted with the product and identified areas where we could improve the user experience. We used these insights to make necessary changes and advancements to the app’s design, functionality, and usability.
For example, we discovered that some users found the time setting difficult to use, so we improved the design by altering the method of entering time (fig. 8a-c). We also discovered that users had problems understanding the functionality of switching between the three suggested routes. We improved this by providing a simple button to make switching more intuitive (fig. 8c, bottom left corner).
Overall, the usability testing helped us create a product that met our users' needs and provided them with an optimal user experience.
Figure 8a. Previous method of specifying the length of the walk, in the style of a classic egg timer. Some users found this difficult to use.
Figure 8b. The egg timer interface unfolded half-way. This interaction was scrapped.
Figure 8c. New method of entering the length, using three possible methods for entry: (i) using the buttons; (ii) using finger to scroll the dial; or (iii) clicking into the dial and entering manually via number keyboard.
Beyond minimum viable product
During the course, we focused on developing a minimum viable product (MVP) to prove that our product worked and was the right one for our target users. This involved prioritizing the most basic features and functionalities that were necessary for the product's success. Through our collaborative efforts and efficient use of time, we were able to complete the MVP two weeks earlier than the deadline designated in the course.
With extra time on our hands, we were able to revisit the features that we had identified as "good to have" and implemented them in the second release of the app prototype. These additional features were chosen based on their potential to add value to the user experience. While there were still some "nice to have" features that remained on the waitlist, we were pleased to have been able to incorporate several new features that enhanced the overall functionality and usability of the product (fig. 10).
Throughout this process, we continued to prioritize the most valuable features for the user, ensuring that each new addition was carefully considered and thoroughly tested through the same rigorous usability testing process we used for the MVP. As a result, we were able to deliver a product that not only met the basic needs of our users but also exceeded their expectations by providing additional features that added value to their experience.
Figure 9. The important/diffuclt diagram helping us prioritize which user stories to address first. This diagram was completed by each member of each team during each sprint planning, and a composite was then assembled to guide us in our planning.
Key takeaways
The Break project was a transformative experience for me as a data-driven UX and service designer. It was one of the earliest projects during my education, and it laid the foundation for the rest of the collaborative work to come. I chose to showcase this project in my portfolio not only because of how much I learned from it, but also because it is one of the projects I am most satisfied with, looking back.
Through the Break project, I gained a deep understanding of Lean Startup methodologies, brainstorming in groups, democratic teamwork, and much more. I learned how to use scrum and agile UX workflows effectively to collaborate with a diverse group of designers and developers to successfully produce the final product.
One of the most significant lessons I learned during this project was that my ideas were not always the best ones. In fact, many times, we were voted down. This came as a shock to me, given that this was one of the earliest such collaborative projects during my education, and I had not yet learned the ropes of democratic collaboration. It was a humbling experience to realize that my ideas were not exceptional or better than anyone else's. Instead, the Break project was a true team effort, and I am proud of all of us for our contributions.
Looking back, I still draw upon the insights and practices that I gained during the Break project in my work today. I continue to strive for excellence in end-to-end design, solving real user problems, and collaborating with cross-functional teams to create solutions that meet the needs of users. All in all, the Break project was an exceptional learning experience, and I am excited to apply the lessons learned from it to future projects.
To sum up
This case study demonstrates the successful application of agile methodologies and user-centered design in a project. The team followed the Scrum methodology and the double diamond structure to develop a proof of concept (POC) of a service aimed at helping people who enjoy taking walks but were unable to do so during the pandemic.
The team followed a user-centered design process and applied Lean Startup methodologies to identify the target audience, validate their problem, and ideate a possible solution. The team fostered good communication and effective work through a letter of agreement that we referred to during each weekly retro. The project's learnings laid the foundation for all my following collaborations and continue to inform my work today.
