Assume that you are in charge of a development project and you have about $10,000 to spend on usability. What is the best way to use the money? What is the right thing to do for the organization? What will be best for customers?
Extreme Makeover is an unlikely place to look for useful insights into corporate innovation. Even the fat, awkward, and, let’s face it, hideous bubble-era companies were not going to improve their questionable bottom lines with a nose job, liposuction, and tummy-tuck. In spite of that, the show can offer some useful lessons when trying to understand the dynamics of innovation.
I recently started a new job. The group I manage is new and all the people on my team have recently been transferred into this group. Additionally, each person has spent a lot of time in the recent past working on individual, solitary projects, and has not regularly been part of a collaborative team.
The efforts to define our field and our role are understandable by-products of our economic times and of forces in our contexts of practice. What are the pressures behind this quest for definition? What are the options (and potential advantages) of refusing to pigeonhole ourselves?
Content management systems suck. Or so you would think from the strife heard from analysts and practitioners alike. And yet, many websites regularly publish vast amounts of information with superior control and ease compared to manually editing pages.
When resources are limited, the design must be optimized to make the best use of all resources. To account for this complexity, it is important to have a clear understanding of both sides of the design equation—what you have to work with and what you are trying to build.
How often do we want to simply make our point, instead of bringing our opinions together to reach consensus? Look at all the PowerPoint presentations and slick brochures: we want to tell our view, instead of listening to others. We want our opinion to be heard.
We’ve all seen blueprints–formally known as contract documents–which architects produce and builders use to construct. No one person knows all the details of the design; the end result is entirely a product of teamwork. But there is one axiom: architects do not build.
Designing web-based enterprise software involves creating complex artifacts like architecture wireframes, object models, screen flows, and clickable prototypes in order to articulate aspects of the online experience for product stakeholders. But what does “craft” mean for interaction designers?
Discussions of how we should label ourselves and define our work are like flu epidemics. They break out from time to time, follow a fairly predictable course, and often make us want to barf.