A list/Sort Pattern For Everyone
I was recently asked to prepare a wireframe for a UI that would allow a user to create and sort a list. The users of the list/sort UI encompassed a wide and diverse set of computer users. Essentially, the UI needed to be intuitive enough for those users who seldom use web applications, but also not so verbose that it might slow down the seasoned user. Given this information I created a wireframe that combined the old fashion design pattern for creating lists, with a wizard/interview design pattern. Once I was done it was sent back to the client for comment. At this point, an extremely dangerous practice known as design by committee took place. The client believed that the new pattern for creating a list was too different from the typical pattern they were accustomed to seeing. Had I been in the room, I would have gently reminded them that we are not building a UI for the sake of their perceived knowledge of web applications alone, but for the person who more than likely has no mental model for a typical list creation, sort UI.
At the end of the day the design by committee people won out (and in my opinion the user lost), and I produced the following prototype based off a new wireframe which eventually lead to a completed UI (completed meaning interaction design & visual design were added). What are your thoughts? Did we in fact ignore a particular group of users with this final UI, or does this pattern fit the bill for everyone that might use a web application? I think you know my thoughts on the issues, but could I be wrong?
If the mouse pointer changes to a hand when you roll-over an image associated with a story the image upon clicking either links to enlarged version of the image or a website associated with the image.
I really like the clear separation you provide in the first wireframe. It provides an easy interface for the way users typically interact with it.
That said, I would rethink the “Step 1”, “Step 2”, etc., as users won’t always follow those steps and desite your instructions at the top, may find that to be confusing. I would change them to something like “Available Items”, “Add Item(s)”, “Selected Item(s)”, and “Save/Reset List”.
Otherwise, great improvements. IMHO.
I have to say, I think the final UI is probably closest to how I’d expect something like this to work. The Double List pattern that you linked to is quite common in Windows UI. The only tricky part to me was the move up/move down as it seemed a little removed from the action, off to the right like it is. Somehow tying it into the list panel itself would have been the only thing I might have done differently.
Cody, you are onto something when you say the user loses out. Why would a committee even try to assume the role of a user (conflict of interest?)? I’m not a fan or advocate of “focus groups,” but it seems to me the one point of view that was overlooked was that of the user (as you so wisely point out). I would imagine a quick online user study with measured results would’ve led to a more realistic decision…
I realize timelines and budgets dictate how these things happen, but a quick test may be helpful in the initial design stage. Regardless, it’s a shame that you didn’t get the opportunity to present your case.
I have to agree that that the first UI prototype is the easiest to use. That being said, I don’t think the final version is that bad. I’m it will still work fine.