Timeline: Long-term project

Team: UX (Solange Molina), 3 people in BE, 3 people in FE, 1 QA, 1 FA, 1 Architect, 1 PO (11 people team) + Scrum Master

Role: UX/UI Designer, Interaction Designer

Tools: Sketch, Invision, Invision Studio, Abstract, Figma, Git/SourceTree, Jira, Confluence, Visual Studio Code

A little bit of history

ClevEHR started a couple of years ago. After almost two years of work heading against the rocks, with an obsolete framework with too much dependencies, a brilliant idea comes: Let's do it with React!

I can say that the first version was a kind of essay for this second part.  With a lot of lessons learned, and an exciting challenge at the corner, our team began to work deeply on this new adventure. 

To get a deep understanding of what are we doing is necessary to know where we come from?

It's not just about a second version but a web based application which one includes all the know-how acquired during the last 20 years by our stakeholder in Belgium, which one boils down to a standalone application with very complex flows, and a huge amount of nested popups to perform any kind of actions.

The challenge

Keeping the recent story in mind, and beyond the look & feel, there is a great opportunity to keep delivering the same flows with a modern perspective.

Current application EHR view

Methodology

Agile and deep diving into the components

As a consolidated squad team we are used to work with Agile methodology and be ledding by a Scrum manager.

React came like a light in the darkness, and altought almost none of us had the knowledge, we had to learn all about it. Thus, we started from scratch: No framework, no dependencies, and a lot to learn!

We started a full React course in Udemy. Each of us on its own rythm.  I got the essential and came back to Design stuff.

From the UX/UI side, the most interesting matter was the fact that React works with components and extends them. Therefore, we started to build a module called "Consultation", and the first setup includes to establish the basics. At this point, and talking about merely design, the ATOMIC concept made perfect sense: both, React and Sketch shares the component's philosphy. This was the spark to the Atomic path.

We all started a react course at Udemy. In this picture, some of my notes.

The process

First things first: wireframes, documentation & flows

As I mentioned before, we staterted working in Consultation module. The wireframes comes from Belgium via UXpin, and the most of the times, all of them can't be understood without an Ad-hoc documentation or explanation. However, in our meetings with the client we had the opportunity to clarify any kind of doubt about functionalities. 

Many times wireframes requieres a thorough review, they must be checked against the documentation and that is where some gaps appears, gaps among the interaction  that should be considered.

Together, UX, FA and PO, we had a bi-weekly product meeting to discuss about the next steps in the application and how to solve them. FE also is involved in this process when a new concept came from Design, to discuss about the feasibility before to show anything to our client.

On the other hand, we have another bi-weekly meeting with the client to explain the new features in which ones we've been working during the sprint. 

Wireframe of Module Consultation
The wireframe shown above display several elements related to this module. Indeed, this is a view of the Consultation Module called “Timeline”, where is displayed the data related to all the consultation for one patient. Consultation module isn’t just a consultation matter but a set of views & components commonly known as EHR. Going in deep, we can easy decompose step by step until to get the Atoms. The following diagram shows the full consultation module, with some highlighted sections such as Dashboard, EHR, HCE modal, Consultation, and Prescription. For further details about the study cases, please go to section “The Design Process

The Design Process

Case Study #1:

Working in organisms level in Patient Admin Card

As a team, our first goal was to develop the Patient Admin Card component.  To do so, in the UX, I started to define this organism since the atomic components, grouping and ungrouping them by nearness.

As shown in the image below, the Patient Admin Card is composed by several atoms described with different tones of grays, an some molecules. All together reveals the organism called Patient Admin Card.

Once detected the elements involved in this organism, I started to work by components in Sketch. Not just the organism but the different cases given by the length of some fields, by gender (to show default picture), the different parameters that indicates the type of insurance and so on.

Managing the library of components

The component managment is carry out mainly in Sketch as a standalone projects, but we also use another tools like Abstract, to collaborate and get a version control of the different componets.

Additionally we use Sketchcloud and DSM in Invision. Regarding DSM, see Deliverables section.

The following image shows an assortment set  of assets from Atoms to Templates.

This is a little selection of components grouped by atoms, molecules and organisms

UX Working model

There is a huge amount of different proposals taht sometimes covers just a single component or an entire view.

It could become crazy to  try to show all my stuff. However, there are some pieces that deserves to be shown and explained due to the maner on they were solved. 

Given that we work with agile methodology, we are used to work by tickets. The following example shows the journey to get the "final" mockup.

A user story to create a comment section

The requisites explained in a ticket
First flow to create, edit, and delete comments
Second flow to create, edit, and delete comments

Deliverables

Front end, be my friend!

Thanks to some tools like Invision, deliverables are more easy now! The  gap between Designers and Front End tends to be null.

Screenshot from one mockups in Invision
DSM, a live styleguide
DSM, also heps us to fill the gap

Documentation

Design Foundation is a must in every project

That's the reason I started to write a live document, which one is growing with the project.

Main view of SDF

The following image shows the grid system saved as a library, and the grid system we adopted to be responsive.

This piece belongs to Design Foundation document (more details in section "Documentation")

In the next image, the first column shows the template sent by our client. The second one, is the grid skeleton we agreed with FE, and the last one is an early mockup ofthe home page and the consultation list.

Early Responsive Template done in Sketch