Affinity Map

Following the observational study, I created an affinity map with the data. I found 4 key themes:

While I was able to understand these as key aspects that created the need for the solution, I was limited in understanding insights from customers and users of the app in relation to this solution as I was unable to observe interactions between the team and their customers.

Problem Statement

I defined the problem as how might we support Rhymes with Reason’s admin team in generating multivariate and longitudinal data visualizations for data that has been compiled.

This pinpointed the ultimate goal of the project as data visualization, rather than simply automating their process for data compilation.

Personas

I considered three personas for this project: (1) the Rhymes with Reason admin team user, (2) the Rhymes with Reason customer user and (3) the Rhymes with Reason app school user.

Summary of Design Stage

During the Define stage, I defined the problem I needed to solve for with the use of the following elements:

• An affinity map with the key themes from the observation study: automation, decentralization, analytics and business model
• I selected a HWM question focused on allowing the Rhymes with Reason team to generate multivariable and longitudinal data visualizations once data had been compiled
• I also generated 3 personas, but was mainly only able to focus on the user who was using the solution in order to manipulate data and gain insights

Storyboard

I next developed a storyboard that illustrated how the solution would be able to generate visualization of current progress for each customer once this data has been compiled and imported into the system.

Feature Roadmap

I used both analogous inspiration and creative constraints in order to help me brainstorm solutions to the problem I outlined. Initially, the founder and I prioritized the following features as must haves.

Later down the line, the following features were included in the design because they were instrumental to the information architecture. I also was able to explain to the founder how creating a report builder for this solution is a secondary feature that could be deprioritized until the primary solution was developed.

Site Map

Initially the site map for the dashboard was built around the jobs to be done, these being the task of generating data visualizations (e.g. data trends) and managing data files. I incorporated the partnership profiles sections initially simply so that the visualization could be linked to the corresponding customers. My thinking was that these tasks would occur largely in isolation of the customer page.

User Flows and Task Flows

I also based the user journey around these tasks: (1) a user uploading data, (2) a user creating a data visualization, (3) a user filter the view of data visualizations and 4) a user navigating to a partner profile to view these data visualizations.

Dashboard Home Design

For the design of the dashboard home, I took a lot of inspiration from the designs I reviewed during the competitive analysis. I initially sketched a secondary navigation and breadcrumbs, but went without these in my mid-fidelity wireframes since they were redundant to the primary navigation that already existed within the portal where this dashboard would exist. In the mid-fidelity designs, I added filter drop downs so that this page could be customized to the user’s needs along with labels and icons to more clearly spell out how users could manage each individual card holding a data visualization. I also added pagination at the bottom to also consider how many data visualizations users would see at once versus how much they would have to click next to view more.

Although this wasn’t a key screen I sketched, a major component of designing the prototype was designing the flow users would take to add a new data visualization. For this, I studied the way this process occurs on Google Sheets where users input data into the cells, highlight the cells and add a chart. From there users, edit the chart’s settings using a chart editor. I attempted to translate this into a flow with screens with modal that broke up the process into each of the four following steps: 1) import data from file, 2) select data points, 3) indicate inputs and outputs and 4) link and publish charts.

Data Files Screen Design

I also incorporated a screen that would allow users to manage the files with the data. At this point, I thought that it made sense for these to exist near the screen on which users were creating data visualizations so I created a tab for each of these tasks. As I moved on to the mid-fidelity screen, I again created filters and pagination for users to be able to view relevant files when needed. I also clarified the information that users would need to see per file and the actions users could take on individual files. My competitive research did not really showcase screens that contained lists of files or what it would look like to upload files so I took to Dribbble for inspiration on how what to include and how to design the flow.

Partner Profile Design

For the partner profile page, I moved the partner details to the left in the mid-fidelity design. I Also clarified the different screens users could navigate to as notes, todo list, calendar and activity record, allowing users to publish updates like Facebook. I also incorporated a feed for users to view these updates chronologically and filters to be able to narrow them down when needed as well. My competitive research did not really examine SaaS companies like Github and Salesforce so I researched these for inspiration. I incorporated patterns like the user photo on the left, the tabs to organize the different feeds.

Component Design

For the design of the components, I applied best practices. I applied the styles from Rhymes with Reason’s branding guide later on after doing testing on the mid-fidelity wireframes. There weren’t a ton of rules in the branding guide so I iterated to make sure that the components were accessible while also maintaining the style of the company.

Usability Testing

I drafted a usability test plan and collaborated with the stakeholder to conducting testing with the key admin team members The subjects included the founder, the person in charge of evaluation and metrics, the operations manager, person in charge of customer success and one of the software engineers. Before finalizing the plan, I iterated on the questions to make sure they would actually generate usable feedback. The major priorities for testing were testing the four flows of uploading files, generating data visuals, filtering data visuals and navigating to a partners profile and understand users’ preference for different views of the files and different organizations of the site’s content.

Feedback Prioritization

Testing found no errors with the website in terms of flow all users were successfully able to complete the four tasks. Users did however have a lot of rich feedback about the information architecture, the individual task flows, preferences of specific views, the specific jobs to be done and additional features they would like to see.

Once I presented all the feedback to the stakeholder, we collaborated to organize the feedback into the most high priority items, the medium priority items and the non-priority items.

Priority Revisions

I focused the majority of my revisions on the high priority issue of revising information architecture. I moved the partner profiles list to the dashboard so that the actions of uploading files and adding data visualizations would happen on a partner’s page. This ended up simplifying some steps of the task flows since users no longer needed to link data visualizations or files to partners. I also added a section to this screen for aggregate analytics across partners as a tab.

This also meant that the partner profiles needed revisions as well. I changed the tabs to hold the screens for activities, analytics and documents. I also removed the text field and instead left the button which would trigger the text field when pressed. This way, I left more of the screen for the activities and created coherence between the activity screen, the analytics screen and the documents screen.

Summary of the Design Stage

During the Design stage, I designed and tested the website making important considerations about the following elements as I increased the fidelity of my designs:

• I created a storyboard in order to put the persona in the context of the solution I was designing
• I created a feature roadmap that prioritized features that accomplished the most important jobs to be done: uploading files, creating data visualizations, filtering data visualization and navigating to partner profiles
• I designed a site map encompassing sections for the analytics, documents and partner profiles
• I designed user flows focused primarily on uploading data files, adding/filtering data visualizations, and navigating to a partner profile
• I designed a dashboard screen and partner profile screen focusing on clarifying the specific actions needed to be able to take on each screen as I increased fidelity
• I created component using best practices
• I tested a prototype to understand whether users could accomplish the 4 tasks that encompassed the jobs to be done and understand their preferences for the flows, and overall design/IA
• Post-testing, I revised the information architecture to make the feature partner profile first, allowing users to complete the other actions from within these profiles