Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Design Principles

Lead UI/UX Coordinator: Susan Wolfe

...

(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.

...