— PROJECT NAME

einsOS

— ROLE

UX Designer

(UI+UX+Research+Testing)

— DATE

Oct '18 to Apr '19

einsOS was the 1st iteration (2nd iteration is Kneura) of an extremely agile project, done to create a digital platform that provides everything related to education.

einsOS comes bundled with multiple applications to teach using digital whiteboard, take attendance, give assessment, get curated content, get performance reports, grading etc.

CNX hardwares (Galileo) runs einsOS app as a digital whiteboard and einsOS also gives device performance and usage tracking for the said hardwares.

einsOS was a part of eins.ai family and its primary motive was to drive the sales of Galileo hardware which is an interactive display device.

einsOS website

To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. All information in this case study is my own and does not necessarily reflect the views of Cybernetyx.

My Role

einsOS initially started as a device performance tracking analytics software, and from there it grew to einsAdvisor, einsAssessment, einsLibrary, einsManage, and einsClass.

I was responsible for laying down the developer hand-off practices, design thinking exercises, information architectures, feature discovery, researching competitions & features , usability tests, and building the user interfaces.

I worked very closely with the AVP Design (My Manager) Tarun Pratap, and MD (Product Owner) Nishant Rajawat during the whole lifecycle of the product.

einsOS was a huge collaborative effort and it would have been very difficult if not for Prasad (Associate Product Manager), Noella (Senior Designer – Visual Communications), and Tarun (AVP Design) helping me out.

Branding, website design, and product hardware design attributed to Noella and Tarun.

Learnings

My biggest mistake was not being in touch with the actual product. The lack of collaboration and communication led to some incorrect behaviours and many loose-ends.

The global content navigation/hierarchy was fragile from the start and we were building over that weakness. Like the einsOS apps were on the top level and inside them, you have these option to select the class (+subjects). Having all these einsOS apps as buckets in classes (+subjects) would have resulted in better navigations and we achieved this in the next iteration of einsOS, that is Kneura.

Initially, there was no final vision of what we wanted to achieve, and every app was designed individually, but later they came together to make einsOS. Because of this agile approach there were brand inconsistencies in between the einsOS application, which led to design debts. A design system would have solved it.

Audience

Teachers

Through Galileo ONE (einsClass), teachers can teach geometry, painting, or write seamlessly. They can, with einsOS, create lesson plans, manage attendance and assess assignments.

Admins

einsOS come with with grading and reporting features, one can also track the utilization of installed devices in classes and monitor the progress made.

Students

With Galileo ONE (einsClass), students can collaborate on a panel in real-time, participate in group activities and make presentations. Students can connect their personal learning devices and contribute to class discussions from their seats. They can also attend classes and give tests remotely when they’re sick.

Design Thinking exercises were led by me and the participants included Prasad (Associate Product Manager), Geet (Product Tech Manager), Digraj (Project Manager), and Tarun (AVP Design).

Side Note: Diverging (then converging) to uncharted territories can be stressful for some.

The DT exercises were not only done for generating insights on what we had to do, but also to give us all a reference to work with.

We referred to “Harish” the teacher and “Rohit” the student personas during everyday discussions, which bought clarity regarding the stories we were trying to solve, and helped us all (Dev+Design+PM) empathize with the users and do the due diligence required to make our personas feel comfortable using our product.

einsOS Dashboard

All einsOS apps have their own specific role. Class is a digital whiteboard for teaching, Academy provides curated content to make lessons, Analytics shows device usage & generated performance report for classes, Connect is for chat & PTM meetings, Assess is related to creation and submission of assessments and Manage is for taking teacher's and student attendance & to manage the user IDs of people involved in the institutes einsOS.

After login each role land on the same dashboard but apps changes to do the things that that role requires, like for student Assess is for submission and Manage, Analytics, Class are not shown.

Brand icons attributed to Noella and Tarun.

einsOS onboarding and institute creation attributed to Tarun & Noella

Onboarding or the overall dashboard concept works fine for a closed platform but the number of onboarding steps, although with skip option, are too long and the actual functioning or stories are not visible until you open some app.

I revisited this issue in next iteration, in Kneura which is free for signup, we reduced the onboarding process to a single step and all the imports and creation part were packaged in their own modules. This made the users invest in the app first and when required, they had the option to create content/people.

The bucket functionality integration @me

einsClass SignIn screen Facelift @me

The einsClass dashboard final facelift @me

One important reason for 1st iteration being 'not successful' was the design architecture. This app on whole was made with accretion, all of that made it bulky and we were unable to handle more module integration like assessment, attendance, content directly in the einsClass application.

Other issues were related to pagination, for years my colleagues were used to the pagination where the CTA buttons were addition & deletion and navigation was through selecting & scrolling in the middle area.

Both of these concerns were foundation for the next iteration (Kneura) and the whole architecture was build to make this work.

einsAnalytics

This is where I came in, I was hired to help architect a solution for showing analytics related to the CNX devices.

It was important for the potential clients (Indian Government) to know how their ordered devices were being used by teachers and the whole institute alike.

The questions were: how the devices were being used? how much were the the teachers using the whiteboard solution (einsClass) we give with the CNX hardware? What other apps were they using? were they even using the hardware? if yes then who all were those that were using it effectively and by how much?

I was given a requirement doc, the proposal from the Indian government- EOI Doc and these were the insights that I received by consuming it:

They looked better on a large canvas, as u can see the relations clearly. We lost it as I never took that photo. I am still unsure how to save these large sticky maps, one way is using some digital tools like Miro but physical feels more like an exercise compared to the digital counterparts.

Once the proposed solution for the above EOI doc was done, and other einsOS apps were getting in the picture, we scaled the analytics part to assessments/performance, attendance, and behaviour analysis.

For the student performance related analytics, I did research on what all insights/graphs to show and how to showcase the data such that it makes sense to the educators and help them improve the performance for each student in their classroom. The study I referred to is the IES Published practice guide – Using achievement data to support instructional decision making, I have highlighted all the important insights in this PDF, if you want to have a quick look.

Following is the Admin's Analytics App, it has 2 views, one is Device view that was the original 1st iteration of this app, and the 2nd view is classroom view, that was later added as other einsOS apps came into the picture.

Designing details: using colors, shadows to show focused, active, and inactive fields.

Few concerns I received due to the colors used, they were too cold, and our marketing was expecting something more peppy. This App was designed to be like a dashboard which was visible on a large screen, and anything attracting attention was equal to something not getting that attention. But in later iteration (Kneura) I was able to achieve a balance between marketable and usable.

The number of breadcrumbs / filters for locations are too many in numbers, and are responsible for a huge cognitive load, but they were the part of the requirement I received. I created zone filters as a workaround that requires an initial overhead to create, but they made the whole flow much better in the long run.

The filters / breadcrumbs were part of the most important route in the whole app. To access more detailed data you had to go through them. I tested all parts of this red route through paper prototyping before handing it off for dev.

einsLibrary

Curated content was one of the most used term in our sales pitch, and through einsLibrary we were trying to create a content catalog for each topic, subject, standard, and boards using web crawlers.

einsLibrary was a content bucket for educators, providing them with videos, pictures or text to prepare their own lessons more effectively.

It was work in progress when I came. When I joined I revamped the whole app other than the core navigation (this is where that class+subject inside each app roots from)

Illustration attributed to @noella

Digvijay Singh Shekhawat, Work & Profile