One of the great puzzles of software design is how to create a user experience that is both intuitive and enjoyable while enabling the user to get the job done with a minimum amount of hassles.
Too often software (or web browser-based services, for that matter) is designed to accomodate all forseeable use cases, which leads to factoring a bunch of edge cases front and center into the design. This results in software that is cluttered, confusing and inefficient.
Why? Because rather than enabling the user to focus on the 20% of the software functions that they will use 80% of the time, the user is perpetually surrounded by a bunch of noise that, while novel and impressive on first run, places a perpetual tax on the user across the lifecycle of using the software.
The goal of my post is not so much to try and analyze good and bad approaches to software usability and user interaction design (a great book on this topic is, "The Inmates are Running the Asylum") as it is to offer up a method that I have found pretty useful in working through complex UI and workflow design challenges.
I call it 'Starting in the Middle,' and the idea is that when you encounter a UI design challenge, you begin not with the beginning of the workflow that is to be facilitated with your software, but start in the middle of a particularly important task.
The reasoning is two-fold. One is that by starting in the middle of an important workflow you naturally focus on the specific job that your user is going to want to accomplish at this place in the software.
This ensures that you focus on the substance of the job -- i.e., named procedures, logical ordering of core functions, natural leverage or entry points from other places within the software and subsequent handoffs once the task is completed. In other words, you focus on substantive outcomes, internally logical and externally synchronous actions and avoid getting distracted by global constraints and style points. For me, it turns the process of UI and workflow design into a kind of orchestrated chess board move, which makes it surprisingly manageable.
The other reason for this approach is that while all tasks are ultimately bounded by the user interface and workflow constructs that you have built into the software, invariably a few different workflow types may be supported within your software. In my experience, one size and one design does not necessarily fit all when talking about meaningful functionality with user lifecycles.
Hence, in the process of revving the software or adding on new functionality, you may conclude that different function sets (or more likely, complete tasks) fit more logically within one workflow type than another. Or, you may conclude that the new functionality sufficiently re-defines the job you are enabling a user to accomplish that significantly iterating existing workflows is warranted.
I should disclaim at this point that I am not an engineer and I am not a trained user interaction designer. I am just an entrepreneur who believes that the marriage between product design and product marketing is essential.
This is so because the jobs your target users ultimately will hire your software to perform for them will need to be aligned both inside the product and outside it (when formulating your go-to-market strategy, messaging and the like).
I have also found myself in more than a few startups where I was the guy raising his hand to take a swag at the user experience side of the software. (Of course, this is/was always done in tandem with a great developer or two who has to implement the functionality and in the process becomes a key collaborator on what ultimately gets baked.)
In any event, next time you face a difficult user interface or related workflow challenge, don't start at the beginning. Start in the middle.
