There is an idea in the Agile world that the most effective software teams are those made up of generalists. From a development perspective I have found this to be, for the most part, true. However, in most of the places where people make the argument for generalists you never hear any mention of the UI. If you are wondering why that is, so am I. In many cases the design of an application is considered to be a technical problem. "Should we use AJAX or Flash?", "How do we hook that front end up to the data?", "How will it perform?", "How easy is the technology to work with?", "Do we (developers) have the skills with this technology?". These types of questions all have a crucial problem. They are all developer focused questions. None of the questions above even remotely consider the end user... those are the people that USE your software, not necessarily the ones that BUY your software.
Things fall apart here because UI is not a technical problem. If you think in technical terms you get a technical solution that works well for technical users. For example, if you ask most developers how to build an app that allows users to manage their timesheet, you are like to get something like this.
A database to store entries for each users.
A screen with a grid on it where users enter hours for each task for each day.
How to build a better Time Tracking application
The problem here is that we got what we asked for. A screen that looks like the developers version of a timesheet. An Interaction Designer may have come up with something different. Why? Because instead of focusing solely on the task of entering time into a database, they would focus on what the user really needs in order to track time. Thinking "outside the db" allows us to investigate how to best meet user goals. In this case, you may find that many people enter all their time at the end of the week. They may keep track on paper the hours spent and translate that into the application on Friday, or occasionally on Monday morning. A more efficient approach would allow the user to bypass the paper step and replace the whole process with something that meets their goals better. We may find that users write down the time they start a task and then when they are done write down the end time. We may also find that an equal number of people write things down at the end of the day. I bet that we would not find many users that log into their online timesheet and enter time spent on each task immediately after completing it. Even worse some users probable don't keep track at all and just make an education guess at the end of the week.
Realizing that the goal is not to "enter" time, but rather to "track" time makes a big difference. Building an application that allows the user to indicate that "I am about to start on task X" and when done say "I am done for now with task X and I am now starting on task Y" removes the added step of tracking time and then entering time into their timesheet. Building in a way for a user to say, "I was out of the office yesterday working in my hotel room, but I worked on X for 2 hours" would also add tremendous value. Using the same application offline allows the user not need to know or care about the technical difference between being "on the network" and "off the network". Have it sync up automatically when the user gets back on the network and you will really have a seemless experience to the user.
So how do we justify the need for an Interaction Designer?
Usually people who make decisions want to see how their decision affects the bottom line. The value of a well-though user experience can be quantified. Imagine you plan to sell you timetracking software to large organizations of say, 50,000 employees. Every week each employee needs to track their time. If you can reduce the time it takes to track time by 15 minutes. 15 minutes x 50000 employees x 52 weeks = 39,000,000 minutes (650,000 hours) per year savings. How much does that cost the organization a year? Even if you only made it 2 minutes faster, you would have a big savings. This isn't even considering what I call the "Extended Cost of Confusion". Extended Cost of Confusion can be more difficult to track however we probably see it every day. You try to use some application and can't figure some function out so you ask the colleague sitting next to you. Best case, she spends 5 minutes showing you how to do it. Worst case she spends even more time trying to figure it out, can't either and now you are both stuck and have spent valuable time. Add on top of that, the cost of calling the help desk or customer support and it can really add up quickly.
But what about the generalist? Can't they learn how to create better experiences?Maybe, but do they want to? And will they ever be as proficient as the person who won't, in the back of there mind, be concerned about how difficult it will be to implement.
For an analogy, think about going to your primary care doctor who is analogous to a generalist. Say, for example, you have suddenly gone blind in one eye. Who do you want to take care of you? The generalist? or an Opthamologist?
Here's another example. Imagine you want to re-design the interior of your house and make something very peaceful and serene. You a contractor to come in and replace some windows, install bamboo floors and paint your walls. Do you want this same person picking out the fabric for your sofa?
But an Interaction Designer will cost money and take timeYes. He/She will. However, what is the cost in dollars and time of building your product and finding out that it doesn't meet the needs of the people using it? What does it cost to rebuild an application? Will you get it right the second time?
Obviously not every product has the same need for Interaction Design. However, almost all products have SOME need for it. If your product is going to be used by humans, make sure it is designed for them to use from the beginning.
So, do you really need an Interaction Designer? What do you think?
Recommended reading: Can programmers do Interaction Design?
No comments:
Post a Comment