Microsoft PAX wanted to build a Graphing feature for students grades 6-8 so they could better understand the fundamentals of Algebra and Trigonometry. The graphing feature had to enable students to experiment with vectors via sliding values, and allow them to render multiple equations at once. The graphing engine had to be able to support the Common Core Math requirements of Grade 8 and beyond
Our goals were to:

1.  Introduce Graphing to the Windows Calculator
2. Support Common Core 6-8 Curriculum
3. Research, Test, Spec in 9 Months

An early visual exploration.


We had to define an MVP experience to work towards. So we started with a list of "User Cans." These are statements that define a feature of the working product without describing specific UI elements. The example listed below is a later version of this document. It includes rank, release necessity (crawl, walk, run), and associated UI/code. These are not needed to start a User Can document, but should be integrated as planning becomes more precise.
The "Rank" and "Release" of a User Can determine how important it is that it be implemented in a certain amount of time. "Release" is a reflection of necessity and effort. User Cans that are ranked as "Crawl" are integral to the final product. Features ranked as "Run" are not necessary and often require more development resources to implement. After defining the most critical User Cans, the Key Scenarios can be flushed out.
Key user scenarios are stories that ground the User Cans in a specific journey. They are specific enough to illuminate the kind of interactions that will take place. Sometimes the specific element needed is mentioned. Other times it is best to omit the element and focus on the "function."

For instance, there's no UI element besides a graph which can be used in-place of a graph. What elements are needed to enable customization of that graph? This is open for debate, as we have to consider our target audiences, peripheral users, and those with accessibility needs. The Key Scenarios focus on the criteria for success and failure of a given scenario. This gives the designer more ways to consider their user journeys and design explorations.
The Process

After defining our scenarios, scope, and schedule, our next task was to begin laying out the user journeys and exploring the UI/UX that would drive our application. We started with the "mobile version" of our application. We wanted to start exploring solutions with as many constraints as possible.
User Journeys

The user journeys were invaluable to our process. We used them to refine UI, test solutions, and solve disagreements internally. Five to ten versions of a scenario can be laid out in the time it takes to develop a robust prototype. These time savings were critical to meeting deadlines and keeping design in-sync with development.

Explorations took place while and after user journeys were established. Explorations included UI, color, scale, interactions, typography, etc. Months were spent exploring the various components until a robust visual language was established.

Lab Mode Explorations - Windows Surface

Lab Mode Explorations - Figma


Every interaction that could be performed by keyboard, mouse, or gesture had to be possible via keyboard-only input. I dismissed my ideas if I was unable to find an accessible solution. Accessibility challenged me to think of my UI's organization on a fundamental level. Everything from how a cursor would be activated via keyboard, to the layer order of the keypads was considered.
Final Product

The final version of our graphing calculator is a significant improvement upon what previously existed. It allows for users to interact with equations in a way that was never before possible via Microsoft software. The open source solution is available Q3 of 2019.
Back to Top