Last night, I attended an ACM (Association of Computing Machinery) CHI (Computer Human Interaction) meeting, here in Ann Arbor. The topic was: wireframes.
First of all, I’ll admit that I attended only because I’m an ACM member and these are the only ACM meetings I can find in this area, although I do sometimes enjoy hearing about ways to improve the interaction between humans and computers. In fact, it was a bit funny (or sad?) because I sat next to a fellow who said he was working with UX. I got quite interested and responded that I had also worked quite a bit with UX, which started a long conversation. Later in the evening, it dawned on me that that we were talking about two different things. I was talking about UX the operating system, where many of the people in the room work in UX (User Experience). Just as with Cleveland, where I ended up attending meetings with mostly people in the healthcare IT space, here in Ann Arbor, I will be mainly rubbing shoulders with web-based folks since Ann Arbor is a big hub of web-based activity. And, as opposed to the Cleveland Clinic and University Hospital people that dominated the Cleveland meetings, here I’m getting the impression I’ll be inundated with people from U of M, Google and GE, but time will tell on that one.
But back to the wireframes: wireframes are basically ways to design web screens. It’s just like the screen design that we do, but they call them wireframes. They can use a pencil and paper, Visio, or a myriad of special drawing tools meant just for designing web pages.
One screen design tip that I do already try to keep in-mind is to consider the audience. For example, you don’t need to make the screen look exactly like the final screen, depending on who you want to show it to and what the purpose is. In fact, they showed some great examples of screen designs that looked nothing like the final web-site but that captured all the actual requirements as to what had to be on the web page and the purpose of those items.
Another useful tip was that you shouldn’t overwork your screen designs. Sometimes, people get too caught-up in making the design perfect or in using all the great features in the drawing tool they have and just invest too much time in the drawings.
Yet another tip that I think is worth considering even for LIMS, ELN and other products is to consider the state of the screen. For example, if you are designing a screen that will track sample or experiment handling, you could draw the screen for data entry then another version of the screen for after the user clicks on the Save button. Think of it, this way: often, we will lock-down certain fields once the user saves their data. We often just mention it in the text. But, we could just as well copy the first screen and try to show it with the locked-down fields greyed-out or something else that visually shows the change.