What you need to do is design. Brief aside: design does not always mean drawing pretty pictures. System design, database design, software design, process design... these are all equally valid. Anyway, saying it is different from proving it. So, this happened today.
Well, it starts last night. As part of a group of evaluate-and-improve meetings, I end up sketching ideas with the boss for making a practical sliding nav menu (a "Facebook style" menu) from what's been built so far. She buys it entirely, and I get some other key info from her so I can make it up overnight, and first thing this morning.
One key was getting a list of items in the nav. I write "Home" at the top, and she strikes it. Not as stridently as grabbing a Sharpie and crossing it out, but that's the gist. And, there were good reasons:
- The company logo is also a link to home. You might think that this is risky, but...
- The organization just did a UserZoom study on nav for mobiles, and found something over 80% of users selected the company logo. Yes, even if there's a "home" tab of some sort. Second, if memory serves, was the browser's Back button.
- And therefore, it seems like a duplicate. Not only is there an argument for saving space, but with this use rate, maybe people start wondering if there's a difference between the assumed-home of the logo, and the home link...
So, I go with it. And I draw it like this. And then I see the problem. See, my solution has the masthead (title bar, if you wish) slide with the menu, so the menu link is always visible and it serves to be a consistent label and a button to close the menu.
Anyway, by sliding the masthead bar, the logo moves. On the handset, in portrait, it is almost off the viewport. So, the logo cannot be found or selected easily.
Worse, another decision made around the tiny, tiny table in the middle of the pod was that we'd avoid gesturally-induced click errors by making the menu modal. Nothing works but the menu items and the menu-button. So, we've have to open that up to allow clicking the logo, which then starts making the modality awfully conditional. When the rules aren't clear, no user will figure them out.
So, I added it back in. And an explanation about 1/4 this length mid morning totally made sense, so there wasn't even an issue. But what does it mean for process? Well, the way we did this is probably good. We had a sketch, and only when this real design went through a couple approvals (all this afternoon -- yes, approved!) did the details matter. But what if we'd come up with this in a room of developers, and they wrote the features and started building it based on these notes, then I come back 18 hours later with a design, and changes? Well, nothing good.
I won't quite say: slow down. But I will say, make decisions carefully. Do not make final decisions, and write details that should be in a specification, without design and design review.
Since I am sorta known as a patterns guy (I get lots of questions about pattern application and creation) a common retort to me at least would be: well, can't patterns tell you enough to avoid these?
Enh. First, have you actually read any of my patterns? Or any good patterns? They are conditional. It depends on what you are doing with it. No one else's implementation is the same as yours. If it is identical to something else, then you are probably copying too much, because no one else's implementation is the same as yours.
And second, we make up new stuff all the time. We're using this sliding menu as it fits the space we have, and there's a bit of user research that indicates it should work. But, it's not yet a pattern. It's not used enough to come up with best practices. And you do the same all the time. You push the limits and try new things. You can use principles, heuristics and patterns to guide and get close, but as I think I said, your product is a precious and unique snowflake. Let it breathe a little, and find it's own way in the world.
No comments:
Post a Comment