Raxa EMR UI and UX
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:
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.
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
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:
Registrar
Nurse
Doctor
Lab Technician
Lab Manager
Pharmacist
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:
Registration
Screening
Outpatient
Lab
Pharmacy
Billing
Emergency (as of now undefined ... possible future work )
Comments
Update on visual design standards
We're making great progress on defining a visual look for the various interfaces on the two platforms (special thanks to Hyeona and Yasmine for taking this forward with OPD and Registration, respectively).
As this work continues, there are four main things that we need to do to make sure that it all hangs together in the end:
Ensure that what's been designed so far for the specific modules is extensible to other modules on the same platform (hence, consider elements required beyond OPD and Registration)
Ensure that what what's been designed can readily achieved using the Sencha widgets (for common interactions – obviously, there will be a number of Raxa-specific widgets that we’ll need to create for things like the human body, etc!)
Ensure that what being designed is optimized for the particular platform (e.g., things that work well for a browser don’t necessarily work well for a touch interface, and vice versa), and highly readable, buttons big enough for touch, etc.
Ensure that, despite all of the intentional differences between the two platforms, they have a ‘family resemblance’ so that it is obvious that they are part of an overall solution for JSS (and for demonstration purposes beyond…); although it will be relatively rare, this also provides a consistent experience for anybody who does happen to use both platforms
There are also a few critical things that need to do at the overall project level to make sure that what we come up with is easily implemented:
Ensure that, before we get too far down the track, we get feedback from the target audience about the usability of the visual design solutions (given the context of use) and feedback about the ‘buildability’ (both from the process and any potential performance implications) from the development perspective
Ensure that that we still have a suitable approach for rolling out these standards to all of the modules (e.g., is it the UI designer’s responsibility, the developers’ responsibility, etc.)
More will be coming on this very shortly, but in the meantime, if you have any suggestions or comments - please do speak up!
Thanks,
Susan
About the common elements spreadsheet
There have been a number of questions, so I want to reinforce what we've said earlier. There are two tabs in that spreadsheet. The first is for the common components from the interface/interaction perspective (e.g., the fact that we need to standard patient identification information), or the fact that we have videos, or how we do error handling, or the use of pop-ups, etc. At that high level, we’re going to be looking for consistency so that the general behavior of the modules is as consistent as possible. Therefore, I’m asking that people look at the modules that they’re designing, and explain on a module by module basis, the components that they need. In that way, we can look to see where we need to come up with some of those behavior standards (in many cases, some of the interaction elements will be module-specific, so we don’t need to worry about consistency with other modules – however, there will be many that overlap, and for which consistency will be important).
The second tab in the spreadsheet is about the specific elements that will be used to create these interaction components things like buttons, editable fields, read only fields, drop downs, etc., etc. (These will be mixed and matched to create the components described in the first tab.) We need this to make sure that everyone is using the same components from the Sencha library so they all work/behave the same way. So this is independent of which module, or the specific data in the fields, or the field label, etc. – it’s just compiling a list of what widgets we will need.
At the moment, we have a couple of people looking across all of the screens that have been designed so far, and develop a superset of those elements. (I had simply started with the Registration module, but that one is very simple, so the list will need to be fleshed out – meaning more rows will need to be added – from the other modules.) As we’re building this list, we can start identifying which Sencha widget to use to build an item (e.g., whenever you need a button, use X). And then, on top of that, well need to give the elements a visual look (there are evidently themes for these elements that come out of the box. If we’re very lucky, one of the themes would be perfect for what we need for JSS. However, since we haven’t decided on the exact branding, it’s difficult to say exactly what it should be. We’ve had a couple of false starts defining that brand, but we’re hopefully to get there very soon. In the meantime, if people could add any unique the elements from their modules to the list (if it's not already in the list) we'll be working to identify the elements from the Sencha tools for each of the components. For the time being, however, all you need to do is add the elements, not the solution.
Please speak up if this doesn't make sense.
Thanks,
Susan