oh yea, my summation/conclusion based on my analysis/findings is
that:users/people/humans
need to know what they are looking for before they can find it which makes
it very necessary for something that wants to be found have an accurate name
and description.

I think...

On Tue, Mar 31, 2009 at 11:42 AM, Angel Marquez <angel.marq...@gmail.com>wrote:

> I totally wrote the doctor, mechanic, musician, specialist post and then
> deleted it before sending. I wanted a cello player not a stand up bass, yea
> they are both stringed instruments, I only do transmissions I can refer you
> to a brake specialist, I know a great plastic surgeon my ex wife uses etc...
> I've decided even though these arguments are ridiculous based on the fact
> that every time it comes to an end, that's just what happens. It ends;
> although, the name is very important for findability and a good example of
> best practice. The entire use of self documenting is what you all should
> strive for.
>
> Just recently I've been looking for more custom type leads for front end
> 'functions' with google and coming up short. Perfect example was posted last
> night. The skills you employ are similar to a function or a collection of
> functions that would fall under the design class, right?
>
> If everyone agreed on what was named what your search time would have to
> branch off in so many directions when under the gun. I'm all for branching
> off into tangents; but, when you need to actually deliver and your
> 'researching' a clean channel is nice, ideal, desirable. If someone wants to
> steer with there teeth and use their hands for the gas and clutch, let em,
> just get out of the car.
>
> Changing the name on a whim would be the same as changing the names in the
> names of functions in code which in turn would be easier with a CLI and the
> system built with this frequent urge in mind.
>
> #designer
>
> interaction (idea) {
> return deliverable
> }
> visual (wireframe) {
> return deliverable
> }
> database (functional-spec) {
> return deliverable
> }
>
>
> On Tue, Mar 31, 2009 at 10:58 AM, Andrei Herasimchuk <
> and...@involutionstudios.com> wrote:
>
>> Damn iPhone buttons.
>>
>> That last message was supposed to say:
>>
>> "I think I love you, Jared. "
>>
>> And yes, watching this bickering is a little too much for me on the
>> enjoyment scale. Pots and kettles and all.
>>
>> Once the fighting is over, someone will remember to bring in the visual
>> people to the table and then things can continue where they left off in 1996
>> before people thought that splitting up all of the skills was a good idea.
>>
>> --
>> Andrei Herasimchuk
>> Chief Design Officer, Involution Studios
>> e. and...@involutionstudios.com
>> c. 408.306.6422
>>
>> On Mar 31, 2009, at 7:50 AM, Jared Spool <jsp...@uie.com> wrote:
>>
>>  In an emergency, you fetch a doctor.
>>>
>>> Interestingly, there are no doctors. Or, more accurately, there are many
>>> doctors that you don't want to help you in a medical emergency. (My good
>>> friend, with the Ph.D. in 15th Century English Literature, is not the person
>>> you want to deliver the baby, even if he was the only Doctor on the island.)
>>>
>>> Many qualified medical professionals don't have an official "doctor"
>>> title. Rehabilitation specialists, nurse practitioners, and myriad other
>>> professionals deliver trained, quality healthcare despite missing that
>>> quintessential label.
>>>
>>> In an emergency, a layman looks for a doctor. It's a useful term and it
>>> works great.
>>>
>>> If you're having a heart attack, you might want a Cardiothoracic Surgeon.
>>> Certainly, if the result you want is to have your chest cut open, your ribs
>>> spread, and your heart massaged. On the operating table, this is a great
>>> result. In the foyer of the Opera House, an EMT might in fact be better
>>> qualified to help you. (Cardiothoracic surgeons are doctors, while EMTs are
>>> not, usually.)
>>>
>>> Some of you may know that over the past eight years, we've been
>>> researching what makes the ideal UX team. One of our early results is that
>>> ROLES DON'T MATTER, SKILLS DO. It doesn't matter if a team has an
>>> interaction designer or information architect. It does matter that
>>> interaction design and information architecture skills are present amongst
>>> the team.
>>>
>>> Teams with the right skills are more likely to produce great user
>>> experiences. Teams missing the right skills are very unlikely to produce
>>> anything exciting or delightful. (Of course, we can't say 'never'. Even a
>>> blind squirrel finds an acorn every so often. But, if I'm staffing a team, I
>>> want to do so in a way that will have the best odds, no?)
>>>
>>> Our research showed there are core skills: interaction design,
>>> information architecture, user research, visual design, information design,
>>> fast iteration management, copywriting, and editing. There are also what we
>>> call enterprise skills, some of which are: analytics, development methods,
>>> design-to-development documentation, ethnography, social networks,
>>> marketing, technology, business knowledge, and domain knowledge. (If you're
>>> interested, I wrote about these in more depth and gave teams a tool to
>>> assess their strengths here:
>>> http://www.uie.com/articles/assessing_ux_teams/ )
>>>
>>> On the best teams, every team member has a solid foundation in all of
>>> these skills. That's important because it gives the team flexibility. No
>>> matter who is available, no matter what needs to get done, a competent and
>>> informed job is possible.
>>>
>>> When teams are made up of specialists -- teams that have only one person
>>> who can do a thorough job with a particular skill -- those individuals run
>>> into the "binary workload problem" -- either they are overworked or
>>> unnecessary. There is either too much work for them, thus creating a
>>> backlog, or they don't have anything to do, thus wasting a valuable
>>> resource.
>>>
>>> The best teams still have individuals who are top-of-their-game in one
>>> skill area or another. People who are up to date on the latest thinking and
>>> techniques. But, because the entire team is fully competent in the skill
>>> area, they can leverage their exceptional skills in those areas on the rare
>>> project that demands it, plus act as an advisor and mentor to the rest of
>>> the team, thereby continuing to raise the entire team's skills further.
>>>
>>> In my opinion, we'll see less emphasis on individual specialist job
>>> titles going forward. We're already seeing that in the job postings that
>>> have come out in the last year. They tend to be looking for more generalist
>>> individuals with a well-rounded, rich set of skills. Many teams can't afford
>>> to have members who are missing the core skills, even if the skills they
>>> have are rich unto themselves.
>>>
>>> (This goes beyond the "T-shaped person" concept that's been floating
>>> around, or its more recent cousin, the "broken comb shaped person." We're
>>> talking a full hair brush here. I promise to never use that metaphor again.)
>>>
>>> UX is not something unto itself. UX is a synergy of all the skills of the
>>> team. The more skills and the richer each team member is, the better the UX
>>> that will result.
>>>
>>> And you probably wouldn't want to check into a hospital filled only with
>>> extremely talented cardiothoracic surgeons, unless chest surgery is the
>>> solution to every problem you have.
>>>
>>> Jared
>>>
>>> Jared M. Spool
>>> User Interface Engineering
>>> 510 Turnpike St., Suite 102, North Andover, MA 01845
>>> e: jsp...@uie.com p: +1 978 327 5561
>>> http://uie.com  Blog: http://uie.com/brainsparks  Twitter: jmspool
>>> UIE Web App Summit, 4/19-4/22: http://webappsummit.com
>>>
>>>
>>>
>>>
>>> ________________________________________________________________
>>> Welcome to the Interaction Design Association (IxDA)!
>>> To post to this list ....... disc...@ixda.org
>>> Unsubscribe ................ http://www.ixda.org/unsubscribe
>>> List Guidelines ............ http://www.ixda.org/guidelines
>>> List Help .................. http://www.ixda.org/help
>>>
>> ________________________________________________________________
>> Welcome to the Interaction Design Association (IxDA)!
>> To post to this list ....... disc...@ixda.org
>> Unsubscribe ................ http://www.ixda.org/unsubscribe
>> List Guidelines ............ http://www.ixda.org/guidelines
>> List Help .................. http://www.ixda.org/help
>>
>
>
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... disc...@ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

Reply via email to