Consistency is often lauded as a high ideal to strive towards when designing user interfaces. It makes sense – if you do something once, and then a second time, suddenly that thing can become quite natural and … well … intuitive.
Last month I came across a cautionary tale related to consistency.
In the last couple of weeks I’ve received several calls from companies claiming that my computer is sending them messages indicating I have been infected by a virus. The scam tries to get you to install remote control software so their “Microsoft Certified Technician” can show you where the virus is on your computer, and possibly help remove it.
Frankly the scam came on pretty hard and was fairly convincing.
A project I’m currently working on is encountering a problem that I believe is not all that rare. They are faced with a challenging question mid-project: should the team focus on producing software that is easy to use and learn, or should they focus on getting as many features and bug fixes in as possible before the final release? I have seen many people frustrated that we can’t seem to have our pie and eat it too – we can’t seem to find ways to “do usability” without somehow impacting the project’s timeline or scope. And sadly, at this point in time, I agree that this is true for this project. Kinda.
I’d like to take a closer look at these two options, and propose a few solutions for future project teams to consider.
A great example of how working with Open Source Products leads to quicker problem solving, user success and support.
Needed help figuring out what channels I record the most. Help in IRC pointed me to the exact line of code where a related product issued the exact query I was looking for.
I am a strong advocate of Open Source projects and those who choose to work on them. Just this week I was involved in a great example of how this different approach to software products can enhance the user/customer’s experience.
I was reviewing a wireframe of mine the other day with my team and we felt a little stumped by one particular part of the design. It felt like it was a good design but I couldn’t put into words why I preferred it over the alternate I had proposed. The team also struggled with giving a name to why it was a better design – until our newest member spoke up.