Do you remember how in college there were classes that were actually below 100-level? The classes that some folks were required to take but they didn’t count for any credits? Well, in trying to come up with a decent title for this blog post, I thought I’d throw in a 090 at the end of the title there since this post will be, in some ways, kinda like those sub-100 level classes. Simple (or simplistic, even), easy, basic-knowledge kinda stuff.
I have to tell you, I was in such a good mood at work today. I finished up a small project which I had begun last week (it feels so very good to make your final code commits… even though you know that bugs will be found, requirements will change, and something will inevitably be wrong with your code), and today I had to come up with a UI design for a filtering component in our application. To put it simply, our application has various “list” screens that list a lot of records and each of these list screens have a filtering component that can filter the records that are displayed to the user. They pretty much function as search pages. Anyhow, I was asked to come up with a design so that our users can not only search for records (existing functionality) but can also perform CRUD (create/read/update/delete) operations with their search settings.
Sounds like a ton of fun–was my first reaction. 
I was enthused about taking on this task because I saw this new functionality as being such a useful functionality for everyone–end-users, QA folks, us developers, business analysts, etc. I knew that anyone and everyone who uses the application would benefit from this functionality and find it extremely handy. Another reason why I liked taking on this task–I was told only the very high-level requirements–namely, that this functionality should allow the users to perform CRUD operations with their search settings. There was no story (i.e. requirements) written for this functionality and no mock-ups. It was all up to me. I love such freedom.
Well… without further ado, here are the steps I took to tackle this task. The last step is still in progress. I call this my User Interface Design 090:
1. Screenshots: Since this was going to be an addendum to our existing search dialogs and list screens, I took screenshots of all of the screens that were going to be affected. I then opened the images up in Gimp, cropped them so that only the parts I want are captured and then copied them into Open Office. I always find that to be a handy way of printing out screenshots that fill up as much of the paper as possible. There’s just something special about doodling on papers as opposed to staring at the monitor–it lets me be a little bit more creative.
2. Research: It didn’t take me too long to realize that I’m not the first person in the world to implement this functionality. This has been done many times before. Originality is good but why waste time trying to be original when there are already perfectly fine existing implementations of this functionality? I looked at various implementations of this–Bugzilla (opensource bug tracking software we use), Twitter (did you know you can now save your search settings in Twitter?), eBay, and even my BlackBerry Bold–the email application. I spent some time playing around with all of these applications. I made mental notes of things I liked and didn’t like, things that made me happy as an end user as well as things that made me scratch my head a little bit.
3. Doodling: After my research was completed, I went to the hard copies of the screenshots and simply stared at it for some time, trying to come up with a mental image of how I want this functionality to be implemented. Slowly, little by little, I started drawing the necessary components–checkboxes, text fields, buttons, etc. I also made various written notes on it–things that can’t be explained by drawing alone.
As I was doodling away, I tried my best to get into the mindset of the end user. To me this is such a crucial step in UI design work. In the end, when it comes to the UI, it is my end users that I need to please. I can build UIs that make my boss super impressed, the QA folks really happy, and my fellow developers envious, but if my end users aren’t gonna like it then I have failed. And that not only makes me look bad, but it makes my team look bad and the company look bad. I tried (as best as I could) to get into the mindset of our end users who use this software–for folks who have absolutely no aptitude nor interest in building software. And to be honest, I wasn’t exactly sure how I could most effectively accomplish this other than to simply take my time asking the What Would the User Do? question with every single doodling element I added on those screenshots.
One more thing to note–as I was doodling, I didn’t give too much thought to the limitations of the architecture/APIs. As long as I knew I wasn’t doing anything crazy I was let myself doodle away. I think it’s a bad idea to be bogged down with such limitations in your creative thinking stage. I’m not saying ignore all limitations. I’m just saying don’t worry about such things too much too soon. I can’t see how that’s going to help you come up with a good UI design.
After I got done doodling, I imagined myself as an end user accessing my doodle-turned-UI. As I went along this step, I made a few adjustments I thought were necessary.
I then went to Chipotle and rewarded myself with a 1110-calorie (yes, I did check my facts online) chicken burrito. SO GOOD.
4. Mock-up: Scribbles you’ve got written down on pieces of paper are useful but it’s even better (and more useful) if you can get them down electronically. After lunch, I made use of the Pencil Firefox add-on, which is a tool built specifically for UI mock-up purposes. You can drag and drop various UI-related items such as checkboxes, text fields, dialogs, fieldsets, and many more. It’s super easy to use. You can then export your finished work into a .png file.
This step took me no more than an hour to complete. Pretty impressive considering the fact that it was my very first time using this tool.
5. Consultation: After I finished mocking everything up, I sat down with my boss and discussed my mock-up with him. A lesson to be learned here: It’s a good idea to run your UI (or anything else, for that matter) ideas by someone. It doesn’t have to be your manager obviously, but it should be someone who is familiar with the software as well as the end users’ uses of the software. My discussion with him proved to be valuable since during our conversation a few things came up that I hadn’t addressed in my original mock-up.
6. Requirements: I got to write up a user story which details the new functionality. We make exclusive use of Google Docs for such purposes at the office. This is the first company I’ve worked for where that’s been the case and I’ve been really happy with doing it that way (What would we, software developers, do without Google?!?). I included the mock-up (exported as .png files) in the story. I tried to be as detailed as possible without specifying the implementation how-to’s of the new functionality in the mock-up. Even though I will most likely end up working on this feature set, the right thing to do when writing user stories is to leave such details out. Let others worry about the implementation details.
7. Review: Perhaps this should be bundled with the above step, but for emphasis-sake, I thought I’d make this into a separate step. It’s never a bad idea to review. If there’s one thing that being in seminary for 4 years taught me, it’s that you almost always discover mistakes when you’re re-reading through your essays. I read through what I wrote down in my user story. Surely, some minor edits were in order. I then printed out a hard copy of it so that I can take it with me and re-read through it before I arrive at the office tomorrow. As of now, the printouts are sitting on my desk next to me. If I finish this blog post up soon enough I’ll be sure to read through it before I go to sleep.
And this concludes User Interface Design 090.
As always, I’d love to hear your comments/questions/feedbacks via this website/Facebook/Twitter.