Raxa EMR UI and UX

Owned by Surajit Nundy
Last updated: Feb 25, 2014 by Karan Singh (Unlicensed)

Design Principles

Lead UI/UX Coordinator: Susan Wolfe

It's great that we have so many people enthusiastic about working on the UI/UX for the various modules.  As we are all discovering, it's a bit challenging to know how best to work together to get everything done as appropriately, and as quickly as possible - particularly given that we're literally working around the globe and we're all extremely busy outside of this project.  Furthermore, as a client of mine used to say, 'we're trying to build the bicycle as we're riding it' - meaning that our standards have to emerge as we're doing the designs, rather than all working off of a fully established set of guidelines.

Having said that, we do have a number of number of principles that we are working to, that will help us:

  1. Our overall channel strategy related to the design is 'mobile first' - meaning that we start by optimizing the design for the mobile platform and then think about what that might mean for the browser based platform.
  2. We want to leverage the existing widgets from the Sencha Touch and Ext JS4 wherever possible.  Obviously, there may be situations where we need to 'improve' upon what's there, but that should be the exception, rather than the rule
  3. We need to identify common behaviors wherever appropriate.  There's a spreadsheet that is currently sitting at the top level UX/UI folder in drop box that has elements that need to be standardized.  (There will be others that need to be standardized, as well.).  Could you please make sure that you add anything to that list that you think is important, based on the functionality you are currently grappling with.  Also, could you please take a few minutes and provide any feedback on the solution that you are currently proposing with regard to each of these elements.  That way, we can figure out how much variability there is in our current thinking and figure out how to make it as consistent as possible.  The easiest way would be to just go into that spreadsheet and add your comments.  However, if you prefer to simply send me an email, that is fine, too.

Finally, you'll notice that there's a folder in dropbox called 'Latest Items'.  If you could please put the latest screens that you're working on (assuming that you're at a point where you're soliciting feedback), that would be great.  Also, as you add new stuff (over time), please get rid of your previous stuff if it's no longer your latest items from your module.

(Introduction taken from A few UI/UX housekeeping issues..., a blog post by Susan)

 

Creating Wireframes

We believe that we finally have the right approach/division of labor to make progress on both the user interface/interaction design as well as the visual look and feel.  We’re just about to kick off a process for determining what the brand feel should be for the overall Raxa application (in both the touch world and the PC world), and we will then develop the visual design conventions to make the modules have a common look to them.  That process is happening in parallel with the work that most of you are doing to create wireframes for the various modules. 

Generating those wireframes is the most critical part of the UI/UX design process, because it’s how we can make sure that we have the right functionality, the right workflow, and the right terminology to make the various aspects of the Raxa system appropriate and usable for the users.  Apart from documenting the design, these wireframes are also critical for Daniel (and others) to be able to get feedback from the audience.  It’s necessary to get that right before we worry about the look of the buttons, colors on the screens, fonts used, etc. 

What this means is that, until your wireframes are ‘signed off’, no one on your team should worry about the visual design.  Wireframes are intentionally devoid of color and graphics, so people can focus on the getting the functionality and flow right first.  (Having said that, you obviously need to be concerned that you’re not designing something that won’t fit on the screen, but you would probably have a good sense of that already.)  The wireframes should be very easy to iterate on the design, as we get increasing amounts of feedback.  The jury is still out on exactly who will be responsible for ultimately applying the visual design, once it has been signed off.  Ideally, each module will have one person who is more technically savvy with the tools, who will be responsible for applying the visual design (in accordance to the standards being developed), once the wireframes have been signed off.   This  will make it a lot easier to instil the sense of visual consistency across the module – and the rules will help make it so, across all of the modules).   

Furthermore, ideally we would all be using the same tools to develop those wireframes.   However, given that we’re a volunteer army and that we all have people different software, and different experience with software, we’re probably not able to mandate a single tool.  What’s most important is that the tool you use is sharable with others on your team so that you can share and eventually stitch everything together.   At worst case,  as long as the wireframe can be converted to a pdf, we’ll be able to do that.  Regardless, what we do know is that you should not spend your time/energy doing things that add minimal value to the process, such as creating them in Photoshop.  Instead, you should be focusing your effort on however you can most easily generate wireframes in a sharable manner with the rest of your team.

Information Architecture

Document in progress.

 

Project Breakdown (User roles, modules)

The user roles for the software are as follows:

  1. Registrar
  2. Nurse
  3. Doctor
  4. Lab Technician
  5. Lab Manager
  6. Pharmacist
  7. Billing

Of the above roles the nurse and doctor roles are the most complex.  Both nurses and doctors will require access to all the modules from registration all the way to billing.  Hence the IA an UI/UX for these roles will be the most challenging.  The remaining roles need more granular access to the modules specific only to their roles, for example the registrar will only require access to the registration module.  

From a high level the modules we will need to design: 

  1. Registration
  2. Screening
  3. Outpatient
  4. Lab
  5. Pharmacy
  6. Billing
  7. Emergency (as of now undefined ... possible future work )Â