Research, deliverables, process and the team

I was playing around with this fairly stream-of-consciousness kind of diagram to get a clearer picture of how the different types of research and deliverables you do as an IA feed into the process and the team.

The diagram definitely needs work, but I’d like to know how it compares to your practical experience as an IA. I’m not trying to define the perfect process here, just trying to clarify how things work in the messy real world. So if you have comments on how you work in a team, what deliverables and research and processes you find useful / not useful, go ahead!

I haven’t found a good way of showing the iterations and feedback between all the different research and team members yet. The two darker bits are the two main documents for signoff. (Visual design gets signed off as well)

It’s a bit big and messy, but look at it this way, at least it’s not a Venn diagram ;)


0 thoughts on “Research, deliverables, process and the team

  1. The task analysis bit always seems really central – and yet I always found it hard to do: I haven’t come across a great methodology for doing the kind of task analysis that I think I want here… The stuff published by Adaptive Path is pretty nice, but I don’t know, I have this feeling there must be more ways of doing this.

    Then, I’ve also found that for each project (that is different), different types of research and docs work best… Some projects need use cases, whereas for others they don’t work as well… I’d like to figure out what elements of a project influence what types of research/docs/process to use.

  2. Eric Scheid pointed me to this similar diagram:

    They have something called an “Actor Catalog” (never heard of) and also include Use cases (which I should include, go in the tech spec).

    But what spikes my interest (is that English) is that they seem to present this as THE process. In my experience, process really needs to be quite adaptive, and be different for different projects. I’m sure they’d agree, but:

    how do I adapt my process to a project? It’s a very touchy feely thing, I assume most people do it like me and just kindof *know* what elements of the process to use for a certain project.

    It would be interesting to see some analysis on that, types of projects maybe, or other ways of determining what bits of the process to use for a certain project.

  3. Looks good to me? If this is feeding into your book then though I’m familiar with task analysis “use case” means nothing to me and could do with elaboration.
    I like the way iterations are represented.

  4. I don’t think I’ll use it in the book (although related) – it’s too messy.
    I actually don’t really believe in using diagrams to explain stuff (like in the book). But diagrams to help discuss or think about stuff (like here), hell yeah!

    WWFM: what works for me:
    – diagrams: help to discuss stuff (you can point at them and scribble on them), and help to think (just jot down all the elements of the problem and start connecting them)
    – stories: explain stuff, teach. Also: examples are great for this.

  5. When doing the user scenarios, I usually like to make sure the IT lead is also doing the use cases around the same time, for consistency as well as buy in.

    I believe that some of the “data gathering” diamonds are best served at different places along the process. For example, doing a competitive analysis in the beginning can help to form the original business goals. In real life, I’ve only seen this happen once, but I think it should happen more.

    I really like that you put in a “prioritization exercise”. I believe this particular area of exercises is becoming more and more important as we phase projects. Whether IA or business analysts do it, it is a distinct regrouping of all the prior analysis and specifically leads into the first build phase, thus, mandatory.

  6. When I saw the diagram I cound not resist laughing! There’s probally a lot more which could be added to chart the ‘Real World’ mess of the design development process. There’s a great deal more time involved on projects than many dare to omit! I know microsoft had put out some documentation covering this subject! I spent over two weeks reorganizing the Design and Development processes for a company I worked for!

    I was the Lead Developer or Person in Charge of Development and managed 5 other programmers. My Employer and I ended up odds over this matter!

    He was more of the Factory Worker Mind set! If he did not see everybody writing lines of code, then they were wasting time! When things went wrong he would get very upset with everybody! I know on Several Occasions we had to correct errors in the main programming logic, or redesign important sections.

    Guess who ended up putting out the fires? Me, because I was in charge the everything. I would seclude myself for several hours, with a stack of print outs, paper for making notes, and go to the “Smoking Room” which included a White Board!
    I would have to go back through everything and rethink it, often taking a break to call up or consult with the client or fellow co-worker!
    Mind you I had to make rounds to make certain that everybody was busy doing something to maintain the “Factory Like” illusion!

    Why? Because the projects were never allocated enough time in the planning stages! The only saving grace was the fact that we were working with a modular code framework that I had developed for the company! That saved a lot of time in Development! When you have precanned code and frameworks to follow!

    We were cranking out code that would have normally taken others 10 times as long to complete! The Joys of Polymorphic coding, OOP and what not!

    In the end I left my job! and so did many of my co-workers! We got tired of reworking the code, not being organized and dealing with our employers rigid mindset!

    Development is not Like Factory Work!!!

    Thank God, my Employeer was in the business of Designing and Building custom built houses! Because it’s easier to replace 100 lines of code
    then it is to relocate a support wall of a house!

    I am much happier now, I have been doing ‘Freelance’ work!

  7. I saw Alan Cooper on Tech-TV the other night! He’s the father of Visual Basic! He was covering User Interfaces, and he had a lot of great information about the design process! Goal–Directed Design, as a matter of fact! He has a book out called

    “About Face”
    The Essentials of User Interface Design
    ISBN: 1568843224M

    After watching him on TV and visiting his website, think this book should be a worth wild investment!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s