The first 'PC' I had any real exposure to was a Mac in 1984. I was a film and video person with little computing background (one intro to programming class, in Pascal). The Mac made perfect sense to me -- moving pictures of documents and folders around on a desktop, drawing things, painting things. When I later saw what most computers were used for, and what their UIs were like (this is the mid-1980s), I was dumbstruck. Text and numbers on black or green backgrounds, arcane text commands, etc.
I started working in IT not much later and pushed every project I worked on (even terminal-based applications for beverage manufacturing and the like) in the direction of the "right" paradigm -- what I learned about what computing could and should be, from the Mac. Even today, when we've moved from the Iron Age to the Iphone Age, I still find myself thinking about UIs with the 1984 Mac OS as my reference point.
R.I.P. Steve.
Saturday, October 08, 2011
Sunday, October 02, 2011
Transparency in design
I want user interfaces, and for that matter all representational artifacts intended to help people do or make sense of something, to be clear and transparent. When it comes to design, this is the ethic that possesses me. One should not need pre-existing specialist (arcane) knowledge to make sense of a UI, or at least the need for such knowledge should be minimal, and not require knowledge of arcane aspects of the UI itself.
This is an endemic problem for enterprise UIs since they are so often built on previous legacy systems. Veterans of the older systems know the terms, functions, and acronyms so well that they become "natural" -- but they're not. The effects of these kinds of preconceptions are something I constantly work to alleviate when designing new or replacement systems. Knowing what the business purpose itself is (for example, selling and servicing telecommunications products for residential and small business customers), and understanding the business itself, and the customers, should be the only prerequisite knowledge for using the new system, rather than “just having to know” how things have been done and what things have been called and abbreviated and acronymed in the previous generations of systems.
Having said that, achieving effective transparency, like all design in the real world, is a balancing act. You don't want to clutter up the UI with too much explanation and exposition, and you want to enable experienced and expert users to move rapidly though their tasks. It comes back to practitioner skill: knowing the right trade-offs to make.
When I glance at position descriptions for user experience professionals, they often seem to miss the point (which is probably inevitable when you are throwing descriptions out to the masses). They list discrete skills (personas, wireframes, HTML 5, Flex, etc.) as if having such skills are what add up to an effective UX designer. But what really matters most is having the ability to understand user needs as well as business or organizational imperatives and technical capacities and constraints, among other factors, all of which require both listening and "speaking" skills in addition to “design” skills.
You need to understand what people (including developers, clients, executives, as well as end users) need and can do, and you need to be able to synthesize these, come up with design approaches, and advocate (sometimes passionately) for the integrity and value of your design given those needs, capacities, and constraints. Any specific skill or technical ability is secondary to these constraints (and a good UX professional should be able to quickly learn any new technique or tool in any case).
Often a first design proposal will not be the perfect solution (however perfect it may be in your own mind, or in the abstract), but it helps shake loose the thinking and creativity of the people you're working with and for, and the dialogue that follows from considering a well-crafted design gives the best clues for how to evolve the design in the best possible direction given all the constraints and sometimes conflicting needs and desires. Listening, making, and speaking are the lather, rinse, and repeat of user experience design. You have to be able to do them all.
This is an endemic problem for enterprise UIs since they are so often built on previous legacy systems. Veterans of the older systems know the terms, functions, and acronyms so well that they become "natural" -- but they're not. The effects of these kinds of preconceptions are something I constantly work to alleviate when designing new or replacement systems. Knowing what the business purpose itself is (for example, selling and servicing telecommunications products for residential and small business customers), and understanding the business itself, and the customers, should be the only prerequisite knowledge for using the new system, rather than “just having to know” how things have been done and what things have been called and abbreviated and acronymed in the previous generations of systems.
Having said that, achieving effective transparency, like all design in the real world, is a balancing act. You don't want to clutter up the UI with too much explanation and exposition, and you want to enable experienced and expert users to move rapidly though their tasks. It comes back to practitioner skill: knowing the right trade-offs to make.
When I glance at position descriptions for user experience professionals, they often seem to miss the point (which is probably inevitable when you are throwing descriptions out to the masses). They list discrete skills (personas, wireframes, HTML 5, Flex, etc.) as if having such skills are what add up to an effective UX designer. But what really matters most is having the ability to understand user needs as well as business or organizational imperatives and technical capacities and constraints, among other factors, all of which require both listening and "speaking" skills in addition to “design” skills.
You need to understand what people (including developers, clients, executives, as well as end users) need and can do, and you need to be able to synthesize these, come up with design approaches, and advocate (sometimes passionately) for the integrity and value of your design given those needs, capacities, and constraints. Any specific skill or technical ability is secondary to these constraints (and a good UX professional should be able to quickly learn any new technique or tool in any case).
Often a first design proposal will not be the perfect solution (however perfect it may be in your own mind, or in the abstract), but it helps shake loose the thinking and creativity of the people you're working with and for, and the dialogue that follows from considering a well-crafted design gives the best clues for how to evolve the design in the best possible direction given all the constraints and sometimes conflicting needs and desires. Listening, making, and speaking are the lather, rinse, and repeat of user experience design. You have to be able to do them all.
Subscribe to:
Posts (Atom)
Posts
