Iterative design

  • Started
  • Last post
  • 13 Responses
  • ninjasavant

    Hi Everyone,

    Here's the situation. I work at a large software company. Development has recently started the switch from the waterfall model to an iterative design model for software development. However, most of the designers in my team still work as they always have: put all their energy into creating a total package, delivering, editing, delivering, and so on. It seems we should adjust our design process to become more iterative. Mirror development's efforts by only providing wireframes and color schemes at first, then apply layers of comleteness to the design in a phased cycle. This will take some education probably since some of our designers have been here 20+ years.

    So my question to you is, do any of you have any experience with design process in software development, specifically with the iterative design model or IRUP, or do you know of any good resources to get more info? Sites, books, etc.

    Feel free to send me an email or discuss here. Thanks so much.

    -rob.

  • jfletcher0

    Damnit, I'm actually putting together a site on some of these ideas and work. I wish you asked this 2 weeks from now.

    Yeah, delivering a total package might now work in the iterative world, but before wire or color work, set up clear business and UX goals, vision, and scenarios (among other things). I've been advocating doing this in a product brief. This starts to seem like a lot of process, but if done correctly if can be manageable, and helps the products development in the long run. Instead of opinion battles you have goals to measure against, etc.

    Once you get into wire work, you can evaluate against above goals, do concept/lab/field studies, move onto further feature iteration, etc.

    I can’t type that much in this little window, but it you’re interested in syncing outside of NT on email, I’d be more than happy to go through a more detailed process for product development and design (both visual and interactive)

  • uberdesigner_0

    more buzzwords please

  • jfletcher0

    producing software that people use requires a lot of them.

  • ninjasavant0

    yeah, you have to speak the language to effectively navigate these kind of projects.

  • jfletcher0

    I don't like referring to those as buzzwords because they're only *really buzzwords when people don't know how to effectively use them or know what they mean...this is why they’ve gotten a bad wrap and are made fun of. Crappy web bubble.

  • blaw0

    warning: blanket statement follows.

    iterative design is for folks that can't make up their minds.

    wanna be a manager, project manager, fella/lady that goes to lots of meetings and feels important? fine by me. but step up and make a freakin' decision so work can get done, and done right the first time.

    what's needed to make those decisions? uh... planning, research, meetings, documentation, and a lot of little decisions along the way.

    can't handle the accountability? find another way to spend your day.

    anyone care to ask me how my fuckin' year's going?

  • Teeuwen0

    i'm a Señor Iteratif DeSigner

    i'm a Señor Iterativ DeSigner

    i'm a Señor Iterative Designer

    i'm a Senior Iterative Designer

  • jfletcher0

    blaw - good points (and so often true). The problem occurs often when there is not person in charge of the UI, or for some reason they are afraid to make a decision. I agree, step up and make a call and don’t casue death by iteration. It can also be caused by people believing design is a subjective matter that anyone can do.

    However when I think of iterative design as ninjasavant points out, is more iterative based on usability feedback. There will be iteration from internal team, but if proper leadership is in place, this shouldn't be non stop pointless meeting.

    Point being, someone should be accountable and judicious in making decisions for UI.

  • blaw0

    successful iterative design to me is this:

    a software package providing a defined solution with a specific set of features.

    version two will improve upon version one.

    by the way, we'll have an updated gui and packaging for v2 because it adds value and keeps designers off the street.

  • jfletcher0

    "by the way, we'll have an updated gui and packaging for v2 because it adds value and keeps designers off the street. "

    you forgot new features!

    If you treat a release as an iteration and it bombs from a UX view point, you may have cursed v2.

  • jfletcher0

    Don’t get me wrong, I’m not a fan of an overbearing process. Otherwise people focus so much on the process they forget about the content. The answer is finding the right process for the team...as a manager it’s your job, but there certainly is a point where you go in circles, with meetings where people trumpet “I’ll look into that.” This is when you start to have meetings about meetings.

    However there is something to be said for no usability, and basing work on one talented individual with vision. However it’s rare to find these people.

  • uberdesigner_0

    iterative design gives marketing types and executives chubbies. it let's them play politics, using those who create like pawns

  • ninjasavant0

    Hi all, good discussion goin on here. A little background on what my thoughts are on the process.

    Yes, it would be ideal to get the specs and the functionality and go off and start creating with those guidelines. This increasingly isn't the case with our development cycle. For better or worse visual design is brought in very early during planning phases. What has happened is that our designers kill themselves to turn around an entire UIs worth of design, a complete package, during the beginning stages. Throughout the cycle changes are made to the software, changes are made in the UI, then some dev manager decides he stopped liking any of it and tells the developer to just come up with something and throw away our months of work that was tested and validated.

    We need a way to fit in with this development process. We can flame all we want about how development should get their heads from their asses and start playing ball (and we have) but its just not going to happen.

    I want to define a process whereby the design of the UI happens at the same rate as the whole program (or learn about one that exists). During the research phase we design and deliver wireframes, at the next phase identify color palettes, next phase icon style, etc etc. These are the realities of corporate design teams. Not ideal, but an interesting challenge.