I'm a user interface design consultant; I work with companies to produce web sites, applications, and consumer devices that give their users simple and direct tools for solving their problems. This consultancy – Miramontes Computing -- is the latest incarnation of my long-standing interest in technology, design, and usability; I've also worked in corporate research labs, including Apple and HP Labs, as both an individual contributor and as a first and second-level manager, and ventured into the startup world a couple of times. If you go back far enough, you'll find my academic roots in cognitive psychology, with computer science mixed in on a frequent basis.
Although the form of my work has shifted with the venues in which I've worked, my fundamental approach has been consistent. I focus on the "user architecture" of interactive systems: as a consultant, I will ideally start a project by working with my clients (especially their marketing organization) and their users to understand what people expect, need, and want from a particular system, and work towards an interface that meets the users' requirements, the engineering constraints surrounding the system's development, and the business demands of the client. Pragmatically, this means that I do a lot of interviews and observational studies in the early phase of a project, and build increasingly detailed prototypes of potential solutions that can be tested on users and checked against the broader requirements of engineering and marketing. The clients and I then narrow down the alternative designs to a single winner, and flesh out that design into one that's ready for production. Once serious engineering on the design has begun, I'll usually shift into usability testing as part of the product release cycle, refining the engineering releases to completion. This style of work has worked well in product settings; it's also paid off in research environments, where I've often gotten a project started by building a quick prototype as a way of framing the problem to be studied and laying a foundation for more work by myself and others.
The main thing I've learned from all this is that usability runs deep: some of the best usability decisions I've ever made (or influenced) have had to do with the object hierarchy of a system design or the APIs between some system components. This isn't meant to minimize the importance of visual design or command structure; indeed, addressing these details is a big part of my business. But these deeper architectural details can have a huge impact on the kinds of information an application can present and on the capabilities of the system that an interface can control. And that translates into a huge impact on the overall quality and ease of use of the system. It also means that usability is a tough job – to do it right, it seems like you need to be part marketeer, part engineer, and part artist – but, hey, nobody forced any of us to go into this line of work.
As a manager, I find that these same principles apply to the structure of a good design team. I'm a big believer in multidisciplinary groups, made up of people able to address a problem with different skills from different perspectives – ethnographic studies, design, engineering, traditional usability testing, and more. Keeping these different perspectives in sync and focused on the work at hand can be a challenge, but the payoff from this approach is abundantly clear. Usability issues are broad and deep, and properly addressing them requires an equally broad palette of tools.
Anyway, welcome to the site. Please get in touch with any comments, thoughts, or questions.