Differences in both designs:
Design 1:
1.Old typical look and feel.
2.Number of steps to complete the task was one step more than Design 2.
3.Cheap (Cost wise) to implement.
Design 2:
1.More latest in look and feel.
2.Number of steps to complete the task was one step less than Design 1.
3.Expensive to implement.
Any guesses for which option you think was used more??
Well! It is Design 1.Due to its ease of use and intuitiveness, design1 was more used.
Drag n drop is more sophisticated in look and feel and is also easy to use otherwise, but in this case:
- Lack of intuitiveness: User had no clue that drag n drop was also a way of doing the same action. The green add/remove icons on the right hand side of Design 2 were displayed only when user clicked on the entity and dragged it.So even if the user was told this way of doing the action, in user-training, it was not intuitive enough. So user couldn't recognize and rather had to recall each time of this option. As a result user used option he/she could see at first instead of remembering how to do it.
- Not very easy to use: Drag n drop works in a way that , the source is supposed to be dropped at the target. So it works well when distance to drag is shorter and the target is bigger. In this case the distance to target could be bigger and not very easy for the user to keep dragging till that distance.
Lessons Learnt here were:
•Heuristics/Principles of a subject are important. They can be avoided at times but cannot be ignored. In the case above, one of the major design principles of design “Shorter distances bigger targets" was being avoided.
•Visual affordance: A design should be intuitive enough visually such that user doesn't have to recall about its functionality.
2. Giving "+Detail" option in a table:
"+more”, "+details" have been lately used to display details on demand. At first glance user can see only the information that user can absorb and can see more info on request if he/she is interested.
We implemented this feature in one of the grids/table displaying data of reports generated by the user.
At first glance details shown were: Report Name, Time of Report Generated, Type of Report, and No. of rows in the report.
There were various filters available which could be applied in a report. But there was no way of seeing it after the report was generated except downloading the report and opening it to see what it contains.
Best solution crafted to address this issue was adding +Details with the every report displayed. This is how it looked:
As a team we were really excited to design this feature. We thought this feature will be quite helpful to the user as there was no way of looking out the details earlier than this was implemented except downloading the report and opening it.
However, it is still a doubt whether users are actually using it or not. We are assuming that most users are not using it since this section is not being well maintained in the sense, that any enhancements done to the filter section (on the left side of above screenshot) needs an effort in this newly designed details section as well.
But this effort is not being put as it is termed as "low priority" and as a result it has become stale / outdated not being at par with other functionality.
Lessons Learnt here: It is good to know your users and interview them before the designing phase, however it is very difficult to have access of actual users especially in a project where your client is not the actual end user.
The challenge is to understand what works and what does not with the end users when there is a limited/no access to the actual end user.
One way to understand this without having access to the end users understands user patterns through analytic. There are ways to record user actions/clicks. This data can further be used to analyze success/failure of a feature/functionality.
I have no experience to share on this area yet. Shall keep this blog posted if at all I get a chance to work on this area.
3.Accommodating additional information in tool tips instead of adding columns to the UI:
An important principle to be kept in mind is that users don’t learn/ remember too much information present on the UI.
One of the articles I read related to User Experience describes it really well. It associates user experience with the
snowplow. Below is the, very interesting portion taken from that
article:
“Let’s take a moment to ponder the humble snow plow. It’s a device of unquestionable value. It keeps roads safe and can be called upon in snowstorms and blizzards to clear paths to otherwise unreachable locations.
In many areas around the world it’s an essential public safety tool.But if you owned a snow plow, would you drive it to the corner grocery store? Or to work every day?
Probably not, unless you lived in Antarctica. Most of us live in climates that require the use of snowplows only periodically, during the worst weather conditions – if at all.
In fact, many people have never benefitted from a snow plow. But where they’re needed, they’re indispensable.
So what does this have to do with user experience and interface design? Think of building an interface with a great deal of unnecessary information and capabilities as the metaphoric equivalent of using a snowplow for one’s daily commute.
Sure, it gets you there – but what portion of the capabilities are actually needed? Would a smaller, more efficient vehicle work just as well? Is it possible to achieve the goal without firing up the heavy equipment?”
Packing too much information on an interface causes confusion and most of the times users get distracted with extra information resulting in poor user experience. This is what happened with our web app.
There was a requirement to show type of an entity displayed as a column in the table. A user should be able to know type for each of the entity Open inventory, Delivery, Sales, Close Inventory (
[1] Screenshot above) displayed as columns in the table.
The values (6000, 3675, 7897 and 7000) in
[2] in above screenshot could be of Type A, Type B or Type C. So it was required to display its type.
[3] In above screenshot shows the horizontal scroll giving hint of number of columns already present in the table.
Two solutions were proposed:
1.Add type column for each entity. There were 4 entities so in all 4 columns were required to be added.
2.Display type as a tool tip on each entity. So when user hovered on value 6000 its Type will be displayed in tool tip.
Differences in both designs:
Design 1:
1.Uses more real estate.4 columns are to be added which will increase the horizontal scroll even more.
2.Not very easy to use. As the entity column is towards the left and to know its type user has to scroll to extreme right.
3.Displayed upfront on UI.
Design 2:
1.Used less real estate. No columns need to be added.
2.Comparatively easy to use. No need to scroll just hover on the entity to know its type.
3.Information is hidden until the user mouse hovers.
Any guesses for which option you think was chosen??
It is Design 1. The main reason was information was upfront present on the UI.
I strongly recommended Design 2 but couldn't understand the choice of Design 1 as the solution chosen. Snow plow principle described above can be related here.
Lessons Learnt Here:
You can work on information to be shown or removed, if you get to know the following:
- What’s most needed
- by the greatest number of users
- in the greatest number of high probability use cases.
You can move or remove elements and functions that are less important, which is also called design for probabilities vs possibilities.
Conclusion : At times you may craft best of design as a way of doing thing but it still may not work with the users/clients.So if you have heuristics or data to prove that your design will work the best it will be more helpful to get it approved.
