Loading ...
Sorry, an error occurred while loading the content.
 

On the Communication between Planner, Designer, and Developer

Expand Messages
  • June Kim
    Following is email I sent to Jeff but I suppose it didn t make it to him. I think it would be better to post it to a larger audience and ask for help. ...
    Message 1 of 26 , May 7, 2006
      Following is email I sent to Jeff but I suppose it didn't make it to
      him. I think it would be better to post it to a larger audience and
      ask for help.

      ---------- Forwarded message ----------
      From: June Kim
      Date: Apr 19, 2006 5:08 PM
      Subject: On the Communication between Planner, Designer, and Developer
      [snip]

      BTW, I just want to ask some comments from you. I would greatly
      appreciate your opinion or any reference you could afford me.

      As I told you I am coaching a few major web portal companies in Korea.
      They have half a thousand developers and a few hundreds of designers
      and planners. Oh, the job title, "planner". I think you are
      unfamiliar with that job title. In Korea, we call those people who invent
      and plan the web service(product manager?) as planners. They invent
      the concepts and ideas and then draw storyboards and sometimes
      organize the team and arrange the schedule, being the mediator between
      designers and developers. Usually they do managing, though not perfectly always,
      too.

      Most of them communicate through documents; what they call "help"s.
      Help is a power point file with almost-close-to-the-real snapshots of
      the whole service, along with some comments with red lines, boxes,
      arrows and texts. For example, on a page for login, the page shows the
      web page as-will-be-developed with some marks like, "this button is
      300x200 pixels with color code #AB00CD" blahblah... One help file is
      usually more than a 50 pages, depending on the size of the project.

      When they come to have a initial meeting the planner prints the help
      file and bring it together and talk with the printouts. Developers and
      designers(usually not present at the same time) take notes on the help
      print outs they've got.

      Now, it see some wastes and places to improve. Major time of planners
      are spent on making(and modifying later) the help files. I guess more
      than 70% of their time. Since they are all basically separate
      teams(designer team, developer team, planner team -- being functional
      and nominally matrix organization, they have temporary project-task-force
      for a short while), they do need some sort of communication media
      and help file is it.

      What experience do you have when it comes to the
      communication/documentation for the collaboration between the three
      parties, and what would you recommend for substitutes for the
      laborious and wasteful, and too-detailed help files?

      June Kim
      --------------------------------

      As an addition to the original email, I would add:

      I think there are many levels of communication channels and media
      between functional parties(developers, designers, planners). I believe
      selective usage of those levels leads to cost-effective communication.
      For one instance of dimensions, from lo-fi to hi-fi, there is a
      spectrum:
      * thoughts
      * scribbles
      * white-board (w/ some post-its?)
      * paper-prototype
      * electronic paper-prototype like SILK and DENIM
      (look at http://dub.washington.edu/denim/ and especially the demo video)
      (compare fig 1 and 2 from http://www.francisli.com/portfolio/denim.html)
      * html/ppt prototypes (w/ or w/o javascript for interaction)
      * flash
      * scripting languages (ruby, python, jython, ...)
      * Java and friends

      What experiences do you have with these?

      June
    • June Kim
      Maybe it would be helpful for you to give me concrete advices if I add some constraints. I had a great success using paper-prototyping and scripting
      Message 2 of 26 , May 7, 2006
        Maybe it would be helpful for you to give me concrete advices if I add
        some constraints.

        I had a great success using paper-prototyping and scripting
        languages(jython and then replacing python classes into java's
        incrementally) as feedback methods between the three parties, with the
        constraint that all of them were in a same room and they were not
        required to make documentation to communicate with the outer world.

        Now, suppose big organizational change is difficult and painful, if
        not impossible.

        Designers, planners, and developers each reside in different places of
        a same building; some on the same floor and some on different floors.
        They can have meetings (I guess) daily, though. There is always
        responsibility and accountability problem.


        On 5/8/06, June Kim <juneaftn@...> wrote:
        > Following is email I sent to Jeff but I suppose it didn't make it to
        > him. I think it would be better to post it to a larger audience and
        > ask for help.
        >
        > ---------- Forwarded message ----------
        > From: June Kim
        > Date: Apr 19, 2006 5:08 PM
        > Subject: On the Communication between Planner, Designer, and Developer
        > [snip]
        >
        > BTW, I just want to ask some comments from you. I would greatly
        > appreciate your opinion or any reference you could afford me.
        >
        > As I told you I am coaching a few major web portal companies in Korea.
        > They have half a thousand developers and a few hundreds of designers
        > and planners. Oh, the job title, "planner". I think you are
        > unfamiliar with that job title. In Korea, we call those people who invent
        > and plan the web service(product manager?) as planners. They invent
        > the concepts and ideas and then draw storyboards and sometimes
        > organize the team and arrange the schedule, being the mediator between
        > designers and developers. Usually they do managing, though not perfectly always,
        > too.
        >
        > Most of them communicate through documents; what they call "help"s.
        > Help is a power point file with almost-close-to-the-real snapshots of
        > the whole service, along with some comments with red lines, boxes,
        > arrows and texts. For example, on a page for login, the page shows the
        > web page as-will-be-developed with some marks like, "this button is
        > 300x200 pixels with color code #AB00CD" blahblah... One help file is
        > usually more than a 50 pages, depending on the size of the project.
        >
        > When they come to have a initial meeting the planner prints the help
        > file and bring it together and talk with the printouts. Developers and
        > designers(usually not present at the same time) take notes on the help
        > print outs they've got.
        >
        > Now, it see some wastes and places to improve. Major time of planners
        > are spent on making(and modifying later) the help files. I guess more
        > than 70% of their time. Since they are all basically separate
        > teams(designer team, developer team, planner team -- being functional
        > and nominally matrix organization, they have temporary project-task-force
        > for a short while), they do need some sort of communication media
        > and help file is it.
        >
        > What experience do you have when it comes to the
        > communication/documentation for the collaboration between the three
        > parties, and what would you recommend for substitutes for the
        > laborious and wasteful, and too-detailed help files?
        >
        > June Kim
        > --------------------------------
        >
        > As an addition to the original email, I would add:
        >
        > I think there are many levels of communication channels and media
        > between functional parties(developers, designers, planners). I believe
        > selective usage of those levels leads to cost-effective communication.
        > For one instance of dimensions, from lo-fi to hi-fi, there is a
        > spectrum:
        > * thoughts
        > * scribbles
        > * white-board (w/ some post-its?)
        > * paper-prototype
        > * electronic paper-prototype like SILK and DENIM
        > (look at http://dub.washington.edu/denim/ and especially the demo video)
        > (compare fig 1 and 2 from http://www.francisli.com/portfolio/denim.html)
        > * html/ppt prototypes (w/ or w/o javascript for interaction)
        > * flash
        > * scripting languages (ruby, python, jython, ...)
        > * Java and friends
        >
        > What experiences do you have with these?
        >
        > June
        >
      • Dave Churchville
        ... If I understand correctly, you re looking for a way to scale some of the techniques you currently use with a team that s co-located (all in the same place)
        Message 3 of 26 , May 8, 2006
          --- In agile-usability@yahoogroups.com, "June Kim" <juneaftn@...> wrote:
          > I had a great success using paper-prototyping and scripting
          > languages(jython and then replacing python classes into java's
          > incrementally) as feedback methods between the three parties, with the
          > constraint that all of them were in a same room and they were not
          > required to make documentation to communicate with the outer world.
          >
          > Now, suppose big organizational change is difficult and painful, if
          > not impossible.
          >
          > Designers, planners, and developers each reside in different places of
          > a same building; some on the same floor and some on different floors.

          If I understand correctly, you're looking for a way to scale some of
          the techniques you currently use with a team that's co-located (all in
          the same place) with a more distributed team (even though they're in
          the same building).

          I've had to deal with this kind of thing (prototyping as a way to
          communicate between groups) in a true distributed environment
          (customers on the East coast, developers on the West). Actually, my
          company developed a product to make this kind of thing easier, because
          we had a lot of frustrating miscommunication using just static
          documents (like you describe).

          I've got a couple of blog entries on this subject, and you can find
          more info on the tool we created as well:

          http://www.extremeplanner.com/blog/2006/02/agile-prototyping-part-1.html
          http://www.extremeplanner.com/blog/2006/04/agile-prototyping-part-2.html

          --Dave
          http://www.extremeplanner.com/blog
        • Ron Jeffries
          ... I have no experience at all in a situation like the one you describe, with large numbers of designers communicating with what sound like very detailed
          Message 4 of 26 , May 8, 2006
            On Monday, May 8, 2006, at 12:26:34 AM, June Kim wrote:

            > What experience do you have when it comes to the
            > communication/documentation for the collaboration between the three
            > parties, and what would you recommend for substitutes for the
            > laborious and wasteful, and too-detailed help files?

            I have no experience at all in a situation like the one you
            describe, with large numbers of designers communicating with what
            sound like very detailed "help" files. That said:

            I'd be guided by the material in Constantine and Lockwood,
            especially regarding paper prototypes.

            I'd be inclined to put a designer or two with each small team that
            was going to build some part of the system, instead of having them
            all off somewhere on their own.

            I'd be inclined to have the designers draw on the whiteboard or
            paper, rather than waste time with all this detail.

            I'd be inclined to set up standards rather than repeat details of
            button sizes and colors again and again.

            Ron Jeffries
            www.XProgramming.com
            Comments lie. Code doesn't.
          • Ron Jeffries
            ... As a frill on what Larry says here, I d advise the use of style sheets and configuration tables and compiler constants and all the techniques I know to
            Message 5 of 26 , May 8, 2006
              On Monday, May 8, 2006, at 4:34:59 PM, Larry Constantine wrote:

              > (2) Definitely do a style guide, as Ron suggests, but only in provisional
              > form at the start of the project. Treat it as evolving through iterative
              > refinement just like any other project artifact. You will only learn what
              > the standards should have been as the design evolves and expands.

              As a frill on what Larry says here, I'd advise the use of style
              sheets and configuration tables and compiler constants and all the
              techniques I know to allow as many as possible of these things to
              change.

              Who knows ... STANDARD_BUTTON_WIDTH, BIG_BUTTON_HEIGHT, ALERT_COLOR,
              ... anything to abstract out the ideas that the designers are
              developing, so that when they decide that pink letters on an orange
              background aren't so good after all, we can just tweak a couple
              values and rebuild.

              Ron Jeffries
              www.XProgramming.com
              It's easier to act your way into a new way of thinking
              than to think your way into a new way of acting. --Millard Fuller
            • Larry Constantine
              These are a couple of general questions for the group about e-etiquette prompted not by any one posting but by a number of them over recent months. What do you
              Message 6 of 26 , May 8, 2006
                These are a couple of general questions for the group about e-etiquette
                prompted not by any one posting but by a number of them over recent months.

                What do you all think of using postings on the group to drive traffic to a
                separate blog as opposed to saying what you have to say here?

                What do you think about promoting product sales via postings?

                --Larry Constantine, IDSA
              • Larry Constantine
                June Kim, Having had experience on humongous projects with vast hoards of designers and developers, let me underscore Ron s suggestions and toss in a twist or
                Message 7 of 26 , May 8, 2006
                  June Kim,

                  Having had experience on humongous projects with vast hoards of designers
                  and developers, let me underscore Ron's suggestions and toss in a twist or
                  three. Collaboration beats communication any day. A designer with each
                  development team works, so does a developer with each design team. Do use
                  whiteboards to explore and work out designs, but digitize (either with
                  capture bars like Mimio (mimio.com)or with digital camera and
                  WhiteboardPhoto for archiving, rapid distribution.

                  (1) Get the UI architecture thoroughly thought out first. Try to work out a
                  complete navigation map and have wireframe schematics, templates, or
                  abstract prototypes for main page/screen types. Treat all of these as
                  provisional and subject to iterative refinement.

                  (2) Definitely do a style guide, as Ron suggests, but only in provisional
                  form at the start of the project. Treat it as evolving through iterative
                  refinement just like any other project artifact. You will only learn what
                  the standards should have been as the design evolves and expands.

                  (3) Regardless of official structure, act *as if* all the participants were
                  part of a common team or team of teams. Consider guerilla tactics that
                  promote that sense, such as encouraging direct communication across
                  divisional and hierarchical lines, inviting broad participation in design
                  reviews, "broadcasting" key milestones or decisions, etc.

                  (4) On one project of this sort, we organized a design "S.W.A.T. team" that
                  had ownership of the evolving UI guide, took on the toughest design problems
                  or those with the broadest impact on the results, and served as rapid
                  deployment consultants to other designers and developers. You want your 3-5
                  best, most adaptable, designers on such a team.

                  (5) Regardless of how designers might be distributed or working
                  independently, keep them coordinated and in touch with each other, reviewing
                  and giving feedback on each other's work, etc. Encourage consultation and
                  mutual help. Have frequent, short, problem-focused meetings. Such things
                  will often go further than standards to promote common look-and-feel. People
                  need to see each others work.

                  --Larry Constantine, IDSA
                • Ron Jeffries
                  ... I prefer to read conversation here and am perfectly happy to read articles and blogs if they are germane. (I am also inclined to point to articles on my
                  Message 8 of 26 , May 8, 2006
                    On Monday, May 8, 2006, at 4:34:59 PM, Larry Constantine wrote:

                    > What do you all think of using postings on the group to drive traffic to a
                    > separate blog as opposed to saying what you have to say here?

                    I prefer to read conversation here and am perfectly happy to read
                    articles and blogs if they are germane. (I am also inclined to point
                    to articles on my own site if they're germane.)

                    > What do you think about promoting product sales via postings?

                    If someone occasionally posts something salesy, but is generally a
                    good contributor, I don't mind it. When someone comes on with
                    nothing to offer but sales, I dislike it intensely.

                    <smile>
                    Contact me via email for agile consulting, and don't forget to read
                    my recently unearthed article: We Tried Baseball and It Didn't Work,
                    at http://www.xprogramming.com/xpmag/jatBaseball.htm .
                    </smile>

                    Ron Jeffries
                    www.XProgramming.com
                    Reason is and ought only to be the slave of the passions. -- David Hume
                  • Phlip
                    ... Dude, I laughed so hard I wet my blog. -- Phlip http://www.greencheese.us/ZeekLand
                    Message 9 of 26 , May 8, 2006
                      Ron Jeffries wrote:

                      > ...read
                      > my recently unearthed article: We Tried Baseball and It Didn't Work,
                      > at http://www.xprogramming.com/xpmag/jatBaseball.htm .

                      Dude, I laughed so hard I wet my blog.

                      --
                      Phlip
                      http://www.greencheese.us/ZeekLand <-- NOT a blog!!
                    • Ron Jeffries
                      ... Thanks! I take that as high praise coming from you. Ron Jeffries www.XProgramming.com You do ill if you praise, but worse if you censure, what you do not
                      Message 10 of 26 , May 8, 2006
                        On Monday, May 8, 2006, at 5:02:31 PM, Phlip wrote:

                        >> ...read
                        >> my recently unearthed article: We Tried Baseball and It Didn't Work,
                        >> at http://www.xprogramming.com/xpmag/jatBaseball.htm .

                        > Dude, I laughed so hard I wet my blog.

                        Thanks! I take that as high praise coming from you.

                        Ron Jeffries
                        www.XProgramming.com
                        You do ill if you praise, but worse if you censure,
                        what you do not understand. --Leonardo da Vinci
                      • Jared M. Spool
                        ... This sounds to me more like a design pattern library than a style guide. It s more than a semantic issue, in that a pattern library is easily developed as
                        Message 11 of 26 , May 8, 2006
                          At 04:34 PM 5/8/2006, Larry Constantine wrote:
                          >(2) Definitely do a style guide, as Ron suggests, but only in provisional
                          >form at the start of the project. Treat it as evolving through iterative
                          >refinement just like any other project artifact. You will only learn what
                          >the standards should have been as the design evolves and expands.

                          This sounds to me more like a design pattern library than a style guide.
                          It's more than a semantic issue, in that a pattern library is easily
                          developed as a group activity (aka your swat team) and more extensible
                          across multiple projects.

                          More thoughts on Patterns for those who are interested:
                          http://www.uie.com/events/roadshow/articles/design_patterns/
                          http://www.uie.com/articles/elements_of_a_design_pattern/

                          Jared


                          Jared M. Spool, Founding Principal, User Interface Engineering
                          510 Turnpike Street, Suite 102, North Andover, MA 01845
                          978 327-5561 jspool@... http://www.uie.com
                          Blog: http://www.uie.com/brainsparks
                        • Sue Heim
                          My own personal opinion is that I would much prefer to read posts here, and not read posts about blogs. And again, my own opinion is product postings are fine
                          Message 12 of 26 , May 8, 2006

                            My own personal opinion  is that I would much prefer to read posts here, and not read posts about blogs. And again, my own opinion is product postings are fine as long as they are a) identified as such, and b) the poster actually contributes more than just posts about those products. There are a couple of groups to which I belong and one of them is quite strict about requiring vendors to identify themselves as such. And there's another one that requires folks to preface "ANN" on the subject line, but that same group also is starting to unsub those folks who post only announcements.

                             

                            My two cents. Of course, traffic here is usually lighter than any of those groups I mentioned! :)

                             

                            I would just hate to see this place turn into a big giant sales pitch (be it for product or a personal blog). ;)

                             

                            ...sue


                            > To: agile-usability@yahoogroups.com
                            > From: lconstantine@...
                            > Date: Mon, 8 May 2006 15:34:59 -0500
                            > Subject: [agile-usability] Group Protocol
                            >
                            > These are a couple of general questions for the group about e-etiquette
                            > prompted not by any one posting but by a number of them over recent months.
                            >
                            > What do you all think of using postings on the group to drive traffic to a
                            > separate blog as opposed to saying what you have to say here?
                            >
                            > What do you think about promoting product sales via postings?

                          • June Kim
                            On 5/9/06, Larry Constantine wrote: [snip] ... Are you recommending a developer with each design team ? (I didn t quite get it) ...
                            Message 13 of 26 , May 8, 2006
                              On 5/9/06, Larry Constantine <lconstantine@...> wrote:
                              [snip]
                              >A designer with each
                              > development team works, so does a developer with each design team.

                              Are you recommending "a developer with each design team"? (I didn't
                              quite get it)

                              > Do use
                              > whiteboards to explore and work out designs, but digitize (either with
                              > capture bars like Mimio (mimio.com)or with digital camera and
                              > WhiteboardPhoto for archiving, rapid distribution.
                              >
                              > (1) Get the UI architecture thoroughly thought out first. Try to work out a
                              > complete navigation map and have wireframe schematics, templates, or
                              > abstract prototypes for main page/screen types. Treat all of these as
                              > provisional and subject to iterative refinement.

                              If we have now UI architecture laid out in our hands, what can we do?
                              Can we tell any one party to start to work on their role from the UI
                              architecture? Suppose it's the designer. Having the UI architecture,
                              what can he/she actually begin to do? (Usually they are trained to
                              respond only to very detailed visual guides, like "help"s -- and when
                              they see sparse or lo-fi guides instead, they don't start to work on
                              it and wait until they think the design is got fixed)

                              I think what they need is some sort of funnel-down guides that can
                              make them start early and concurrently.

                              BTW, I had an experience of designing a web service with innovative
                              UIs, for example like Magic Lens and Fish Eye style. Fortunately, we
                              worked as a team in a war-room. We were talking about the surface UI
                              from the beginning(our focus was more on the specific UIs) and I think
                              it didn't have a great positive influence on our developers velocity
                              and the code quality.

                              >
                              > (2) Definitely do a style guide, as Ron suggests, but only in provisional
                              > form at the start of the project. Treat it as evolving through iterative
                              > refinement just like any other project artifact. You will only learn what
                              > the standards should have been as the design evolves and expands.

                              Hm... I don't think I got it. Any examples?

                              >
                              > (3) Regardless of official structure, act *as if* all the participants were
                              > part of a common team or team of teams. Consider guerilla tactics that
                              > promote that sense, such as encouraging direct communication across
                              > divisional and hierarchical lines, inviting broad participation in design
                              > reviews, "broadcasting" key milestones or decisions, etc.

                              Yes. I wholeheartedly agree with you and I am trying to achieve that
                              at this time but still finding it quite challenging. For example, in
                              one organization I'm consulting, all the designers in the company are
                              in one department -- let's call it Designers Dept. Each one serves
                              several projects and teams. On the other hand, developers have their
                              own team grouped by the kind of web service they support, and planners
                              also have their own team each team serving a few web services. So
                              there isn't always a one-to-one mapping between developer teams and
                              planner teams, but some developer team and planner team stick together
                              for quite a long time(since their main focus has been a few big
                              services for a long time) and they collaborate better.

                              It's very hard to change their behavior and attitude, when they have
                              never experienced any kind of close collaboration.

                              >
                              > (4) On one project of this sort, we organized a design "S.W.A.T. team" that
                              > had ownership of the evolving UI guide, took on the toughest design problems
                              > or those with the broadest impact on the results, and served as rapid
                              > deployment consultants to other designers and developers. You want your 3-5
                              > best, most adaptable, designers on such a team.
                              >

                              As a separate team and serving other "planner and developer" teams?
                              Wouldn't it slow down the whole process? I'm a bit worried.


                              Thank you.
                            • Sachin Palewar
                              I second Ron on that. Regards, Sachin Palewar Palewar Techno Solutions Pocket PC & Mobile Software Development Nagpur, India
                              Message 14 of 26 , May 8, 2006
                                Message
                                I second Ron on that.
                                 
                                Regards,

                                Sachin Palewar

                                Palewar Techno Solutions
                                Pocket PC & Mobile Software Development
                                Nagpur, India

                                http://www.palewar.com
                                -----Original Message-----
                                From: Ron Jeffries [mailto:ronjeffries@...]
                                Sent: Tuesday, May 09, 2006 2:14 AM
                                To: agile-usability@yahoogroups.com
                                Subject: Re: [agile-usability] Group Protocol

                                On Monday, May 8, 2006, at 4:34:59 PM, Larry Constantine wrote:

                                > What do you all think of using postings on the group to drive traffic to a
                                > separate blog as opposed to saying what you have to say here?

                                I prefer to read conversation here and am perfectly happy to read
                                articles and blogs if they are germane. (I am also inclined to point
                                to articles on my own site if they're germane.)

                                > What do you think about promoting product sales via postings?

                                If someone occasionally posts something salesy, but is generally a
                                good contributor, I don't mind it. When someone comes on with
                                nothing to offer but sales, I dislike it intensely.

                                <smile>
                                Contact me via email for agile consulting, and don't forget to read
                                my recently unearthed article: We Tried Baseball and It Didn't Work,
                                at http://www.xprogramming.com/xpmag/jatBaseball.htm .
                                </smile>

                                Ron Jeffries
                                www.XProgramming.com
                                Reason is and ought only to be the slave of the passions.  -- David Hume

                              • Tim Wright
                                As long as it s postings over recent months not recent hours that are problematic then I m happy - a few a month is fine, a few a day is not. As to posting
                                Message 15 of 26 , May 8, 2006
                                  As long as it's postings over 'recent months' not 'recent hours' that are problematic then I'm happy - a few a month is fine, a few a day is not.

                                  As to posting blog entries, I'm not really a big fan. I kinda feel that mailing lists are to gather advise and ask questions. Blogs are to share experiences. However, on saying that, it doesn't really matter. The quantity on this list is small enough to make little difference and the blog entries tend to be good.

                                  I did like the baseball game. The refactored game actually seemed like fun!

                                  About job advertisements: I like them as it makes the skills discussed on this list seem market-worthy.

                                  About sales pitches: the chances are you're actually advertising to your competitors.

                                  Tim

                                  On 5/9/06, Larry Constantine <lconstantine@...> wrote:
                                  These are a couple of general questions for the group about e-etiquette
                                  prompted not by any one posting but by a number of them over recent months.

                                  What do you all think of using postings on the group to drive traffic to a
                                  separate blog as opposed to saying what you have to say here?

                                  What do you think about promoting product sales via postings?

                                  --Larry Constantine, IDSA






                                  --
                                  Kei te kōrero tiki au. Kei te kōrero tiki koe. Ka kōrero tiki tāua. Kōrero ai tiki tāua.
                                • William Pietri
                                  ... It depends on how spammy they feel to me. If there s a discussion going and somebody refers to a germane post they made last month along with some other
                                  Message 16 of 26 , May 9, 2006
                                    Larry Constantine wrote:
                                    > What do you all think of using postings on the group to drive traffic to a
                                    > separate blog as opposed to saying what you have to say here?
                                    >

                                    It depends on how spammy they feel to me. If there's a discussion going
                                    and somebody refers to a germane post they made last month along with
                                    some other content, I'm happy about that. Announcements of blog posts
                                    generally leave me cold, especially if they are just a link with teaser
                                    text.

                                    > What do you think about promoting product sales via postings?
                                    >

                                    I think a couple of lines in SIGs are fine. I'm also very happy with
                                    people talking about products that they like, even when they get
                                    evangelical about it. Promoting one's own products strikes me as
                                    frequently dubious, and always so when it's from somebody who doesn't
                                    actively participate in the list.


                                    William
                                  • Adrian Howard
                                    On 8 May 2006, at 21:25, Ron Jeffries wrote: [snip] ... [snip] Seconded. Getting the UI abstractions into the code makes things much easier all round. As an
                                    Message 17 of 26 , May 10, 2006
                                      On 8 May 2006, at 21:25, Ron Jeffries wrote:
                                      [snip]
                                      > Who knows ... STANDARD_BUTTON_WIDTH, BIG_BUTTON_HEIGHT, ALERT_COLOR,
                                      > ... anything to abstract out the ideas that the designers are
                                      > developing, so that when they decide that pink letters on an orange
                                      > background aren't so good after all, we can just tweak a couple
                                      > values and rebuild.
                                      [snip]

                                      Seconded. Getting the UI abstractions into the code makes things much
                                      easier all round.

                                      As an aside this is one of the problems with people still working in
                                      a "throw the UI specs over the wall to the developer" mode. When
                                      developers are presented with a bunch of user journeys, wireframes,
                                      etc. without the UX person around to explain /why/ things have been
                                      done in such-and-such a way you don't notice the abstractions, so
                                      they don't make it into the code, so they get mucked about when the
                                      inevitable changes arrive....

                                      Cheers,

                                      Adrian
                                    • Jeff Patton
                                      June, Sorry I didn t get back to you right away. I m sure you understand how non-trivial the situation you describe is – and
                                      Message 18 of 26 , May 10, 2006
                                        <warning - long response>
                                        June,

                                        Sorry I didn't get back to you right away. I'm sure you understand
                                        how non-trivial the situation you describe is – and potentially how
                                        risky that makes giving advice. But, although I've hesitated, I won't
                                        let it stop me.

                                        The pain point or problem I hear you wanting to solve is the large
                                        amount of time planners spend crafting this communication artefact to
                                        designers and developers – so I'll talk about that first. Of course
                                        if you take a hard agile line with all this, you'd do everything you
                                        could to avoid the written communication. You do that by seating the
                                        teams close together, by encouraging them to talk over a whiteboard
                                        whenever possible.

                                        But, this doesn't solve everything.

                                        The planner seems to be performing the role of an interaction designer
                                        [they invent what needs to be built and document the user interaction
                                        and what I think is the visual design]. Concurrently they perform the
                                        role of project manager. Sounds tough. Sounds like a lot of
                                        responsibility for one person. In support of the interaction design
                                        work, they'll still need to work through somehow what the application
                                        should look and behave like. They'll need to model with cards, draw
                                        pictures on whiteboards, build and test paper prototypes. So, they
                                        still need to build something to contain all their own thoughts – even
                                        if it isn't powerpoint. That'll take time.

                                        And, if we encourage the planner to talk more over the whiteboard, and
                                        over their paper prototypes with the designers and developers, that's
                                        going to take lots of time.

                                        So, at the end of the day, we won't give the planners back any more
                                        time – they'll be spending as much or more, but we may reduce some
                                        significant risks of miscommunication caused by reliance on paper
                                        documents. In addition, I think people are ultimately happier when
                                        they can talk… but does this organization place value on "happy"? Do
                                        they perceive any pain caused by miscommunication?

                                        As far as a documentation mechanism goes, right now, I believe
                                        powerpoint works as well as anything. These days I spend more of my
                                        life than I want to admit building powerpoint storyboards. Part of
                                        the reason I prefer it over potentially other tools is that I can
                                        control the fidelity a little bit. By that I mean I can make very
                                        realistic UI when I think the situation demands it, or I can paste in
                                        and manipulate whiteboard photos when they're sufficient – and lots of
                                        points in between. The point is I control the fidelity. But, it
                                        doesn't seem like your planners are working with that "fidelity knob".
                                        Could they be? Would it save them time?

                                        What does come to mind is that the scale of the operation you describe
                                        indicates that building a healthy _community of interest_ is in order.
                                        By that I mean planners need to start regular collaboration with each
                                        other about how they do their job. They need to share techniques,
                                        document and share interaction patterns, basically have the
                                        opportunity to collaborate with each other about how to get better at
                                        what they do. Does this sort of opportunity for planner collaboration
                                        exist in the organization? If not, could it?

                                        Seems like planners could also work in small teams – dividing up work
                                        and building these prototypes faster. I've seen many organizations
                                        that have a design team that feeds and collaborates with development.
                                        Whether they believe they are or not, the BA teams we use at
                                        ThoughtWorks on projects function as a design team. They collaborate
                                        and take collective responsibility for the functionality of the
                                        software, the artefacts they hand to development, and the day to day
                                        communication with development. Could planners work in 2-3 person
                                        teams? Would that help them move faster?

                                        Now, the things that make me twitchy – problems I sense but problems
                                        you didn't express:

                                        How does the planner determine what was needed? How does he research
                                        and understand his users and their needs? How does he validate his
                                        solution is indeed a good one? Seems his life is so dominated by
                                        building powerpoints to keep the project running that he may have
                                        little time to determine if the resulting product is going to be a
                                        good one. That scares me. Issues there would manifest themselves as
                                        projects being completed on time, but end users and customers not
                                        liking what was built. Does that happen?

                                        I'm twitchy about how little the planners seem to collaborate with
                                        anyone on what they doe – end users, developers, each other. I'm
                                        always suspicious of solutions arrived at by individuals working in
                                        isolation with little context on which to solve their problems.

                                        What do you mean by designers? [or did you say and I missed it?]
                                        Are they designing the inside of the system – the architecture-y stuff
                                        – or the outside if the system – the visual and interaction design?
                                        My guess is the former – not the latter. If that's the case, based on
                                        what I'm hearing as constrained collaboration between them and
                                        developers, I suspect problems come out of that too.

                                        Finally, the last piece of advice I could give is think about how
                                        things would look if they were better. What would things look like if
                                        problems were solved? Then given that mental picture of the solution,
                                        what's the first tangible thing you can do/change you can make to move
                                        towards it?

                                        In the future do planners simply spend less time doing powerpoint work
                                        because they have a cool prototyping tool? This brings me back to one
                                        of the first things I asked – what really is the problem here? Is
                                        this really about saving the labour costs/time spent by the planners?
                                        No offence to the planners – but who cares? If you saved them 25% of
                                        their time, would that be significant to the company you work for?
                                        Might the company them be tempted to fire 25% of the planners? The
                                        net result being that their life really isn't any better. Look deeper
                                        to what the problem really is here. Does it take to long to build
                                        product? Is the product quality low? Is it too expense to build
                                        products vs. your competition – do you need to reduce costs overall?
                                        Where is the pain coming from?

                                        Hope that give you some more things to think about – and potentially
                                        some more questions to ask.

                                        Thanks for posting this here to make the discussion public.

                                        -Jeff

                                        --- In agile-usability@yahoogroups.com, "June Kim" <juneaftn@...> wrote:
                                        >
                                        > Following is email I sent to Jeff but I suppose it didn't make it to
                                        > him. I think it would be better to post it to a larger audience and
                                        > ask for help.
                                        >
                                        > ---------- Forwarded message ----------
                                        > From: June Kim
                                        > Date: Apr 19, 2006 5:08 PM
                                        > Subject: On the Communication between Planner, Designer, and Developer
                                        > [snip]
                                        >
                                        > BTW, I just want to ask some comments from you. I would greatly
                                        > appreciate your opinion or any reference you could afford me.
                                        >
                                        > As I told you I am coaching a few major web portal companies in Korea.
                                        > They have half a thousand developers and a few hundreds of designers
                                        > and planners. Oh, the job title, "planner". I think you are
                                        > unfamiliar with that job title. In Korea, we call those people who
                                        invent
                                        > and plan the web service(product manager?) as planners. They invent
                                        > the concepts and ideas and then draw storyboards and sometimes
                                        > organize the team and arrange the schedule, being the mediator between
                                        > designers and developers.
                                        ...
                                      • Jeff Patton
                                        ... Ditto! There s been lots of talk about how you can t refactor UI. By that developers mean that refactoring UI code is hard. Well I suppose it is - but
                                        Message 19 of 26 , May 10, 2006
                                          --- In agile-usability@yahoogroups.com, Adrian Howard <adrianh@...> wrote:
                                          >
                                          >
                                          > On 8 May 2006, at 21:25, Ron Jeffries wrote:
                                          > [snip]
                                          > > Who knows ... STANDARD_BUTTON_WIDTH, BIG_BUTTON_HEIGHT, ALERT_COLOR,
                                          > > ... anything to abstract out the ideas that the designers are
                                          > > developing, so that when they decide that pink letters on an orange
                                          > > background aren't so good after all, we can just tweak a couple
                                          > > values and rebuild.
                                          > [snip]
                                          >
                                          > Seconded. Getting the UI abstractions into the code makes things much
                                          > easier all round.

                                          Ditto!

                                          There's been lots of talk about how you can't refactor UI. By that
                                          developers mean that refactoring UI code is hard. Well I suppose it
                                          is - but it's extra hard to refactor code when the concepts in the UI
                                          aren't reflected in the code. I've found that when the UI concepts
                                          arrive in the code as first class objects, changing details about
                                          those concepts is easier. By that I mean changing/refactoring the UI.

                                          Throwing anything over a wall injects risk into a project. UI to
                                          developers is just another wall.

                                          [Live from London]
                                          -Jeff
                                        • Jared M. Spool
                                          ... Dare I make the Patterns war cry again? Jared Jared M. Spool, Founding Principal, User Interface Engineering 510 Turnpike Street, Suite 102, North
                                          Message 20 of 26 , May 10, 2006
                                            >On 8 May 2006, at 21:25, Ron Jeffries wrote:
                                            >[snip]
                                            > > Who knows ... STANDARD_BUTTON_WIDTH, BIG_BUTTON_HEIGHT, ALERT_COLOR,
                                            > > ... anything to abstract out the ideas that the designers are
                                            > > developing, so that when they decide that pink letters on an orange
                                            > > background aren't so good after all, we can just tweak a couple
                                            > > values and rebuild.
                                            >[snip]

                                            At 08:03 AM 5/10/2006, Adrian Howard wrote:

                                            >Seconded. Getting the UI abstractions into the code makes things much
                                            >easier all round.
                                            >
                                            >As an aside this is one of the problems with people still working in
                                            >a "throw the UI specs over the wall to the developer" mode. When
                                            >developers are presented with a bunch of user journeys, wireframes,
                                            >etc. without the UX person around to explain /why/ things have been
                                            >done in such-and-such a way you don't notice the abstractions, so
                                            >they don't make it into the code, so they get mucked about when the
                                            >inevitable changes arrive....

                                            Dare I make the "Patterns" war cry again?

                                            Jared


                                            Jared M. Spool, Founding Principal, User Interface Engineering
                                            510 Turnpike Street, Suite 102, North Andover, MA 01845
                                            978 327-5561 jspool@... http://www.uie.com
                                            Blog: http://www.uie.com/brainsparks
                                          • Adrian Howard
                                            On 10 May 2006, at 14:05, Jeff Patton wrote: [snip] ... [snip] I m pleasantly surprised how many XP coding practices fall nicely into place when you take the
                                            Message 21 of 26 , May 10, 2006
                                              On 10 May 2006, at 14:05, Jeff Patton wrote:
                                              [snip]
                                              > There's been lots of talk about how you can't refactor UI. By that
                                              > developers mean that refactoring UI code is hard. Well I suppose it
                                              > is - but it's extra hard to refactor code when the concepts in the UI
                                              > aren't reflected in the code. I've found that when the UI concepts
                                              > arrive in the code as first class objects, changing details about
                                              > those concepts is easier. By that I mean changing/refactoring the UI.
                                              [snip]

                                              I'm pleasantly surprised how many XP "coding" practices fall nicely
                                              into place when you take the UI into account. I rambled about this a
                                              little last year (http://groups.yahoo.com/group/agile-usability/
                                              message/1373).

                                              Adrian
                                            • Adrian Howard
                                              On 10 May 2006, at 14:35, Jared M. Spool wrote: [snip] ... [snip] ... I m thinking more of application-specific UI abstractions - and they don t seem to fit
                                              Message 22 of 26 , May 10, 2006
                                                On 10 May 2006, at 14:35, Jared M. Spool wrote:
                                                [snip]
                                                > At 08:03 AM 5/10/2006, Adrian Howard wrote:
                                                [snip]
                                                >> As an aside this is one of the problems with people still working in
                                                >> a "throw the UI specs over the wall to the developer" mode. When
                                                >> developers are presented with a bunch of user journeys, wireframes,
                                                >> etc. without the UX person around to explain /why/ things have been
                                                >> done in such-and-such a way you don't notice the abstractions, so
                                                >> they don't make it into the code, so they get mucked about when the
                                                >> inevitable changes arrive....
                                                >
                                                > Dare I make the "Patterns" war cry again?

                                                I'm thinking more of application-specific UI abstractions - and they
                                                don't seem to fit under the pattern banner to me.... am I wrong?

                                                Adrian
                                              • Jared M. Spool
                                                ... I think UI patterns could work in an application-specific manner. They take the abstractions you are talking about and add other descriptive components,
                                                Message 23 of 26 , May 10, 2006
                                                  At 09:59 AM 5/10/2006, Adrian Howard wrote:

                                                  > > At 08:03 AM 5/10/2006, Adrian Howard wrote:
                                                  >[snip]
                                                  > >> As an aside this is one of the problems with people still working in
                                                  > >> a "throw the UI specs over the wall to the developer" mode. When
                                                  > >> developers are presented with a bunch of user journeys, wireframes,
                                                  > >> etc. without the UX person around to explain /why/ things have been
                                                  > >> done in such-and-such a way you don't notice the abstractions, so
                                                  > >> they don't make it into the code, so they get mucked about when the
                                                  > >> inevitable changes arrive....
                                                  > >
                                                  >On 10 May 2006, at 14:35, Jared M. Spool wrote:
                                                  > > Dare I make the "Patterns" war cry again?
                                                  >
                                                  >I'm thinking more of application-specific UI abstractions - and they
                                                  >don't seem to fit under the pattern banner to me.... am I wrong?

                                                  I think UI patterns could work in an application-specific manner. They take
                                                  the abstractions you are talking about and add other descriptive
                                                  components, such as the context of use, history, and other required patterns.

                                                  I'm thinking by making your patterns align with the UI abstractions, you
                                                  get more mileage for not much more effort.

                                                  Jared


                                                  Jared M. Spool, Founding Principal, User Interface Engineering
                                                  510 Turnpike Street, Suite 102, North Andover, MA 01845
                                                  978 327-5561 jspool@... http://www.uie.com
                                                  Blog: http://www.uie.com/brainsparks
                                                • Adrian Howard
                                                  ... [snip] ... Oh yes, I quite agree. It s more a question of nomenclature. Once you add a bunch of application specific detail to them is it really right to
                                                  Message 24 of 26 , May 11, 2006
                                                    On 10 May 2006, at 17:16, Jared M. Spool wrote:

                                                    > At 09:59 AM 5/10/2006, Adrian Howard wrote:
                                                    [snip]
                                                    >> I'm thinking more of application-specific UI abstractions - and they
                                                    >> don't seem to fit under the pattern banner to me.... am I wrong?
                                                    >
                                                    > I think UI patterns could work in an application-specific manner.
                                                    > They take
                                                    > the abstractions you are talking about and add other descriptive
                                                    > components, such as the context of use, history, and other required
                                                    > patterns.
                                                    >
                                                    > I'm thinking by making your patterns align with the UI
                                                    > abstractions, you
                                                    > get more mileage for not much more effort.

                                                    Oh yes, I quite agree. It's more a question of nomenclature. Once you
                                                    add a bunch of application specific detail to them is it really right
                                                    to carry on calling them patterns? Haven't they then lost the generic
                                                    nature that the name implies?

                                                    Adrian
                                                  • June Kim
                                                    ... That s OK. I really appreciate your long and detailed response. ... They initially devise and propose the core idea of the service. They do strategic
                                                    Message 25 of 26 , May 11, 2006
                                                      2006/5/10, Jeff Patton <jpatton@...>:
                                                      > <warning - long response>
                                                      > June,
                                                      >
                                                      > Sorry I didn't get back to you right away. I'm sure you understand

                                                      That's OK. I really appreciate your long and detailed response.

                                                      > how non-trivial the situation you describe is – and potentially how
                                                      > risky that makes giving advice. But, although I've hesitated, I won't
                                                      > let it stop me.
                                                      >
                                                      > The pain point or problem I hear you wanting to solve is the large
                                                      > amount of time planners spend crafting this communication artefact to
                                                      > designers and developers – so I'll talk about that first. Of course
                                                      > if you take a hard agile line with all this, you'd do everything you
                                                      > could to avoid the written communication. You do that by seating the
                                                      > teams close together, by encouraging them to talk over a whiteboard
                                                      > whenever possible.
                                                      >
                                                      > But, this doesn't solve everything.
                                                      >
                                                      > The planner seems to be performing the role of an interaction designer
                                                      > [they invent what needs to be built and document the user interaction
                                                      > and what I think is the visual design]. Concurrently they perform the
                                                      > role of project manager. Sounds tough. Sounds like a lot of

                                                      They initially devise and propose the core idea of the service. They
                                                      do strategic planning for the web service also; thinking about the
                                                      positions of the web service in the company's whole web services
                                                      portfolio, SWOT analysis, benchmarking other rival services, sometimes
                                                      coming up with marketing plan and etc. And usually there is a process
                                                      that the planner should do the presentation in front of executives to
                                                      persuade them into allowing the service.

                                                      > responsibility for one person. In support of the interaction design
                                                      > work, they'll still need to work through somehow what the application
                                                      > should look and behave like. They'll need to model with cards, draw
                                                      > pictures on whiteboards, build and test paper prototypes. So, they
                                                      > still need to build something to contain all their own thoughts – even
                                                      > if it isn't powerpoint. That'll take time.
                                                      >
                                                      > And, if we encourage the planner to talk more over the whiteboard, and
                                                      > over their paper prototypes with the designers and developers, that's
                                                      > going to take lots of time.
                                                      >
                                                      > So, at the end of the day, we won't give the planners back any more
                                                      > time – they'll be spending as much or more, but we may reduce some
                                                      > significant risks of miscommunication caused by reliance on paper
                                                      > documents. In addition, I think people are ultimately happier when
                                                      > they can talk… but does this organization place value on "happy"? Do
                                                      > they perceive any pain caused by miscommunication?
                                                      >
                                                      > As far as a documentation mechanism goes, right now, I believe
                                                      > powerpoint works as well as anything. These days I spend more of my
                                                      > life than I want to admit building powerpoint storyboards. Part of
                                                      > the reason I prefer it over potentially other tools is that I can
                                                      > control the fidelity a little bit. By that I mean I can make very
                                                      > realistic UI when I think the situation demands it, or I can paste in
                                                      > and manipulate whiteboard photos when they're sufficient – and lots of
                                                      > points in between. The point is I control the fidelity. But, it
                                                      > doesn't seem like your planners are working with that "fidelity knob".
                                                      > Could they be? Would it save them time?

                                                      Enlightening! I never thought I could lower the fidelity in the
                                                      power-point. Of course, we could even use varying levels of fidelity
                                                      in a same power-point file, depending on the significance and needs.

                                                      I did some instruction on paper prototyping to a few teams(developer
                                                      teams and planner teams), and they were very interested in the
                                                      technique and Guindon's idea of opportunistic design(top-down and
                                                      bottom-up).

                                                      I totally agree that fidelity knob is very important. Thanks for
                                                      pointing this out.

                                                      >
                                                      > What does come to mind is that the scale of the operation you describe
                                                      > indicates that building a healthy _community of interest_ is in order.
                                                      > By that I mean planners need to start regular collaboration with each
                                                      > other about how they do their job. They need to share techniques,
                                                      > document and share interaction patterns, basically have the
                                                      > opportunity to collaborate with each other about how to get better at
                                                      > what they do. Does this sort of opportunity for planner collaboration
                                                      > exist in the organization? If not, could it?

                                                      I am trying to nudge in. With a few teams, I came to the point where
                                                      the planner team and developer team became willing to collaborate
                                                      (like agile planning) but still the designer dept is the problem.
                                                      There is a political issue, and a mentality issue.


                                                      >
                                                      > Seems like planners could also work in small teams – dividing up work
                                                      > and building these prototypes faster. I've seen many organizations
                                                      > that have a design team that feeds and collaborates with development.
                                                      > Whether they believe they are or not, the BA teams we use at

                                                      What are the BA teams?

                                                      > ThoughtWorks on projects function as a design team. They collaborate
                                                      > and take collective responsibility for the functionality of the
                                                      > software, the artefacts they hand to development, and the day to day
                                                      > communication with development. Could planners work in 2-3 person
                                                      > teams? Would that help them move faster?

                                                      They could in some fortunate teams, and it would make them move
                                                      faster. But there are planner teams that take responsibility for
                                                      almost 100 services(24 x 7) with 10 people, each one serving 10
                                                      services. They make a new event for their services, plan renewal ,
                                                      resolve customer dissatisfaction and etc. For such a team, that kind
                                                      of move might not be feasible, well, in the shorter term

                                                      >
                                                      > Now, the things that make me twitchy – problems I sense but problems
                                                      > you didn't express:
                                                      >
                                                      > How does the planner determine what was needed? How does he research
                                                      > and understand his users and their needs? How does he validate his
                                                      > solution is indeed a good one? Seems his life is so dominated by
                                                      > building powerpoints to keep the project running that he may have
                                                      > little time to determine if the resulting product is going to be a
                                                      > good one. That scares me. Issues there would manifest themselves as
                                                      > projects being completed on time, but end users and customers not
                                                      > liking what was built. Does that happen?
                                                      >

                                                      I would say yes. I think they do mostly speculative researches.
                                                      Conceptual design?

                                                      > I'm twitchy about how little the planners seem to collaborate with
                                                      > anyone on what they doe – end users, developers, each other. I'm
                                                      > always suspicious of solutions arrived at by individuals working in
                                                      > isolation with little context on which to solve their problems.
                                                      >
                                                      > What do you mean by designers? [or did you say and I missed it?]

                                                      They are graphic designers. Planners plan the service, developers
                                                      implement the "blue-print" and designers do all the artistic parts,
                                                      like drawing jpg images, choosing specific colors for buttons, and
                                                      even coding html. They have not much room to consider usability,
                                                      information architecture, and all the luxury, but they are always
                                                      concerned about aesthetics, I guess.

                                                      Oh, the mentality problem I mentioned above, is that they are worried
                                                      if their desiging skill would lag or even deteriorate when they join
                                                      to become a whole team with developers and planners. They are some
                                                      designers who belong to a task force (with developers and planners in
                                                      the same room) but their pride is very low and they consider they are
                                                      there because their design skill is not professional enough. They want
                                                      to be with their kinds. They want to form a professional group.

                                                      > Are they designing the inside of the system – the architecture-y stuff
                                                      > – or the outside if the system – the visual and interaction design?

                                                      Outside.

                                                      > My guess is the former – not the latter. If that's the case, based on
                                                      > what I'm hearing as constrained collaboration between them and
                                                      > developers, I suspect problems come out of that too.
                                                      >
                                                      > Finally, the last piece of advice I could give is think about how
                                                      > things would look if they were better. What would things look like if
                                                      > problems were solved? Then given that mental picture of the solution,
                                                      > what's the first tangible thing you can do/change you can make to move
                                                      > towards it?
                                                      >
                                                      > In the future do planners simply spend less time doing powerpoint work
                                                      > because they have a cool prototyping tool? This brings me back to one
                                                      > of the first things I asked – what really is the problem here? Is
                                                      > this really about saving the labour costs/time spent by the planners?
                                                      > No offence to the planners – but who cares? If you saved them 25% of
                                                      > their time, would that be significant to the company you work for?
                                                      > Might the company them be tempted to fire 25% of the planners? The
                                                      > net result being that their life really isn't any better. Look deeper
                                                      > to what the problem really is here. Does it take to long to build
                                                      > product? Is the product quality low? Is it too expense to build
                                                      > products vs. your competition – do you need to reduce costs overall?
                                                      > Where is the pain coming from?
                                                      >


                                                      These are good questions.

                                                      I started coaching a new team with developers and planners (haven't
                                                      yet figured out to have the designer participate, and they are
                                                      thinking about working without a designer as far as they can get --
                                                      they think the political problem is too difficult to solve) and their
                                                      morale is very high. The team is working very agile using agile
                                                      usability techniques.

                                                      The problem is other teams.

                                                      > Hope that give you some more things to think about – and potentially
                                                      > some more questions to ask.

                                                      Thank you. I will keep in my mind those questions and report the result later.

                                                      >
                                                      > Thanks for posting this here to make the discussion public.
                                                      >

                                                      Your welcome. Thank you again for your response.

                                                      June

                                                      > -Jeff
                                                      >
                                                      > --- In agile-usability@yahoogroups.com, "June Kim" <juneaftn@...> wrote:
                                                      > >
                                                      > > Following is email I sent to Jeff but I suppose it didn't make it to
                                                      > > him. I think it would be better to post it to a larger audience and
                                                      > > ask for help.
                                                      > >
                                                      > > ---------- Forwarded message ----------
                                                      > > From: June Kim
                                                      > > Date: Apr 19, 2006 5:08 PM
                                                      > > Subject: On the Communication between Planner, Designer, and Developer
                                                      > > [snip]
                                                      > >
                                                      > > BTW, I just want to ask some comments from you. I would greatly
                                                      > > appreciate your opinion or any reference you could afford me.
                                                      > >
                                                      > > As I told you I am coaching a few major web portal companies in Korea.
                                                      > > They have half a thousand developers and a few hundreds of designers
                                                      > > and planners. Oh, the job title, "planner". I think you are
                                                      > > unfamiliar with that job title. In Korea, we call those people who
                                                      > invent
                                                      > > and plan the web service(product manager?) as planners. They invent
                                                      > > the concepts and ideas and then draw storyboards and sometimes
                                                      > > organize the team and arrange the schedule, being the mediator between
                                                      > > designers and developers.
                                                      > ...
                                                      >
                                                      >
                                                      >
                                                      >
                                                      >
                                                      >
                                                      >
                                                      >
                                                      > Yahoo! Groups Links
                                                      >
                                                      >
                                                      >
                                                      >
                                                      >
                                                      >
                                                      >
                                                      >
                                                    • Jared M. Spool
                                                      ... I guess I was thinking about large applications, where design elements (such as date input or user login) may repeat themselves multiple times in a variety
                                                      Message 26 of 26 , May 11, 2006
                                                        At 06:41 AM 5/11/2006, Adrian Howard wrote:
                                                        >Oh yes, I quite agree. It's more a question of nomenclature. Once you
                                                        >add a bunch of application specific detail to them is it really right
                                                        >to carry on calling them patterns? Haven't they then lost the generic
                                                        >nature that the name implies?

                                                        I guess I was thinking about large applications, where design elements
                                                        (such as date input or user login) may repeat themselves multiple times in
                                                        a variety of contexts. I would think patterns would be ideal in this scenario.

                                                        I agree that for small applications, it's probably overkill. But for a
                                                        suite of small applications, it could be useful.

                                                        Jared


                                                        Jared M. Spool, Founding Principal, User Interface Engineering
                                                        510 Turnpike Street, Suite 102, North Andover, MA 01845
                                                        978 327-5561 jspool@... http://www.uie.com
                                                        Blog: http://www.uie.com/brainsparks
                                                      Your message has been successfully submitted and would be delivered to recipients shortly.