3 posts tagged “simplicity”

    How many times have you suddenly "discovered" a feature about a certain software that could of possibly saved you hours of time had you known that feature before? It's all too typical to find hidden features in software these days. The problem isn't that designers intend to keep you from using such a feature, it's that the design limits them from "trying to put everything in front of the user". There's the first mistake - don't.

    There are some products that will put everything in front of the user while other products will only put a few things while hiding the rest from perspective. Users will either find themselves searching and searching for something that they need to get to or slow down the confusion and filter through all the unnecessary, even still - distracting - garbage in front of them.

    To avoid this scenario, designers can equip themselves with learning about what tasks are important to their users in addition to creating workflows. Most users can only get one thing done at a time. It's usually best to follow this idea of presenting things one at a time - wherever appropriate. For instance, instead of providing the textbox to post a new blog post, there is a Create button at the top of the page. I can see that when I need to accomplish that task, it's right there in front of me to get to it - without distractions.

    As a user we can be prone to wanting everything in front of us at every possible moment, but what we tend to forget is that we don't always need to get everything - everywhere - done at the same time. So, in supplement we complete tasks according to the context or point of focus we are in. At the same time, with respect to the designer, we need to understand that users need to be able to get out of context quickly - without seeking it out, which can lead to frustration. Simple things like - "I'm done", "Save", "Ready", "Back", "Previous" help users understand that they can navigate to other points of focus not only fast but very simply.

    There is an age-old saying that everything that can be thought of has already been created in some form or another. The problem that differs from every single scenario is not necessarily the practice that implements the solution but the entire product that shows itself through its main and completed interface. While the importance of lean and efficient code is and always will be there, there is of much greater importance to a product that can market itself. But let's take a step back at what great products entail in their user interfaces.

    There are a load of toolkits available to create graphical user interfaces today for the web, desktop and mobile but what most of these toolkits tend to do is supplement a key component in creating a product - showcasing originality. In fact, the greatest part about creating a new product is that you have full control over how your users are going to interact with it - you can choose to make task completion inherently difficult or inexplicably easy. In all of interaction design this is quite possibly the most important - work hardest on it over any other.

    Google wasn't the first search engine, or the last for that matter, but what made its success what its ability to create relevant searching without disrupting the user's train of thought. The same logic can be applied to just about every industry in existence. Take a look at the number of different learning management systems available - (there are over a dozen different open-source "enterprise systems").

    The only successful product out of that market will be one that can differ itself in great interaction experience. Of course, creating that will not be easy and should not be taken lightly. Efficient code takes much thought into building algorithms that you can depend on. The same goes for interfaces in that successful products take much more thought, time and emotional presence into designing interfaces that you can depend on.

SCS, or Simply Complex Software, is a way of describing a program that is complex in a really direct kind of way. The level of complexity depends on the depth of the application and to what extents it may reach. There are essentially two types of software that inherently make it complex: 1. the software is complex by the nature of what it must accomplish, simulate and acquire to present data to the user and 2. the interaction is complex by the nature of bad design.

It's easy to say, this software should be simple to use, intuitive, interactive... you can throw all the words at your requirements as long as you have time to. The principle lyes in the goals of the team in developing the software. Simplicity for development or simplicity for user interaction. Questions that may arise in the cycle of interaction design include:

• Is this something a user can move and resize?
• Does this relate to a goal that the user is trying to accomplish?

Questions that involve persistence and existence levels should be the main points to consolidate. Persistence meaning for how long, existence meaning where. Interaction with software has of course grown over the years where we can effectively ask these questions so our users aren't constrained with the natural complexities that make up software. There are base interpretations to building software that make it apparent that certain tasks should not have to be done by the user. The very reason behind this is because, in code, we are perfectly capable of handling the extra steps necessary to complete the goal. This should be a general train of thought when approaching interaction design.

Users aren't meant to understand network protocols, binary data, hexadecimal commands, error codes, error messages, and even going to the extent of the strenuous tasks that make up our computing lives. File management is something that can be kept in mind for automation, so long as it follows user intentions. Even something as simple as a file path is useless to a user, it involves directory structure and is usually arbitrary.

Moving on to the reasoning why most software is neither simple to use or complex in its depth. I address this because most developers ask far too much of a specific feature. A PM will introduce a feature, documented no less, the team will continue to discuss interaction, to which varies insurmountably, and finally the team gets to developing. Vision, idea, documentation is far away from what code can produce. There are normally two bumps in development that may deter the original vision, either the vision is overkill and too much and the team accepts it regardless or the vision is still complex and the team undermines it by their abilities and/or development time. Point stated, team dynamics destroy what could be simply complex software.

And a note from Kathy Sierra's blog:

I think we'll have to take a moment to start understanding team dynamics next...