My Process
> iOS and Android B2C Case Study
Mind Games
Table of
Design Problem Statement
This case study covers my work as the UX Director and owner of NiiD Technologies on a project for Mindware Consulting, a small company that had created a brain training app called Mind Games. The Android version of the app required a redesign, while the iOS version redesign was being managed concurrently. The client wanted us to take over management of the application and execute a redesign of the front-end.

Mind Games was a success before the client had approached us, with 8 million daily users. The only competitor at the time was Lumosity. The client wanted us to take over management of the application overall, and execute a redesign of the front end.
Design Impact on Product
My team's UX research work provided an understanding of users from perspectives such as personas and customer journeys. As a result of our UX design work, users reported a higher NPS (net promoter score) by 0.5/7, and the Google App Store average rating consistently rose over the next six months. Our prototype also helped developers gain a clear understanding of the work required for the next iteration.
Back to Top
My Roles
  • UX Lead
  • UX Researcher
Working on a product of this scale had its own unique advantages and challenges. On one hand, there was no shortage of data and means to collect it, such as millions of users who could be surveyed, feedback in various app stores, and the ability to conduct A/B testing. On the other hand, challenges included maintaining the existing high score on every app store, managing the app's avid fan base who were vocal about design critiques, and working with a risk-averse client who wanted only small incremental changes. Additionally, the science behind neuropsychology and brain training limited our design options, requiring a high focus on UX and minimalism.
The biggest challenges associated with the app:
  • The existing app had a high score on every app store (usually around 4.3/5). This would have to be maintained or increased to show the impact of our work.
  • There was an avid fan base that would play daily and notice even very small changes in the app. They would provide their own design critiques and would be very vocal. These opinions would not always be consistent with the scientific & ethical point of view that the client was trying to maintain in the app. This would have to be balanced as both perspectives are important.
  • The purpose of the app was to train the brain as a muscle through various "games" (in reality, exercises). These games had to be highly repetitive in nature in order to be successful (based on the scientific expertise of our client).
  • Dr. Cole was a risk-averse client who didn't want to make large changes at once because he did not want to take the chance of alienating the user base. Instead, the client wanted to make very small incremental changes. This was a challenge because it slowed progress and efficiency. The client had to be convinced via a data-informed UX strategy that our approach would not harm the app.
  • The science of neuropsychology and specifically brain training limited many of the options and ideas we could present. Even though this made our work harder, I did not object because I felt it was ethically correct and in the user's best interest. From a PR standpoint, however, this was also a challenge, as users wondered why we did not have a much more visually appealing app. Mind Games' competitor, Lumosity, had a much freer design philosophy, but we did not believe it had as much scientific validity (reduced transference) because of the degree of distracting graphics and animations. For the brain training in the app to carry over into real life, the app had to be exceedingly simple and not visually appealing. The brain had to focus on a single input at a time. Therefore, it required a very high focus on UX and minimalism.
  • Because of the science behind brain training, the games could be visually appealing as long as they did not distract the user. The user had to focus on the specific game that was being played. There were 36 exercises while we were doing the app redesign.
Project Management Plan
Our initial steps included recruiting core team members and applying an Agile model. We also applied collective knowledge and Systems Thinking strategy to determine project needs and questions, created a team communication structure, defined clear roles and responsibilities for the leadership team, created an initial risk management plan, and created initial tentative timelines and sprint plans.
Initial UX Project Steps
  • Recruit core team members off the bench, such as a development team lead, database team lead, QA lead, visual design team lead, and a senior BA. I had a dual function as the UX team lead/UX strategist and as the overall Product Manager.
  • Apply Agile model to UX process, observing sprint ceremonies.
  • Apply collective knowledge and Systems Thinking strategy to determine what the project needs and what are the questions that we want to ask.
  • Create team communication structure to be flat initially and scalable in the long term.
  • Create clear roles and responsibilities for leadership team
  • Create initial risk management plan
  • Create initial tentative timelines and tentative sprint plans
Design Strategy
  1. Hypothesize Problem Statement
  2. Secondary & Competitor Research
  3. Conduct Social Surveys
  4. Conduct Usability Interviews
  5. Refine Problem Statement based on data
  6. Usability Testing of existing application
  7. Document Current Information Architecture (IA)
  8. Define Critical Flow
  9. Create User Persona
  10. Create Journey Map
  11. Heuristic Evaluation
  12. Heuristic Frequency Breakdown
  13. Lessons learned, including pain points and opportunities
  14. Document future IA
  15. Create paper prototypes with cutouts
  16. Usability Test paper prototypes
  17. Create Mid-high fidelity prototype
  18. Usability Test prototype
  19. UX Specifications Document/Style Guide
  20. Handover to Development team
  21. Hypothesize opportunities for future iterations
Back to Top
UXR Sprint Strategy
This is the UX research strategy that I typically used for individual studies. It combines both Agile and UX research methodologies. Click the image to zoom in.
Back to Top
To understand the application, our first step was to assess any existing User Experience (UX) Research. This included A/B comparative studies, personas, Journey Mapping, heat mapping, and SEO data from Google Analytics. We utilized the existing Google Analytics data to determine the sites where users spent the most time and the bounce rate. We also created the first User Persona and Journey Map for that user, while recommending expanding the User Persona types and using tools such as UserTesting and UserZoom for future UX research iterations to create a more resilient design.

Next, we examined the existing presentation and structure of the application by diagramming the overall flow chart to show the various paths the user might take. As the scope of the current application only involved one user type, the player of the game, we created a persona for that user and did not consider an admin user as it would be too much overhead to manage 8 million users by a single administrator.
Overall App Flow
Back to Top
Identify App Happy Path
Identifying the Happy Path was the goal of the basic process flow, which involved taking the user through the most essential steps in the app required for accomplishing their needs and goals. This process also laid the groundwork for the Journey Map, which will be encountered later in the case study.

The basic process flow also lays the groundwork for the Journey Map, which will be encountered later in the case study.
Back to Top
We created a User Persona based on user interviews and insights from quantitative data. This allowed us to triangulate/affinity map off that data, and create a persona for Jimmy, a retired construction manager recently diagnosed with Alzheimer's. Although Jimmy is interested in keeping away the symptoms, he is not comfortable with smartphones or new technology in general, and using the app was not his decision, making him a reluctant user.
About Jimmy
Jimmy is a retired construction manager. Recently diagnosed with Alzheimer’s, his children gave Jimmy the Mind Games app to help him fight it. Although Jimmy is interested in keeping away the symptoms, he does not want some “new gimmick.”
Known Challenges
  • Not comfortable with smartphones or new technology in general
  • Using the app was not his decision so Jimmy is a reluctant user.
Pain Points
  • He can feel his mental faculties slip away as names faces and objects become harder to remember
  • Feels a loss of control in daily activities
  • Emotions are difficult to overcome
Application Feature Opportunities
  • Help Jimmy regain his self confidence
  • Possibly fight the spread of Alzheimer’s by using brain training games
  • Show his children his progress and how he has been using the app
Back to Top
The Journey Map phase involves demonstrating an iteration of the application redesign based on user research and testing. The purpose of the Journey Map is to document and understand how Jimmy goes through the app based on the current process flow. We strive to meet his needs by empathizing with his emotions and actions as he navigates the app.

To read the Journey Map, steps are listed at the top and emotions, actions, and key points are shown. Red text indicates pain points and areas for improvement in the next iteration of the design. The amount of red text reflects the amount of work that needs to be done.
Current Journey Map Overview
  • The Journey Map covers the points mentioned in the basic process flow, so in turn, this is a simple Journey Map. This leaves open for more comprehensive Journey Maps for more complex process flows in future iterations.
  • Red text throughout the Journey Map indicated problems and/or pain points. The amount of red text indicates the amount of work that needs to be done in this coming iteration of the design revision. It also indicates Jimmy's pain and frustration as he goes through the app. The idea is to get other participants of the project to understand and empathize with Jimmy, so that we, as User Experience Designers, can be user advocates. The next phase, the Heuristics Inspection, will further indicate more work that will need to be completed. Both the Journey Map and Heuristics Inspection are intended to scope out the work and then prioritize the pending tasks.
  • Based on the red text, in some cases, the actions will be changed. We changed the flow, design, and overall user experience to reduce the pain points.
Back to Top
The purpose of the Heuristics Evaluation is to apply a logical approach with UX design factors to identify errors and points of change. We used a 9-point heuristic analysis common in the industry (taken and slightly modified from the Nielsen Norman Group) and applicable to the design. The factors considered throughout the case study are:
  1. Users & Their Goals
  2. Flexibility & Efficiency
  3. Recognition Rather Than Recall
  4. Error Prevention
  5. Help Users Recover From Errors
  6. User Control and Freedom
  7. Visibility of System Status
  8. Consistency & Standards
  9. Help & Documentation
Heuristics Evaluation
This is the first screen that users encounter in the Mind Games App (after the splash screen), but it is confusing users with its lack of information hierarchy, unnecessary buttons, and many other buttons. As part of the Heuristics Inspection, we tackle this screen first as it is arguably the most important in the app and the first one encountered by users (aside from the Splash screen). The heuristics factors examined are mentioned on the right in bold and numbered. The numbers are noted on the page to mark where the errors occurred. For more details about the error, the table can be checked, and the reasoning is given.
Main Menu Page
Games List Page
The Games List screen gives users another menu choice where they can pick a game to play. The purpose of this screen is to help users make a choice by showing information in brief, via icons and text.
This screen displays what one of the games, Attention Training, looks like while playing.
Game Reports
The purpose of the game reports screen is to display the score history of users. It is confusing to users because it also displays instructions for how to play the game, which should be separate. As a screen that gives progress reports, it should provide information clearly and concisely.
The purpose is of this table is to count and show the number of errors encountered in total, across each of the screens encountered in the case study, and order them according to their frequency. The severity of the errors can be determined and prioritized. As a majority of the errors encountered are usually in the top 2 or 3 heuristics factors, those are the ones we will focus on learning from and fixing in this iteration of the design.
Usability Testing
During this phase, extensive usability testing was conducted to confirm the personas, heuristic evaluation, and journey maps. This testing helped us gain insights into the user experience and identify any areas that needed improvement.

While the specific details of this testing are not available for this case study, it is important to note that user feedback and testing should be an ongoing process throughout the design and development of any application. This allows for continuous improvement and ensures that the final product meets the needs and expectations of its users. For further details regarding my evaluative testing process, please see the UX Research Artifacts page and the User Research playbook (most recent example).
Back to Top
Although the Mind Games app had 6-8 million daily users and was the second-most popular brain training game across all mobile app platforms, there were still many points of improvement that were identified through the Journey Map and the Heuristic Inspection. Good design is always iterative, and we used our experience in mobile app design, along with the data presented in this case study, to inform our decisions and recommendations for improvement.

As mentioned earlier, I focused the team's attention on three heuristics: flexibility and efficiency, recognition rather than recall, and help and documentation. I developed a design strategy that focused on maximizing user control and freedom through dropdown menus, reducing the need for recall and increasing flexibility and efficiency. We also focused on creating a cleaner design that would help reduce information overload, improving recognition rather than recall and flexibility and efficiency.

It is important to note that the conclusions drawn from this case study are specific to the needs and challenges of Jimmy Walker, the persona we created for this project. The recommendations and design strategies developed in this case study may not be appropriate for all users and applications. In ethnographic/anthropological terms, the research done here was a thin description. According to the Heuristics Frequency Breakdown table given above, there are three heuristics that we focused our attention on because they were of high severity and there was a great deal of feasibility in fixing the errors. The factors (as mentioned in the section above) were:
  • An interactive gameplay wizard where Jimmy has to tap the screen in the right places, which will be guided as much as possible for error prevention and to help Jimmy feel in control.
  • Concerning control, although User Control & Freedom is not mentioned as one of the top factors in the above breakdown, we will counter-intuitively focus on this factor to target the other two factors ("flexibility & efficiency" & "recognition rather than recall") as a type of "rebound" strategy. What we intend to do is create a design where user control and freedom is maximized through dropdown menus so that the need for the recall is reduced, and flexibility & efficiency is increased.
  • A cleaner design will help both the "recognition rather than recall" and "flexibility & efficiency" heuristics because there will be less chaos on the screen, leading to less information overload.
If you take a look at the other case study mentioned in this portfolio (the Chess Tournament Management w/ CMS case study), you will notice that the heuristics frequency table mentions the same errors. However, the conclusions drawn as a result of these errors are different. This is because the User Persona is different for each of the apps. In this case, we are focusing on the troubles of Jimmy Walker, who (as mentioned in the User Persona) is an Alzheimer's patient. Because of this, rather than reducing the need for Help & Documentation by focusing on architecture (as was diagnosed as the solution in that case study), we are going to take a slow and patient approach to the app and really help Jimmy as much as we can. This means:
  • Flexibility & Efficiency
  • Recognition Rather Than Recall
  • Help & Documentation
Research Analysis
Back to Top
New Happy Path
This is the revised Basic Process flow, given the Lessons Learned section (the section directly above).
  • Help reduce Jimmy's pain points and target his user needs.
  • Take Jimmy from point A to Z in the app
  • Accomplish the simplest but most important task
Research Validitation
  • Usability Interviews showed that Jimmy is not a new user and doesn't have to sign up or login again.
  • There is a new guided tutorial mode that has been added to the Future Process Flow. It can be turned on & off. It is assumed for this process flow that Jimmy has it turned on.
Back to Top
UX Specifications Documentation/Style Guide
The handover of the design process to other elements of the business begins with this document. The UX Specifications Document is supposed to thoroughly examine all elements of the UX Design from a developer context. The purpose of this is to have a reference guide for developers to refer to. It also creates better communication and shows all the different elements involved in the design in one place. The difference between a Style Guide (more commonly used) and UX Specifications document is that this document shows interactions, with elements such icons, text inputs and buttons showing states such "active" and "disabled."
What Did We Do?
We accomplished the following in the process of creating the UX Specification Document. Examples of the interactions are shown with the fingertap icon (the large grey icon in the image below):
  • Showed the dropdown menus, which we hypothesize based on this case study will improve the way that users will go through the app (needs to be confirmed with user testing).
  • Show the transitions between the screens and the logic behind them, so that developers can have an easier time coding them in and knowing where they belong. This will also help the creation of the Prototype (next step).
  • Showed Iconography, which is one of the steps that we took to clean up the app and make it more intuitive. Iconography can be a kind of visual shorthand on buttons to lesson user recall and working memory load.
Back to Top
What Is It?
We created a mid-fidelity Invision prototype. A prototype is clickable used for: 
  • End Users for User Testing. More complex testing is available for User testing at higher fidelity levels. This prototype is mid-level so many of the links not covered in the case study are not clickable. Additionally, the game cannot be played but the interactions within the game are shown.
  • Designers to collaborate regarding designs, on the cloud, and (in the case Invision and some other prototype tools) simultaneously.
  • Helps developers to understand the functionality and capabilities of the app to create the logic to make the design usable.
What Did We Do?
  • Uploaded screens that we created via Sketch to Invision
  • Uploaded dropdowns for each screen
  • Created hotspots so that screens would be interactive
  • Created layered screens in Invision
Impact Summary
  • Ability to have a hands on view of the app and functionality
  • Simple user testing capabilities without investing in a costly and time-consuming developer-created PoC.
  • Business users will understand how the app will generally function and get an idea of the look and feel of the app.
Back to Top
Next Iterations
This section is written from the perspective of what I might do present day, if I had the project today.
Future UX Research
  • Card sorts could be conducted to improve the IA. Whatever results would be given from these could be confirmed with a Tree Tests. I would normally do these in Optimal Workshop.
  • Growing Minds monetized the application via advertising on the free application. The free application was also the source of most of the income from the product. Therefore, user research should be done to evaluate how to improve the UX with respect to advertising and how to leverage UX to improve advertising revenues.
  • The IA & general functions of the application could be added to. Additional features could be determined by a UX research study surveying the existing users.
  • Additional personas could be added, with associated journey maps for those personas.
Future Design
  • A design system could be created (typically I use Google Material UI unless I am working on iOS) that would allow for multiple designers to work on the application with consistency.
  • A strategic focus could be added to the additional (existing) website component of Growing Minds. This could be designed to be consistent with the mobile app iteration described here.
Back to Top