top of page


problem space

Translating functionality from an existing web application into the mobile context (i-pad). This project entailed close collaboration with the client representing marketing, business and technology goals

our take

A scenario based approach thelped us think about user needs, goals and constraints  while developing wireframes


Emma, Carlie, Matthew, Arushi


This project was sponsored by RyeCatcher


RyeCatcher is an application that enables parents and student advocates to build and manage a “circle of support” tailored to a student’s individual needs. It also serves as a tool to connect students with local support providers, and facilitates tracking and monitoring student progress over time. It is used by teachers and other providers 

The client provided us with a list of requirements - a set of pages and functionality she wanted built for the mobile version. This included the feed, student pages, notes and trackers

snapshot of the whole process

Initial research with RyeCatcher user to understand usage, hurdles, on the go relevant actions

Familiarizing ourselves with the web app,

Creating site map

Current landscape

Fleshing requirements with current usage


Listing features to be included / excluded  in the mobile version.

3 distinct scenarios  to think about wireframes, covering all requirements

Sketches of wireframes with 2 goals:

- Keep it simple

- Translate data into meaningful information

Imagining what might be

Feedback and critique session with client - change in approach toward the application

Creation of wireframes for new scenarios, reflecting changed approach.

Evaluative research with RyeCatcher user

Synthesis of key findings and creation of opportunity matrix to prioritise our actionables 

Presentation and critique session with client 

Revision based on feedback

Annotated wireframes and information architecture for development team

Creating and testing


wireframe mockup of the i-pad app 

In this project, we followed a converge, diverge process for team and individual work: coming together for key decisions, then branching to work individually, then coming together to show our work and decide next steps

One of the pages that I worked on is shown below: the individual student landing page, that remarkably changed the existing page, making it less overwhelming and more actionable.



7 tabs reduced to a single page by -  

  • Changing layout

  • Bringing high level information above the fold

  • Removing functionality more apt for desktop

Reduced hierarchy for feed - a rarely viewed feature by users, and was very extensive 

Bringing plans to the front, and adding graphs that enable quick read of the progress

A look at the defining moments below

initial research gave guiding principles

Early in the research process we spoke to Steven Lam, a California public school teacher, who told us about his life as a teacher and how he used Ryecatcher.

What we heard: Teachers are extremely busy, with several activities beyond teaching in class. They think of time in 2 minute chunks


What we took away: Teachers need a way to quickly finish the task and get the information they are looking for 

What it meant for design:

1. Our design should ensure 3 click completion of most tasks,

2. Lean/stripped functionality -  Have only what is essential on screen, with an option to view and do everything

a scenario based approach

Early on, we decided as a team, to anchor our wireframe sketches to specific use cases that touched upon all the requirements . This would allow us to think about our user's needs and goal for accessing particular pages. We decided on specific tasks for each team member.


While another team member wrote the stories, I evaluated selected pages of the existing web application to see functionality and features that need to be included, added, excluded and lowered in hierarchy for the mobile version.

We then came together to share our individual work. Based on this shared understanding, we discussed which pages should we sketch to communicate our approach. We then broke off again to sketch independently. Few of my sketches below

client feedback
use data tracking to show what we are doing about the problem?" - Arthi

During feedback, we realised we had subconsciously regarded this tool as a way to identify and monitor the "problem child". Key takeaways from this session were

  1. Think of the tool as an “enablerfor the student. We providers are taking ownership for the student's success. We ask ourselves - what is being done and what can be done for this student. 

  2. Lean is good, but the current functionality expects teachers to come back and fill fields which they will not. 

  3. Help user prioritise, show them whats on fire / what they need to attend to

  4. Data analysis to show meaningful information was highly appreciated

change in approach

RyeCatcher is about relationships - establishing, growing, and repairing relationships
RyeCatcher is a tool used by teachers to identify and monitor students that make trouble
evaluative research

We created 2 new scenarios to reflect the understanding from the client feedback. We then proceeded to creation of wireframes for evaluative testing with RyeCatcher user

For evaluative research of the wireframes, we created a script that ran our user through the two new scenarios with the intention to get reactions on page organisation, new features and visual elements.

The first scenario started on the feed page and was workflow driven. We internalised Arthi’s feedback about teachers only having 2-minute chunks of time by developing a real-time
process f
or updating, editing and taking attendance for upcoming events. Our note removed / minimised the need to type, adding the ability to tap and smart search

The second scenario was focused on tracking a student’s progress through easy-to-view snapshots on the student page to drive a more informed story about the student’s growth. This was accomplished by changing the page layout and bringing all the high-level information above the fold, allowing the user to click-in if they want more in-depth information. Subtle changes like renaming "watch list" to starred students was done to encourage thinking differently about these students

findings and synthesis

We translated our learnings into an opportunity matrix 

5 key takeaways

to view the evaluative research presentation click here
final critique

After making changes to our wireframes based on the opportunity matrix, we had our final critique with 

To begin, we got a lot of comments on redundancies and consistency. Our wire- frames needed to be developed more cohesively so that they told a story as a system.
In addition, it was recommended that we remove all non-vital calls to action and icons that lead to pages that have not been built out.

This recommendation led to a more detail-focused review of each page’s features and questioning of how each fits into the larger system.

annotated wireframes and information architecture

Finally, we created annotated wireframes for the development team of RyeCatcher and updated the information architecture that had been evolving through our entire journey

to view all annotated wireframes click here
bottom of page