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.
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.
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.
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.
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.
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
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.
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.
The following image shows the grid system saved as a library, and the grid system we adopted to be responsive.
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.