03 Jul 2003 | danny said...

Could you link to such a document. I am afraid I don't really understand it.

03 Jul 2003 | Matthew Oliphant said...

Here are some documents used in the User-Centered Design process (the link goes to a NASA site, but the documents listed are meant to be used as templates, so hopefully their purpose should be explanatory. Specific to this topic is the Task Analysis Template.

Some of the different parts of a FTA are FT Scenarios, Function Allocation Table (or diagram), potentially workflow diagrams, and the main task analysis. Some of these are closely related to what a requirements, or process modeler might create.

The scenarios are a narrative form of the user goals for the purposed system. What does the user wish to accomplish. Sort of along the lines of a combination of Use Cases and Personas.

The FAT is a work breakdown of user actions and system responses and should cover all tasks (or at least the main ones), as well as be user-centric. In table (I'm not going to build a table here:) form it might say: "User selects the appropriate Account Type. System displays feedback that a choice has been made." This is a requirements document that begins the bridge between the analysis and design phases. So you don't necessarily say that the user "Pushes the Submit button," as that would be a design decision.

A workflow disagram is essentially a high-level diagram of actions taken by the user to complete the task. It is entirely (ususally) user-centric, and basically should show the path the user takes from initiation to completion.

The main FTA document has a detailed breakdown of each task (and sub task) the user can perfom with the new system. This should match back to any business requirements document that was produced. It should contain all relevant info, as well as how the design might be impacted. No design decisions at this point, just things to keep in mind when you start designing.

Did I go too academic (for lack of a better word)? Does anyone produce these kinds of documents?

Let me know if you have more questions. The NASA site has some decent templates for UCD related deliverables. I'll see about posting examples (templates, no info of course) from work on my Web site.

04 Jul 2003 | hurley#1 said...

I was involved in something like this in the 1980s, when the nonprofit I worked for made a transition from an aging DEC mainframe to a bunch of Apple Macintoshes networked to a minicomputer. Our IT department had to develop new and improved forms for data entry and reports, and I was the liaison between IT and the department I worked in. I interviewed all my colleagues to find out what they needed, and interviewed my bosses to find out what they were looking for in reports.

The biggest lessons I took home from that process were that system design is an iterative process, and that most people cannot envision what they need abstractly or even after looking at paper prototypes and workflow diagrams-- they can only tell you what they need after they start living with the system.

You can get a reasonable approximation of what people will need by going through a lengthy process such as identified on the NASA site. But you will still have to refine the design, or in extreme cases start over from scratch, once people actually start using it.

In my case, the data entry forms we designed were basically good, but (after the new system was in place) management kept coming up with new things they wanted to track in weekly and monthly reports. So we would have to collect new data, which meant going back and revising the data entry forms. We also spent a lot of time redesigning the reports based on managers' feedback. The lesson there is that managers are usually too busy and harried to provide helpful input at the beginning of the process; it's easier for them to just offer criticism of the working product, which you then have to revise.

So I guess my opinion is that it's better not to expend a whole lot of effort up-front trying to come up with a perfect design or a perfect system, but instead put something in place that gets you reasonably close and then refine as you go along. I think that ends up being cheaper, more efficient, and less frustrating to everyone involved. Good luck convincing managers to go with that approach, however.

04 Jul 2003 | JF said...

hurley#1, you are so right. I completely agree. You can't simulate reality. Sure, you can score a few insights here and there, but what people tell you is often different from what they do or what they'd like to do. I've always found it slightly humorous that many usability and task analysis surveys don't have a "no comment" option. In effect, they force you to answer a question that you really don't have an answer for. Then, people take that data and run with it as if it's fact.

Experience has taught me that the best results come from your initial best efforts (which includes some quick information gathering up front) plus constant tweaking post-launch. As long as you aren't initially way off the mark (which you shouldn't be if you know your business), you're going to save a lot of time, money, and energy by going with an interative approach. Plus, since this approach shortens time to market, your version 2 or 3.0 will be launching the same time your initial 1.0 would have launched if you spent all that time up front trying to predict the future.

Did any of that make sense?

04 Jul 2003 | Matthew Oliphant said...

Plus, since this approach shortens time to market, your version 2 or 3.0 will be launching the same time your initial 1.0 would have launched if you spent all that time up front trying to predict the future.

I guess this supposes that you (if you are a consultant) did a good enough job to be invited back to do versions 2, 3, etc. :)

I guess we just do a lot of documentation. A lot of steps (mandatory) in our methodology. I think that some of our documents aren't all that necessary, but I don't know whether I did or didn't do it, if it would make as good an app.

A somewhat unique (tell me if it is unique) part is that I will have been off the project for 1-3 months before the implementation even happens. And I rarely hear how it is going when it does go out. I am already on a new project (or two) by that time.

For us the life cycle of a project (talking Web apps here) is anywhere from 14-24 months. This is from kickoff to full implementation to the target user group. Partly this is because the project teams are 30+ members, and the target audience of 34,000+.

Hm, perhaps this topic is a little esoteric for most who read/comment here? Hey, after all, I'm stuck in the middle of Illinois at a company that doesn't "share practices" all that often. I just wanted to see what poeple "out there" are doing.

BTW, alisha? You out there?

04 Jul 2003 | hurley #1 said...

I guess if you're stuck with that bureaucratic process, then you have to make the best of it. But me, if I had to fill out all those forms and create all those deliverables, I'd start looking for a bridge to jump off.

Formalized processes like this probably make some sense in big corporations or agencies, but I'm not convinced they have much benefit other than documenting internal accountability (at a pretty high price in terms of lost time and productivity).

04 Jul 2003 | Matthew Oliphant said...

...but I'm not convinced they have much benefit other than documenting internal accountability (at a pretty high price in terms of lost time and productivity).

Yeah, I do tend to agree, but they have another use. Because the docs are so detailed, if another designer comes along on a project for the same user group the info in the analysis only has to be verified. It doesn't have to be gathered and documented, unless the user group has changed substantially, which tends to not happen quickly.

04 Jul 2003 | Ron Zeno said...

I've always referred to this "Future Task Analysis" as "work redesign". Towards the goal of minimizing documentation, I refer back to problems found in task analysis that can be fixed through a properly designed new system. Of course, consultants don't always have a great deal of choice on what they document and in what detail, and they can be biased towards more documentation than necessary.

05 Jul 2003 | p8 said...

Matthew, I think you should look at extreme programming.

Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

The 12 core practices of XP are:
1. The Planning Game: Business and development cooperate to produce the maximum business value as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same:
1.1. Business comes up with a list of desired features for the system. Each feature is written out as a User Story, which gives the feature a name, and describes in broad strokes what is required. User stories are typically written on 4x6 cards.
1.2. Development estimates how much effort each story will take, and how much effort the team can produce in a given time interval (the iteration).
1.3. Business then decides which stories to implement in what order, as well as when and how often to produce a production releases of the system.

2. Small Releases: Start with the smallest useful feature set. Release early and often, adding a few features each time.

3. System Metaphor: Each project has an organizing metaphor, which provides an easy to remember naming convention.

4. Simple Design: Always use the simplest possible design that gets the job done. The requirements will change tomorrow, so only do what's needed to meet today's requirements.

5. Continuous Testing: Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Tests in XP come in two basic flavors.

6. Refactoring: Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn't break anything because you have the tests.

7. Pair Programming: All production code is written by two programmers sitting at one machine. Essentially, all code is reviewed as it is written.

8. Collective Code Ownership: No single person "owns" a module. Any developer is expect to be able to work on any part of the codebase at any time.

9. Continuous Integration: All changes are integrated into the codebase at least daily. The tests have to run 100% both before and after integration.

10. 40-Hour Work Week: Programmers go home on time. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.

11. On-site Customer: Development team has continuous access to a real live customer, that is, someone who will actually be using the system. For commercial software with lots of customers, a customer proxy (usually the product manager) is used instead.

12. Coding Standards: Everyone codes to the same standards. Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code.

05 Jul 2003 | Matthew Oliphant said...

p8, thanks for the link. I will read it when I am getting paid to do so. ;) Seriously, I will take a look at it. Part of my posting this topic was out of frustration with the process at work. If I posted my work's methodology, you'd all be looking for a bridge to jump from. :)

Quick question before I delve: Is extreme programming similar to Rapid Application Development?

06 Jul 2003 | p8 said...

I'm not familiar with RAD (nor am I an expert on XP) but they seem similar, although I think XP is a bit broader. Both seem to encourage an iterative design process (which Hurley#1 and JF mentioned).

"When the Hubble Telescope was launched into space it had a mirror built to the wrong specifications. It wasn't until the telescope was fully deployed and in the hands of its customers that the problem was discovered. A satellite's customers can't try using it until after it's in outer space, but why do we do this with software?"

07 Jul 2003 | Don Schenck said...

I don't even know what Future Task Analysis is.

*sigh*

08 Jul 2003 | Don Schenck said...

My Square Foot Garden has been feeding us salads every night for the past 30 days plus. Now, our heirloom tomatoes are starting to thrive! Woo-hooo!

A little whole wheat bread, some "designer" lettuce and heirloom tomatoes from the garden, some salt and pepper, a splash of Italian dressing or -- better yet, tampenade, and I'm in Food Heaven.

08 Jul 2003 | Don Schenck said...

My theory: Alisha is on vacation. They get like 30 days in non-U.S. countries *sigh*.

08 Jul 2003 | fajalar said...

Yeah, our garden is going great too. Cucumber (okay, only 2 so far, but they were big), squash, lettuce, kale (yes, kale), peas, beans, and some tomatoes are starting to color.

It's nice when you are making a veggie burger and are able to step outside to get lettuce for it.

08 Jul 2003 | hurley #1 said...

My theory: Alisha is on vacation. They get like 30 days in non-U.S. countries *sigh*.

Actually I think she came over here to Canada to meet with a client (I remember her saying something about that in one of her posts) and maybe she's been traveling since then.

My balcony garden is doing well in the heat...already enough basil to make a small batch of pesto.

08 Jul 2003 | Don Schenck said...

Faj, ever try making a homemade veggie burger? I wonder how it's done??

08 Jul 2003 | fajalar said...

Never made a veggie burger, but I'll try and let you know. But we do use Seitan (7.75 grams of protien per ounce, and no fat) a lot and I am going to try and make it myself this weekend.

10 Jul 2003 | Phil Wolff said...

I love threads that end in food.

16 Jan 2004 | Walter said...

For example, if you see an AIM window peeking out from behind your browser and you click on it, that window will come to the front, but the main application window will not. The Mail.app/Activity Viewer is another example. The Aqua system of layers works well in many instances, but not in all. Thank goodness that the Dock is always there to come to the rescue. I know that clicking on an application icon in the Dock will always result in not only the application coming to the front, but also any non-minimized windows associated with it. And if the application is active but no windows are open, clicking on the Dock icon should create a new window in that application.

16 Jan 2004 | Peter said...

At WWDC, I listened to Apple representatives make some excellent points about taking the time to build a 100%-compliant Aqua application, and I think all developers need to look beyond the code and listen to what the folks at Apple have to say

04 Nov 2004 | Jimes said...

Hi

27 Nov 2004 | brigitte nielsen nude orgy said...

brigitte nielsen nude orgy
http://brigitte-nielsen-nude.celebrities-portal.info/

31 Jan 2005 | compatelius said...

bocigalingus must be something funny.