Joel Spolsky claims the "Program Manager" role does UI design... ????

"Lacking a program manager, your garden-variety super-smart programmer is going to come up with a completely baffling user interface that makes perfect sense IF YOU'RE A VULCAN (cf. git). The best programmers are notoriously brilliant, and have some trouble imagining what it must be like not to be able to memorize 16 one-letter command line arguments. These programmers then have a tendency to get attached to their first ideas, especially when they've already written the code."

How to be a program manager
http://www.joelonsoftware.com/items/2009/03/09.html

What Geoffrey Moore, Donald Norman, Paul Graham, Heidi Roizen, Jennifer Aaker, Michael Lopp, and Ryan Carson all have in common?

http://www.businessofsoftware.org/

-- Joel Spolsky
joel at joelonsoftware.com

Russell, Joel was trained in teh land of Redmond. In Redmond this was totally true. the Program Manager was the UI designer, like in NYC the Producer often has the role of UI Design or at least IA. I don't think you should or can interpret Joel's words as saying that the PM replaces the IxD or more traditional UI Designer role in the least. Though I can see how today it can be seen like that.

- -dave

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

First, I agree with Dave that you have to take Joel's lingo with a pinch of MS salt from the 90s.

However, I have to say his comment that PMs (read designers) must keep the developers happy lest they go off and do WTF they feel like made me shudder. I've spent a lot of my career trying to help devs and designers get along (I admit, having a CS degree helps), and part of that effort was in helping each side recognize that both had something to add to the conversation, and that both could be wrong.

Now here's Joel telling us that those gods in mortal flesh, programmers, must be appeased, lest the design be cast aside. And he's saying this is the RIGHT WAY for things to be.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

This is actually a pretty dangerous essay to our profession. To have us cut out of the software development process by an influential figure is really unfortunate. We should have some sort of response to this.

Dan

So the theory is to cloak the designer as a program manager? Or did I twist that a bit?

On Mar 9, 2009, at 3:42 PM, Russell Wilson wrote:

"Lacking a program manager, your garden-variety super-smart programmer is going to come up with a completely baffling user interface that makes perfect sense IF YOU'RE A VULCAN (cf. git). The best programmers are notoriously brilliant, and have some trouble imagining what it must be like not to be able to memorize 16 one-letter command line arguments. These programmers then have a tendency to get attached to their first ideas, especially when they've already written the code." How to be a program manager http://www.joelonsoftware.com/items/2009/03/09.html What Geoffrey Moore, Donald Norman, Paul Graham, Heidi Roizen, Jennifer [trim]

Perhaps Don Norman will set him straight?

I see Spolsky is based in NYC. It's an attitude I've run into here more than once during my cultural transition of moving from the silicon valley 1.5 years ago. Yet our discipline is somehow still "hot" here and there are never enough qualified senior people. Believe me, it's had me stumped. Have been thinking of going into process consulting/ teaching just to educate the community here.

-- www.light-motif.com

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

I've been a program manager.

Why do you see this as a threat? I see this as another opportunity.

And UX people should know a bit about programming, so they know what they're designing into.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

That's what I understood his point to be

Sent from my iPhone

On Mar 9, 2009, at 6:47 PM, mark schraad mschraad at gmail.com wrote:

So the theory is to cloak the designer as a program manager? Or did I twist that a bit? On Mar 9, 2009, at 3:42 PM, Russell Wilson wrote: "Lacking a program manager, your garden-variety super-smart programmer is going to come up with a completely baffling user interface that makes perfect sense IF YOU'RE A VULCAN (cf. git). The best programmers are notoriously brilliant, and have some trouble imagining what it must be like not to be able to memorize 16 one-letter command line arguments. These programmers then have a tendency to get attached [trim]

I believe it's important, particularly in the current über-cost-conscious climate, to think of IxD as a discipline, rather than a job description.

Depending on the mix of talents, personalities and experience in a software organization, it may or may not be necessary to have a full-time interaction designer. A lot of very worthwhile software projects are designed, built and managed by a single person. That person is "doing" interaction design whether they know it or not. This has its most obvious reflection in the progress the Agile movement has made in the last few years. Agile makes a lot of sense to the bean-counters, because it allows small teams to deliver (more-or-less) functional software really quickly.

The challenge for people like us will lie in finding ways to insert ourselves into these processes. Not only to keep putting bread on the table, but to make sure that we don't see another generation of really awful software. For a lot of us, that's going to mean we have to either get our hands dirty and start coding, or else ease up on the reigns and let the developers think they're running things. Because, let's face it. Without an interaction designer, you end up with bad software. Without a developer, you end up with no software at all!

There. I think I used my one-exclamation-point-per-message pretty well, don't you?

On Mon, Mar 9, 2009 at 5:02 PM, Russell Wilson russ.wilson at gmail.comwrote:

That's what I understood his point to be Sent from my iPhone On Mar 9, 2009, at 6:47 PM, mark schraad mschraad at gmail.com wrote: So the theory is to cloak the designer as a program manager? Or did I twist that a bit? On Mar 9, 2009, at 3:42 PM, Russell Wilson wrote: "Lacking a program manager, your garden-variety super-smart programmer is going to come up with a completely baffling user interface that makes perfect sense IF YOU'RE A VULCAN (cf. git). The best programmers are notoriously brilliant, and have some trouble imagining [trim]

Well, if you've seen the UI for FogBugz, then I guess that shows you what kind of a UI a Program Manager can design.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully. Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
Twitter: zakiwarfel
In theory, theory and practice are the same.
In practice, they are not.

"Well, if you've seen the UI for FogBugz, then I guess that shows you what kind of a UI a Program Manager can design. "

You mean a profitable product?

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

@Dan - I completely agree. Very frustrating for someone who spends a lot of time evangelizing the value of good design.

@Patrick - I'm not threatened at all, and I started out as a programmer (BS and MS) - and still code when I can - just wrote some javascript as a matter of fact. But what Joel says is like saying "just have the building contractor or structural engineer due the architectural renderings"... It's complete BS and undermines the value and need for skilled designers. And unfortunately his voice is widely heard. Btw - how do you see this as an opportunity?

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

Since you asked, this is how I see it as an opportunity (pretty much the best once since the invention of sliced bread):

While we're all trying to figure out what our titles are (and that's our damn fault, politics and posturing in our community be damned), Joel defined an ADDITIONAL position for us that includes all the most important goals of what we're supposed to do anyways, and it's literally 60 percent of the job (the other 20 percent being a pure fashion choice).

So he defined 75 PERCENT of the job relating to UX, the rest to communication, is what we're supposed to be good at anyways. And that job, with manager in it's title, pays very well (more than a typical IA position), and relates directly to ROI of the product, even more so than a product manager position. I've had THAT EXACT JOB TITLE, and it rocks. I did it totally from a UX standpoint.

(Raise your hands if you can say the same.)

But wait, THERE'S MORE.

Not only did he do that, but he defined the ratio of program managers to developers, which is very important, because, well, most of the projects we work on have like one IA to 80 developers. He placed it close to that magical 25 percent UX, 50 percent development, 25 percent QA ratio, and let me tell you, in an agile environment, that ratio is MAGICAL.

BUT WAIT, THERE'S MORE!

He defined functional requirements IN SOME FORM as important. They could be wireframes. They could be use cases. They could be written on butcher paper. But he defined them as HAVING VALUE IN THE SOFTWARE DEVELOPMENT PROCESS. (Can you say the same about XP or Scrum?)

He also said...

"The number one mistake most companies make is having the manager of the programmers writing the specs and designing the product. This is a mistake because the design does not get a fair trial, and is not born out of conflict and debate, so it's not as good as it could be.

SNIP

...both sides, but especially the program manager, need to be emotionally detached from the debate and willing to consider new evidence and change their opinions when the facts merit it.

SNIP

Functional specifications are so important one of the few hard and fast rules at Fog Creek is %u201CNo Code Without Spec.%u201D "

He said he even learned from his own mistakes at his own company, and restructured the role so it would be more effective.

I do disagree that anyone out of college can do the UX part; and it's up to us to convince him otherwise than complaining about it here (and I'm going to write to him personally). And there's the opportunity — letting him know the value.

On the other hand, we have to respect his opinion.

He runs a very profitable company, larger than most of the people on the group, has the respect of his peers (I can't tell you how many times the developers suggested FogBugz over TFS because of it's ease of use for simplified bug tracking), has a great product line, and sold more books than anyone else on this list, I would guess.

He also has a farther reach into the software community than all of us put together.

It would be better for us to reach out to him and state our case and build bridges, right?

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

I thought his comment about specs was heartening in a world where I'm seeing more developers perceiving design and planning as anti-agile:

Functional specifications are so important one of the few hard and fast rules at Fog Creek is %u201CNo Code Without Spec.%u201D

If spec=design, as it seems to with his reference to storyboards and functional descriptions, it's good to have a heavy-hitter like Joel in your corner when you're having one of those conversations with eng.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

On Tue, Mar 10, 2009 at 6:42 AM, Russell Wilson russ.wilson at gmail.com wrote: "Lacking a program manager, your garden-variety super-smart programmer is going to come up with a completely baffling user interface that makes perfect sense IF YOU'RE A VULCAN (cf. git). The best programmers are notoriously brilliant, and have some trouble imagining what it must be like not to be able to memorize 16 one-letter command line arguments. These programmers then have a tendency to get attached to their first ideas, especially when they've already written the code."

Hi Russell,

I think that there's some circular logic at work in the interpretation here.

"Lacking a program manager" means without a program manager (to me, at least) "your ... programmer is going to come up with a completely baffling user interface" means what it says, i.e. that Spolsky is saying that the coder will screw up the UI. While this isn't always the case, it happens often enough that there is some truth to it.

My interpretation is this - in the absence of a program manager, the UI will be left to the coder, who may screw it up. And I agree with this. Anyone not with me so far?

I am not sure that this infers in any way, shape, or form that the program manager will be designing the UI. What it does mean, and logicians feel free to shoot me down here, is that in the presence of a program manager, someone other than the coder will design the UI. It does not specifically state that this will not be an IxD, UxD, IA, or janitor.

The absence of a thing does not denote the presence of its opposite.

Best regards, Andrew

Andrew Boyd
http://uxaustralia.com.au — UX Australia Conference Canberra 2009 http://uxbookclub.org — connect, read, discuss http://govux.org — the government user experience forum http://resilientnationaustralia.org Resilient Nation Australia

Does Joel know about IxD? Because a year ago, I didn't. I did a Google search: "interaction design" site:joelonsoftware.com The hits on the first 2 pages are from the discussion pages, and there was one on jobs. If Patrick writes him we could hope for an article soon.

I personally don't see any problem design done by a someone with the job title "Program Manager". So in many ways I agree with Joel. My worry is that it depends a lot on the individual. With the wrong PM the UX is neglected, done improperly, and without adaquate knowledge or training.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

Already wrote him.

Wrote a post:

http://www.usabilitycounts.com/2009 /03 /09 /the -program -manager -and -how -getting -ux -into -software -way -we -can -is -good /

Look, not all software organizations can support an IA, a UX designer, whatever. That takes a larger software project, and for the vast majority of UX people, they would just be happy working with a SECOND UX person in the same organization.

Most of the work out there is in agencies or in contract, so anywhere we can get extra positions (mostly UX with some project management) is good. While it's not a job title, it is a discipline, and our good that we can educate and get better software produced.

From THIS website:

"...the IxDA network actively focuses on interaction design issues for the practitioner, no matter his or her level of experience."

Doesn't that include anyone that wants to learn?

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

I think the principle is sound, the practice as he describes it sounds a bit political.

Years ago I used to call myself an Interactive Director in order to make the distinction that I was there managing the interactive experience as the third pillar of Creative/Art Director and Technical Director. The title never caught on, but the discipline did.

My main beef with Joel's piece is that he's talking about a role that interaction and user experience design covers and pinning an outdated title on it to... well, I don't really know why. To write a blog post? To try and sell a new idea? To sell himself?

He's not really saying anything new. The reason projects don't have a Program Manager is because they're called something else these days.

For what it's worth, I think Excel has and continues to have an awful UI and FogBugz looks like Word.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

This post and the reactions on the list demonstrate very clearly the need for intense communication to related communities. I am working mostly in enterprise environments in Europe, and there it is still quite normal that UX work is been done by business analysts and developers without naming it UX or anything similar. More than 50% of my work consists of educating clients and partners about my profession and its value to an IT project.

Some ideas from posters before point in the right direction, such as

What else can be done to raise awareness and to simplify/communicate the message?

milan -- ||| | | || | || | ||

milan guenther * interaction design
p +49 173 2856689 * www.guenther.cx

I generally agree with Patrick.
I think the title can work for us. I do believe that when you design you are actually responsible, more than others for the product success, so the program manager title is better than interaction designer or user experience, etc. I like the full responsibility it gives us. It also brings us closer to the "business plate" (Andrew!) which means more influence (and usually more money).

On the other hand, his view regarding user interface design is outdated andmmm... well not serious. The job description is quite cool but IxD as a discipline description is very poor.

We should try to turn this to our advantage, I think it is possible. Maybe write on Joel's discussion board? (Hopefully someone more articulate than me...)
Nurit

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

And how is a Program Manager not going to screw up the UI? Unless they have some design training or skills, they're no less likely to screw it up than a programmer, who at least understands the technology.

On Mar 10, 2009, at 2:22 AM, Andrew Boyd wrote:

My interpretation is this - in the absence of a program manager, the UI will be left to the coder, who may screw it up. And I agree with this. Anyone not with me so far?

Cheers!

Todd Zaki Warfel
Principal Design Researcher
Messagefirst | Designing Information. Beautifully. Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
Twitter: zakiwarfel
In theory, theory and practice are the same.
In practice, they are not.

Unless they have started teaching design, hci, interaction design, information architecture and/or usability analysis in Project/Program management undergrad and grad schools these days, I am completely dumbfounded.

Oh - wait

There are no schools in Program Management, just certificate programs and industry continuing education.

Oh - and wait - there are no classes in any of the above mentioned disciplines in the curricula of those continuing ed/certificate programs.

Seems like a great idea - let's take a role that necessarily has had no need for or training in the most applicable disciplines necessary for the successful experience design or interaction design and empower them to make all those design decisions. Sounds fantastic to me!

~ will

"Where you innovate, how you innovate,
and what you innovate are design problems"

Will Evans | User Experience Architect
tel: +1.617.281.1281 | will at semanticfoundry.com http://blog.semanticfoundry.com
http://www.linkedin.com/in/semanticwill
aim: semanticwill
gtalk: semanticwill
twitter: semanticwill

On Mar 10, 2009, at 8:40 AM, Todd Zaki Warfel wrote:

And how is a Program Manager not going to screw up the UI? Unless they have some design training or skills, they're no less likely to screw it up than a programmer, who at least understands the technology. On Mar 10, 2009, at 2:22 AM, Andrew Boyd wrote: My interpretation is this - in the absence of a program manager, the UI will be left to the coder, who may screw it up. And I agree with this. Anyone not with me so far? Cheers! Todd Zaki Warfel Principal Design Researcher Messagefirst [trim]

I think that Joel is touching a much more important problem.

The problem is: who is responsible for conceptual design of a product?

On my experience about 60% of design decisions are done when we have not defined UI at all.

There is a need for a mixed BA/UX type person, what ever we call it: 'Program Manager', 'Product Manager' or 'Project Leader'... The one who owns the holistic view on the product. This person can either have BA roots (which is more common) or UX roots.

Such people do not necessary substitute UX or BA professionals. They are working together being responsible for more conceptual things leaving details to the specialists.

http://boxesandarrows.com/view/transitioning-from http://www.boxesandarrows.com/view/bringing-holistic

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

What happens when Program Managers design the UI? Well, it doesn't appear to work or look much different than a good programmer designing one: http://media.fogcreek.com/fogcreek.com /FogBugz /60movie /60movie.html

Cheers!

Todd Zaki Warfel
Principal Design Researcher
Messagefirst | Designing Information. Beautifully. Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
Twitter: zakiwarfel
In theory, theory and practice are the same.
In practice, they are not.

I personally respect the PMs I work with way too much to think they have time to create an elegant UI in addition to budgeting, scheduling, coordinating, project tracking, client/ mgmt appeasing, troops gathering, and all the assorted logistics. And do I want to do that stuff?? I sometimes do project management on UX-only projects. But for the larger, more complex stuff that I'm guessing most of us work on here, when it includes managing a team of developers? No way. (Especially when it involves using Excel ; ))

There is some overlap between our disciplines, yes—but then there is overlap in EVERY discipline with ours.

I bristle when I read blanket statements such as the "vulcan" comment about programmers' lack of ability to come up with good UX ideas. Like everyone, they vary in their abilities so this kind of generalization is not only untrue, but can only hurt the perception of anyone in a UX role in its condescending tone, I believe. A good UX designer accepts input from the entire team—PMs, programmers, visual designers, writers, marketing, management, etc, etc.

--

www.light-motif.com

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

@Will First, Program Managers and Project Managers are different beasts (usually).

@Patrick Amen.

I don't care what Joel calls the job, though I'd prefer he recognize that design is something that requires training as much as programming does. He comes from MS, and MS has Program Managers. They've got designers now too, but I suspect there were a lot fewer when Joel in the Excel 5.0 days. So, Joel writes about Program Managers. The way he describes the job sounds very familiar to what I've done in much of my career.

It surprises me that this discussion has focused so much on what he calls the job, then the relationship he describes between designers and developers.

Of course, when programmers are peers of the program managers, the programmers tend to have the upper hand. Here's something that has happened several times: a programmer asks me to intervene in some debate he is having with a program manager.

%u201CWho is going to write the code?%u201D I asked.

%u201CI am%u2026%u201D

%u201COK, who checks things into source control?%u201D

%u201CMe, I guess, %u2026%u201D

%u201CSo what's the problem, exactly?%u201D I asked. %u201CYou have absolute control over the state of each and every bit in the final product. What else do you need? A tiara?%u201D

And yes, Fog Bugz is ugly and kind of hard to use.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

Well... of course without the right education / training in UX / IxD, the job can't be done, whatever the title is...

But with adequate knowledge and experience this is actually a good title. I also like the idea that this person should not report to the CTO, I see it in many companies and I think it is wrong. The issue of title and hierarchy may seem insignificant when you are a consultant but it does affect your ability to do your job when you are part of the team.

This is not in any way a comment about IxD content, means or training, which are of course very important, and Joel list miss that totally. But a few of the ideas there are good and may help some of us in our own backyard.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

Yuck. Here's the quote again:

(From the article)

Of course, when programmers are peers of the program managers, the programmers tend to have the upper hand. Here's something that has happened several times: a programmer asks me to intervene in some debate he is having with a program manager.

"Who is going to write the code?" I asked.

"I am..."

"OK, who checks things into source control?"

"Me, I guess, ..."

"So what's the problem, exactly?" I asked. "You have absolute control over the state of each and every bit in the final product. What else do you need? A tiara?"

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

I really wish I had the time to read the responses in detail (way too busy today!)... but from snippets:

1) Program Manager as a title is both outdated and nebulous. I don't know any two people who would agree on what a program manager does. If you want to move more into the business side, go with Product Manager.

2) The implication that "anyone can design" (and I may be misinterpreting... please tell me I'm misinterpreting) - that a program manager (or developer or product manager or janitor...) can "learn" UI design and perform that function in addition to their other responsibilities/skills GROSSLY devalues the knowledge, experience, and training required to perform "good" design (notice the term "good" ). No offense to Steve Krug, he is a friend, but reading his book does not make you a designer... just like picking up a copy of "A Pattern Language" doesn't make me an architect.

3) I consider myself a design evangelist. I created my role (VP of Product Design) at my current company and have done so at other companies as well. I encounter skepticism, confusion, and misunderstanding regarding the value, role, and skills associated with "good" design all the time... but what's shocking is to see these same things on this very list, what I consider my "safe place"... what does this say about user interface / interaction design? Am I fighting a losing battle? We can't even make up our own minds? To see people say things like "let's just call ourselves program managers", ready to jump ship after one article, is maybe a sign of frustration, uncertainty, ??

Crud... must run...

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

@Jason
"It surprises me that this discussion has focused so much on what he calls the job, then the relationship he describes between designers and developers."

Why is that surprising??? We (us, the industry, etc.) have to agree on a name for our role. Without it we lack credibility and it makes it very difficult for the simple things like job hunting, etc. You know what an architect does. You know what a dentist does. When I hire people my HR dept (and we're a 300 company) can't decide what their payscale should be because they have no good data or understanding about what usability / user interface designers do!

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

- Regarding the look and feel of FogBugz (or say what you want to say about it...)

I don't know about you, but that's successful UX to me.

He's exactly right. Programmers, because of where they sit in the development process, are gatekeepers and have quite a bit of control over the product. And if they tune out the program manager and build something that, well, sucks, it's going to show.

Smart programmers will realize this and work as a team, because flipping the bozo doesn't legitimize their answer of, "well, I decided to write it my way." Smart company management will say, "sure" are fire them, because that affects the bottom line.

Does this happen alot? No. But I've seen it happen in good companies.

Okay, let's change the job title to ice cream specialist.

Joel's looking for someone for the job title for ice cream specialist, and this ice cream specialist has to have five years of user experience, uh, experience. They are going to be managing the process of developing software product. They call people who do user experience design ice cream specialists. And they have to be able to build wireframes and functional requirements in some form.

Sounds like IX/UX to me.

If it pertains to your experience, and you're getting paid to do the work you live, does it matter what the job title is?

The reason Joel calls them that is because of the culture he's worked in. Microsoft had program managers as part of the process, and it worked because they were able to find people to play the role. Sure, some of their products sucked (BOB), but for Joel, a program manager was the perfect role because they were able to build cool Excel macros which the target audience was able to use. Or...effective UX.

We get so frustrated with how UX/IX is not respected, and think there should be UX/IX titles in there, yet we never seek to understand the politics and/or structure of the company to figure who's doing the UX/IX, regardless of title or department.

The reality is, IAs do the work, BAs do the work, Web Designers (god forbid, sometimes with their lack of understanding of taxonomies) do the work. The important thing is SOMEONE is doing UX/IX work, and they are doing it with SOME kind of process that represents a UX/IX process. That means doing personas (or not), wireframes (or not), ethnographic studies (or not).

Personally, I could really care less what the job title is in the end.

What I do care about is SOMEWHERE in the job description, there's a like that says, "requires 5 to 10 years of information architecture experience". If it says that, we've done our job.

I saw one of the recaps of IXDA. One of the speakers had a great point: if we can't agree on a job title in front of HR, people will do it FOR us. This is just one example.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

It's not targeted at you directly, but rather a real question, which is how is a program manager any less likely to screw up the UI?

On Mar 10, 2009, at 12:40 PM, Andrew Boyd wrote:

Read the rest of my original response. At no time do I advocate that the program manager should have anything to do with the design. This thread started with an incomplete quote, and this tradition seems to be continuing : )

Cheers!

Todd Zaki Warfel
Principal Design Researcher
Messagefirst | Designing Information. Beautifully. Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
Twitter: zakiwarfel
In theory, theory and practice are the same.
In practice, they are not.

On Tue, Mar 10, 2009 at 1:04 PM, Todd Zaki Warfel lists at toddwarfel.com wrote: It's not targeted at you directly, but rather a real question, which is how is a program manager any less likely to screw up the UI?

If you mean "less likely than a developer" then you didn't read the article. In the column, Joel emphasizes the importance of this person (ignore job title for now) communicating with users, communicating across teams, and encoding the understandings gained from those experiences into a document that emphasizes function without being too tied to any methods by which the function is implemented. He also explicitly refers to things like user testing.

I just don't know (m)any programmers who have those things as their primary responsibilities; do you?

I do believe that an emphasis on those things is statistically more likely to produce better design, and I'm betting you believe the same thing, no?

Best, --Alan

That's the case in what I do: I'm a product manager that does UI design. It woks beautifully!

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

Hmm, on second view at the sight there is a lot of user interface stuff under "Software Designer". Even IxD stuff.

In that respect it looks more like the Ix designer role is split between PM and SD, rather than PM replaces IxD, in Joel's world.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

On Mar 10, 2009, at 1:11 PM, Alan Wexelblat wrote:

I just don't know (m)any programmers who have those things as their primary responsibilities; do you? I do believe that an emphasis on those things is statistically more likely to produce better design, and I'm betting you believe the same thing, no?

I read the article.

These activities are things that any designer, developer, or manager can do.

I do believe they increase the likelihood for success.

Most program managers I know aren't trained in design, which is where the real difference comes in for making better designs.

Cheers!

Todd Zaki Warfel
Principal Design Researcher
Messagefirst | Designing Information. Beautifully. Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
Twitter: zakiwarfel
In theory, theory and practice are the same.
In practice, they are not.

i'm with Andrei here.

If we are talking about our practice and in the realm of software, I think you should call yourself a "software designer" or an "interface designer". The more I dive into ID the more I realize that the designer's job is to make a final appearance model. if you aren't doing that, then you are just a middle man, and middlemen are just too expendable.

Now!!! I want to add that this is completely different than the "discipline" of Interaction Design. The discipline has a very discreet identity from UI and ID and Architecture, etc. It works with all of these and between them. It is a collection of theories and methods that can be applied horizontally across
mediums/technologies/contexts.

BUT! if we are talking about software, then heck, you are a UI Designer or a Software Designer. Ya know about 15 years ago or so there was a group called the Software Design Alliance or some such with peeps like Cooper & Kapor deeply involved. it didn't go anywhere at the time, but I think it was just bad timing on their part. IxDA is basically that Org, IMHO re-born in a new generation.

-- dave

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

Andrei's requirements:

I can perform most of those tasks to about a 90 percent level (don't even ask me to do high level actionscript though). But, as a person who has hired for UX positions, the requirements described there are impossible to hit in any one person, except for the lucky few (a few on this list).

In fact, in my time of building a team of 25, I would have found exactly one person that could have fulfilled those requirements, and that would have been me.

We need to have realistic expectations for who fills the roles and what they can do, otherwise we fail in front of our software development peers. For example, we wouldn't expect a software developer to be an expert DBA and an expert in system administration while being a rockstar coder. They exist, but not in the levels needed to support what was just mentioned. And, to the benefit of software developers everywhere, team managers divide up the roles logically because they have figured out how to make the divisions.

And that's the crux of this argument and probably why we struggle with the role. While some of us can do many of the different tasks and roles, expecting the whole IX/UX community to be able is not achievable. We don't like to be put into a box, but we have to so we fit within team structures.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

On Mar 10, 2009, at 5:35 PM, Patrick Neeman wrote:

We need to have realistic expectations for who fills the roles and what they can do, otherwise we fail in front of our software development peers.

I disagree at a tactical level. We need to have unrealistic expectations and understand that as a profession, we aren't doing enough to train and get ourselves to a baseline so the Spolsky's of the world stop redefining our jobs for us. We haven't done enough for our peers and those coming through the education system to the level required. If we continue to make excuses or lower our expectations for why we don't have people to do the things I've listed, we simply won't get there.

And yes, these things take time. But to the next generation, most of it will be second nature since it will be expected fro the get go. And yes it means you won't find people with all of the skills but you also have to tell people when you hire them they will be expected to learn more and learn more fast if they want to keep the job later on.

And that's the crux of this argument and probably why we struggle with the role. While some of us can do many of the different tasks and roles, expecting the whole IX/UX community to be able is not achievable. We don't like to be put into a box, but we have to so we fit within team structures.

It is achievable. In fact, more of the younger designers out there are far on their way with the hard skills I've listed, especially with regard to scripting HTML, CSS and JS/AS.

-- Andrei Herasimchuk

Chief Design Officer, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

In my life I have met handful of people who could be a candidate for such a role. As a hiring manager or owner I could spend all of my time looking - and frankly, there many other tasks worthy of this time. To put this sort requirement out there as a standard would be irresponsible. It is also an aspiration that I can only think is rooted in the struggle to think through the required tasks of an assignment and assemble the appropriate team to match.

Obviously quality of the work is not addressed in this list... but to have these skills at a high level... is very tough. And frankly, there is not enough time in the work week to keep this many skill set sharp. I'll take a balanced crew of professionals that have 3/5s of these skill, but greater ability in in just a few places any time.

Mark

On Mar 10, 2009, at 1:40 PM, Andrei Herasimchuk wrote:

* Understand type, color and layout composition/grid and can execute on those design fundamentals with their own two hands Know the fundamentals of I/O and behavior with hardware (like a mouse and keyboard, and now with multi-touch displays) Understand how algorithms, code, frameworks, databases and other software engineering aspects of the product work under the hood Draw and sketch with real pen, pencil and paper Use professional software tools to make design and process deliverables (specs, mockups, wireframes, posters, etc) Use professional creative software tools to make production ready, [trim]

"Henceforth, a program manager would:
1. DESIGN UI'S
2. Write functional specs
3. Coordinate teams
4. Serve as the customer advocate, and
5. Wear Banana Republic chinos"

@Andrew Joel's description sure sounds to me like he was discounting the UI Designer. Otherwise....wouldn't he have mentioned us somewhere? And if the Program Manager and Developer are peers, than I imagine (if there is a UI Designer somewhere) it is beneath them...which I don't much fancy.

On the one hand I take Joel's article as completely ridiculous. on the other, if I cross out "Program Manager" and add "UI Designer" it suddenly looks alot better, and I find myself identifying with the role for the most part and even taking notes...

Some of the important points in the upcoming article "How to be a UI Designer" are:

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

There's a ton of talk about good design on this list (and in articles and books and...). What I'd really like to see is with every discounting of software that other people have built (which happens a lot here, it seems), an offering of an example in the same space (e.g., in this case, bug tracking software) that exemplifies what you think is great (or at least better)—and is preferably something you (the person doing the criticizing) have had a hand in.
Fogbugz. Yes, not the most elegant solution; however, it is so much better than many (if not all—I haven't looked lately) others in that space. And it does, as Patrick said, resonate with the target audience.

Program manager (a.k.a., product manager outside of MS circles) is not the same as a project manager. I would actually recommend product/program manager as a role to UX folks. Why? Because the PM essentially owns the product (or piece of product) and specifies what does and doesn't get built and, if he/she doesn't have a dedicated designer, can also spec how it works. If you do have designers, you still have a lot of say there. So you're more empowered to ensure that the end product is good.

Finally, I think Joel probably is not trying to denigrate the value of design but just has his own understanding and perspective on it based on his experience. He writes from his experience/opinion, not from research. If he were exposed to good designers doing good work and saw the value, I'm pretty sure he'd write about it. What I imagine, though, is he wouldn't take well to a lot of feather fluffing in the design community (as would most software dev types).

In any case, I see what he wrote as a baby step forward—helping devs to recognize that they're not best equipped to do UI design and even just helping them realize that it is an important aspect that requires special attention (which many devs discount or just don't get). Baby steps

On Mar 10, 2009, at 10:40 PM, J. Ambrose Little wrote:

What I'd really like to see is with every discounting of software that other people have built (which happens a lot here, it seems), an offering of an example in the same space (e.g., in this case, bug tracking software) that exemplifies what you think is great (or at least better)

I don't see it being that much better, visually, than Bugzilla, Mantis, or Trac.

Better:
Axosoft http://www.axosoft.com/
Trac http://trac.edgewall.org/
TrackIt http://www.numarasoftware.com/ctash.asp?src=google &trm=trackit

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully. Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
Twitter: zakiwarfel
In theory, theory and practice are the same.
In practice, they are not.

SNIP

I don't see it being that much better, visually, than Bugzilla, Mantis, or Trac.

Better:
Axosoft http://www.axosoft.com/
Trac http://trac.edgewall.org/
TrackIt http://www.numarasoftware.com/ctash.asp?src=google&trm=trackit

Cheers!

Todd Zaki Warfel

SNIP

...have you used it in a project?

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

On Wed, Mar 11, 2009 at 12:23 AM, Todd Zaki Warfel lists at toddwarfel.comwrote:

On Mar 10, 2009, at 10:40 PM, J. Ambrose Little wrote: What I'd really like to see is with every discounting of software that other people have built (which happens a lot here, it seems), an offering of an example in the same space (e.g., in this case, bug tracking software) that exemplifies what you think is great (or at least better) I don't see it being that much better, visually, than Bugzilla, Mantis, or Trac. Better: Axosoft http://www.axosoft.com/ Trac http://trac.edgewall.org/ TrackIt http://www.numarasoftware.com/ctash.asp?src=google &trm=trackit

Thanks, Todd. So you're judging on visual design style, correct? (I guess I didn't mention it but it begs the question that if you think something's better, to point out what. : ))

Anyways, Fogbugz has been around for a long time. It had some innovations that were, at least back then, pretty spot on in terms of better usability (e.g., simplifying/minimizing # of fields in general and that are required, one-owner workflow, which was controversial but really good, IMO, and being able to just email to log a bug, to name a few). Most software in this space was (is?) so bloated and tentacular that it becomes impossible for a mere mortal to use without training and regular head-bludgeoning.

But I suppose this is a bit of a digression. My particular point here is maybe to get us to be more constructive in criticism and help each other learn from what we and others have done. Let's put some meat on the bones and maybe even some skin in the game.

-a

I want to jump in here again and support Andrei.

I have not even graduated from college peeps who can do most if not everything that Andrei suggests and IxD should be able to do AND!!! they can do a lot that Andrei doesn't suggest:

Across the street from me is the Interactive & Game Design department here. One of the top 5 in the country by some accounts and well, I would say that they too can DO everything Andrei listed AND they have the breadth of HCI/Usability/IA that is implicit in our requirements as practitioners as well.

So I think an implicit part of Andrei's point is "watch your back" b/c the people who are coming up the hill behind you, ARE going to be able to do the multi-facetted work that some of you are claiming isn't possible.

This is that point in our career building where we might be feeling "age" trickle in on us. Some get around it by moving up the food chain away from production into management or strategic value, but I worry about the bulk of us who aren't taking Andrei seriously.

As for the people who can't find the employees. Please email me offline and I'll send some 10 graduating seniors your way who all can kick my ass as a production interaction designer and even teach me a few things about design theory and research methods as well.

There is nothing as exciting as a motivated and passionate youthful energized designer to knock your socks off. I've been humbled by my students in so many ways.

Yes, they have a lot of to learn, but they know enough to know what it is it means to go out and teach themselves.

-- dave

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

I've had the opportunity to talk to a lot of new designers lately and have to echo strongly what Dave is saying. Design education is, for the first time in awhile, finally moving back to its roots a bit in making folks multifaceted and companies, for the first time in awhile, are starting to realize that hiring multifaceted folks makes a lot of sense. Apologies to all the early movers on this list that have been operating like this for awhile.

Chris Bernard
Microsoft
User Experience Evangelist
chris.bernard at microsoft.com
630.530.4208 Office
312.925.4095 Mobile

Original Message
From: discuss-bounces at lists.interactiondesigners.com [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of dave malouf Sent: Wednesday, March 11, 2009 3:49 AM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] Joel Spolsky claims the "Program Manager" role does UI design... ????

I want to jump in here again and support Andrei.

I have not even graduated from college peeps who can do most if not everything that Andrei suggests and IxD should be able to do AND!!! they can do a lot that Andrei doesn't suggest:

Chris,

agreed.

Designers (all of them, not only those working on digital products) have to been savvy in business, technology, and human factors/psychology thinking. The more broad the better. The separation between industrial and communication design for example, was not there when the discipline emerged at the Bauhaus in the 20s.

On the other side, there will always be need for specialists, such as

for IxD, that would mean

But design is an art of linking, bridging and connecting, and thus not comparable to classic "knowledge" disciplines.

A deep knowledge in those other disciplines involved, be it technical, user or business related, helps a lot! And for IxD, technology is something essential.

milan -- milan guenther * interaction design
||| | | || | || | ||

+33 6 67 11 13 83 * www.guenther.cx

I need designers to be familiar with:
business and revenue models
project and product management
SEO action script
scalable front end development
back end development
database structures
site metrics
market research
usability studies

By familiar... I mean they have enough knowledge to work along side, have indepth conversations and understand at a fairly deep level what these folks are doing. In a pinch, they may need to lean over and help. I don't need them to be experts in these area because I have folks that do this 50 and 60 hours a week... and do it very very well. Why would I have a designer do this instead? It makes no sense.

Maybe that is the difference between working at a larger company with the resources and expertise and a small design shop. I realize with smaller staff you need folks to wear multiple hats.

Mark

On Wed, Mar 11, 2009 at 4:09 PM, Milan Guenther milan at guenther.cx wrote:

Chris, agreed. Designers (all of them, not only those working on digital products) have to been savvy in business, technology, and human factors/psychology thinking. The more broad the better. The separation between industrial and communication design for example, was not there when the discipline emerged at the Bauhaus in the 20s. On the other side, there will always be need for specialists, such as 3D Designers Motion Designers for IxD, that would mean Social Interaction Designers Workflow/Business IxDs Service IxDs etc. But design is an art of [trim]

I'm not saying broading the skills is a bad idea (still a good idea). And I get frustrated when dealing with a UX type that says, well, they do only user researching. Most companies demand more jack of all trades.

However...

Going for this and hiring a UX team are completely different issues. The question I would ask is, "how large is your agency?" The larger you get, the harder it is to fill some of those roles with rockstars who have skillz.

You can have your HR person list all the skills listed, and then you scare away people that have maybe 80 percent of the skills you need. Hiring is hard, and not everyone fits in a box (for example, I've hired more content types, because I felt they could do better work than visual designers).

I think the world needs more generalists. I just wouldn't expect them to be a total expert on every skill, though.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

Lots of good conversation in this thread.

I find it kind of interesting that some on the thread rate the knowledge of and ability to write HTML, Javascript, and CSS to be of higher value than the "user research" skillsets.

As for me, I believe that user research skills are much more valuable for an "interface designer" than the ability to write HTML, Javascript, and CSS. Two quick reasons why are:

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

On Mar 11, 2009, at 10:57 AM, J. Ambrose Little wrote:

Thanks, Todd. So you're judging on visual design style, correct? (I guess I didn't mention it but it begs the question that if you think something's better, to point out what. : ))

Design to me encompasses both visual aesthetics and interaction. The applications I cited are both visually more appealing than FogBugz and equal if not better from an interaction perspective. I think the interaction of FogBugz is better than Bugzilla and Mantis, but visual aesthetics are essentially the same.

Cheers!

Todd Zaki Warfel
Principal Design Researcher
Messagefirst | Designing Information. Beautifully. Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
Twitter: zakiwarfel
In theory, theory and practice are the same.
In practice, they are not.

Pattrick, I think what Chris, Andrei and I are saying is that hiring tomorrow will not be like hiring from today.

Personally, if you are hiring, I'd look to hire new grads more than experienced folks, IMHO depending on the size of your team and your current league of managers. But if you got good managers and leads already in place and are hiring in the middle, I'd go cheaper and go younger and you'd probably get much more bang for the buck AND they'd teach you a few things.

This isn't about "jack of all trades" vs. "interaction expert". This is about "redefining" what is important for Interaction Experts really do.

I think doing "deliverables" and "documentation" is much less important than being able to communicate final design that encompasses ALL aspects of the interface implementation short of production engineering.

People talk about "agile" and UX. Well, for me this is much more important and more real AND more agile. Don't go to code first, go to prototype first and let the designer DO it and let the coder sit on the sidelines (or fix the bugs they created in the previous rev).

If I never see "wireframe" as a deliverable again, I will be a happy man. The age of visio, omniograffle, axure, iRise, etc. I hope come crashing down (now offense to all the coders who worked hard on these tools), in favor of Fireworks, Catalyst, Flash, Blend and Illustrator, Coda, etc.

But that's just my crystal ball.

-- dave

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

FYI Dave, Fireworks is becoming a very popular wireframing tool...

And...to the broader point about wireframing...are you suggesting that a designer go right to prototype first, and have that be their ideation/brainstorming phase? Or are you merely suggesting that it's not a deliverable given over to the client?

I personally could not cut wireframing out of my workflow. I have to get something low-fidelity out there so I know where my idea stands. Skipping this step would be, for me, putting the cart before the horse.

Also, clients like wireframes...it's an easy way to iterate quickly about the broad interaction design issues, like what actually goes on the screen, and what priority each element has. If I had to write HTML for each of these iterations, it would slow things down considerably. (its possible that tools will improve to the point where creating HTML prototypes is as fast as wireframing, but until then...)

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

Sometimes wireframes are the only thing we produce. If your CSS is properly developed...

On Mar 11, 2009, at 8:37 PM, dave malouf wrote:

If I never see "wireframe" as a deliverable again, I will be a happy man. The age of visio, omniograffle, axure, iRise, etc. I hope come crashing down (now offense to all the coders who worked hard on these tools), in favor of Fireworks, Catalyst, Flash, Blend and Illustrator, Coda, etc

On 11 Mar 2009, at 20:37, dave malouf wrote:
[snip]
I think doing "deliverables" and "documentation" is much less important than being able to communicate final design that encompasses ALL aspects of the interface implementation short of production engineering. People talk about "agile" and UX. Well, for me this is much more important and more real AND more agile. Don't go to code first, go to prototype first and let the designer DO it and let the coder sit on the sidelines (or fix the bugs they created in the previous rev). [snip] That is how I see some agile/ux folk working. There were several folk [trim]

Russell Wilson wrote:

Admittedly maybe a few for programming: Software Engineer Software Programmer

At my past three software engineering jobs, I was a "Member of Technical Staff" on paper, as was pretty much everyone who did anything remotely technical, from QE to circuit board design. On the very senior technical people had titles, then it was "Architect" or "Principle Engineer", no matter what they actually did.

--

J. Eric "jet" Townsend, CMU Master of Tangible Interaction Design '09

design: www.allartburns.org; hacking: www.flatline.net; HF: KG6ZVQ PGP: 0xD0D8C2E8 AC9B 0A23 C61A 1B4A 27C5 F799 A681 3C11 D0D8 C2E8

Andrei Herasimchuk wrote:
If the title in the software world is going to be called "interaction design" then that person needs to know these hard skills:

Interesting list. I can think of a number of graduating seniors here who can handle 2/3 of your list pretty well and who are catching up on the rest of the list.

The one exception:
* Understand how algorithms, code, frameworks, databases and other software engineering aspects of the product work under the hood

I think this is a set of knowledge that rarely gets distributed outside of the computer science classroom. CMU teaches an intro-to-programming class (15-100) in Java and has recently added a section taught in Processing by Golan Levin. I've talked to a couple of seriously non-technical/artsy types who took it and came out with a vague understanding of how computers actually work and, more importantly, the desire to learn more about what they can do using code as a tool.

But it's certainly not a required class for ixd and it's a risky class to take as an elective as it can fuck up you GPA.

--

J. Eric "jet" Townsend, CMU Master of Tangible Interaction Design '09

design: www.allartburns.org; hacking: www.flatline.net; HF: KG6ZVQ PGP: 0xD0D8C2E8 AC9B 0A23 C61A 1B4A 27C5 F799 A681 3C11 D0D8 C2E8

On Mar 16, 2009, at 10:01 AM,
j. eric townsend wrote:

But it's certainly not a required class for ixd and it's a risky class to take as an elective as it can fuck up you GPA.

All the more reason to take it! It's a great way to learn how to walk the tightrope.

-- Andrei Herasimchuk

Chief Design Officer, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

My primary objections with Spolsky's article are pretty simple: I don't want to be a program manager, nor do I want to be mistaken for one, nor do I want to have to do things that program managers do. Having different titles for different jobs is, y'know, useful. If someone does happen to do both jobs, they can easily bill themselves as a "program manager/ux designer". There's nothing wrong with being a slashie, or with being precise.

timoni grone
www.timoni.org
www.twitter.com/timoni

Yes, Patrick there is a lot of "it depends" and YMMV to the reality of all this.

But if ActionScript and "pixel perfect" design is beyond you. Please move to strategy and management. Please!

The economies of scale require that there is a UI Designer. ONE person. The age of having an IxD, a Visual Design, and a GUI coder as 3 separate roles is fading. If anything one might say that it was a nice experiment by the IA/UX community to create the false need for such an experiment.

The one split that has always made sense to me is that of research & evaluation. BUT! that is the one hanger-on that I hear many IxDs, IAs, etc. want to keep. I'm not saying don't be a part of the process. Hell, we all know that the more stakeholders involved in research the better. What I'm saying is don't own it.

But back to the more important issue. When I hear Patrick say that actionscript (really? actionscript) or pixel-perfect design is beyond him. I at the same time concur and get scared. For myself really. I'm very much like Patrick. BUT! my access to these amazing students have me feeling OLD. Their energy and easy at which they accumulate knowledge and skills is so inspiring and intimidating. I had 1 student this past quarter learn drag & drop in actionscript for a 1 week prototype in a day or two having never used Flash before this class.

When it comes to pixels, script, batteries, screens, snap domes, plastics, databases, frameworks, OSes, etc. it is about material. It is like an ID who has to understand material science to some degree to even be in conversation with mechanical engineers. You have to know the material that people are going to be interacting with, how to forge it to what you need it to be AND to your point about communication, you need to be able to create your own apearance models. NOT b/c you have to do them in the real world, but having the craft mastered is a process of well mastering the craft of your medium, so when you communicate within it, or to others who have to understand it, you do so with unparalleled command.

In the IxDA panel that Jared Spool led. Jared asked where the next 5k (or was it 10k?) IxDs were going to come from. I say they are mostly already here. They are industrial designers who are already so used to dealing in human situated solutions around eco-systems of activity. They don't know Norman per se, but reading a few books is the easy part. They already know how to think within multiple dimensions (all 4 of them) and they know how to do it as a means of completing a narrative. Of course, there are many that don't get it. But there are many more that do.

I give it 5-10 years and I predict a major shift in interaction design practice & education away from majors and masters and into support tracks and electives for already existing degrees in interactive, industrial, and architecture.

-- dave

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

I give it 5-10 years and I predict a major shift in interaction design practice & education away from majors and masters and into support tracks and electives for already existing degrees in interactive, industrial, and architecture.

--

Agreed. At least to educate those that need enough to get by.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

On Tuesday, March 17, 2009 1:20 AM, Dave Malouf said:

to even be in conversation with mechanical engineers. You have to know the material that people are going to be interacting with, how to forge it to what you need it to be AND to your point about communication, you need to be able to create your own apearance models. NOT b/c you have to do them in the real world, but having the craft mastered is a process of well mastering the craft of your medium, so when you communicate within it, or to others who have to understand it, you do so with unparalleled command.

Okay Dave, you've mentioned this twice now and Google and Wikipedia are leading me to things that I can't quite tie to your quotes.

So, can you please explain what an "appearance model" is, in the context of IxD?

Thanks : )

Meredith

An appearance model is a term used in industrial design. It is the final model made that represents exactly the color, finish, shape, and behavior of a product. If it has buttons, you can press them. If there are doors you can open them.

Its purpose is to get final consensus from ALL stakeholders on go, no-go on every aspect of the product's industrial design. BTW, this is not the last representation. The next representations are usually soft-tooled products. This means that they are put through non-final tooled fabrication processes and WORK! (all aspects). There might be 2-3 rounds of this. These are used for physical testing (heat stress, drop tests, etc.)

In software IxD we don't use the term per se, but this is exactly what Andrei has been describing when he talks about final prototypes. It is an exactly looking & behaving model. It is that chance for everyone to see exactly what the team/client will be getting when it goes out the door to production. That yes/no.

hope that helps!

-- dave

On Tue, Mar 17, 2009 at 4:31 PM, Meredith Noble meredith at usabilitymatters.com wrote:

On Tuesday, March 17, 2009 1:20 AM, Dave Malouf said: to even be in conversation with mechanical engineers. You have to know the material that people are going to be interacting with, how to forge it to what you need it to be AND to your point about communication, you need to be able to create your own apearance models. NOT b/c you have to do them in the real world, but having the craft mastered is a process of well mastering the craft of your medium, so when you communicate within it, or to others who have to [trim]

-- Dave Malouf
http://davemalouf.com/
http://twitter.com/daveixd
http://scad.edu/industrialdesign
http://ixda.org/

Dave, I admire your ability to generate interesting conversation!

"The economies of scale require that there is a UI Designer. ONE person. The age of having an IxD, a Visual Design, and a GUI coder as 3 separate roles is fading."

The counter-trend is that a lot of front-end development is getting harder, not easier. Front-end web development is increasingly embracing advanced programming patterns, making it harder for designers to contribute meaningfully. Our tools are trying to catch up, but soon designers are going to have to start reading about OO patterns instead of design patterns.

Now, I strongly believe a CS minor should be a requirement for anyone designing software, but no one seems to be listening : )

"[an appearance model] is an exactly looking & behaving model. It is that chance for everyone to see exactly what the team/client will be getting when it goes out the door to production."

It's always struck me that one of the great leaps forward in working in software, and more so on the web, is the fact that our production processes are adaptable. So, why not make the most of this advantage and embrace parallelism? Build that pixel perfect prototype, but why make it a pre-condition of production?

-- jackson

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

HI Jackson,

On your 2 pts.

re: trends
No doubt the UI is getting more complex and the need for amazing programmers to work on them is important. But I think tools like Blend and Catalyst are stepping in and putting in a new layer that previously wasn't there and enabling designers to more forward. (see below)

re: the malleability of software and parallelism
yea, done that, been there. Seriously. This is a pipe dream. Design control is the only way to get designer intention out of production engineering. Phased approaches that separate pre-production & production will always produce more accurate results of the designer's intentions.

BTW, this problem is not only ours. IDs have this problem in studios where they don't take on the engineering schematics of all surfaces. In those cases, where it stops with mere models that are not in the engineering databases (sorry for too much ID speak; maybe you all should learn some) the ODMs often come in and change the outcome at points that can't be re-done. Oh Well!

Yup, this happens everyday in software too. So unless you have an appearance model that is fully signed off on with staged approaches of production checks that design reviews throughout with other stakeholders, you'll end up with skewed execution from the intention.

BTW, designs are not done w/o engineering collaboration. At least not where design is done well. That's a given. Also, often there are tons of parallel things to be done in the architecture and platform of systems (the stack) way below the GUI layer. So there ARE parallelisms for sure. Just not at the usable form layer of presentation and behavior.

- dave

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701

On Mar 18, 2009, at 2:52 PM, Jackson Fox wrote:

The counter-trend is that a lot of front-end development is getting harder, not easier. Front-end web development is increasingly embracing advanced programming patterns, making it harder for designers to contribute meaningfully. Our tools are trying to catch up, but soon designers are going to have to start reading about OO patterns instead of design patterns.

Front-end development is not getting harder. It's actually getting easier, especially for designers to contribute meaningfully. I remember teaching myself enough coding back in the early 90s on the Mac to draw windows, menus and dialogs on my Mac SE/30. That was a pain in the ass compared to the stuff I did with Hypercard then.

These days, doing HTML+CSS+JS or MXML+FlashCSS+AS is an order of magnitude easier. And what you can do with the technologies these days with the larger screen sizes, far more robust animation and compositing engines, richer APIs, etc., is far more advanced. Toss in things like Dave mentioned, Blend or Catalyst and there really is no excuse now for a designer to not learn enough scripting to get a prototype — or appearance model, using Dave's new religion of ID terminology — built.

It's only hard if you haven't been keeping up with the trends which are quickly reaching a critical mass of standards and flattening technology. The good news is this: Learning HTML and the DOM, learning CSS, and learning JS or AS is not rocket science. In fact, if you know professional creative software inside and out (Photoshop, Fireworks, Illustrator, InDesign, Flash, Framemaker, CorelDraw, Quark XPress, etc.) then you are more than a third of the way there as the concepts in traditional creative software permeates the technologies I listed. That can lead to other things like Ruby, Pearl, PHP, etc.

Not actively learning those things and claiming that you design interfaces will soon be like claiming to be a furniture designer but having no idea how a lathe works or how various types of wood handle stress and weight.

If you follow the parallels with high-tech products and the history of automobiles, you'll start to see that the high-tech is quickly coming upon what was known in the auto industry as "the golden age of design." The golden age of design was made possible once technology reached a critical mass while also standardizing enough to allow designers more freedom to spread their wings with the overall design of the car, which became increasingly more important in how car manufacturers differentiated themselves in the market. When that age hits the tech industry, those that don't know the skills or craft with their own two hands will quickly be weeded out. There's still time to catch up however.

To close, I got a demo of Shaun Inman's new Fever feed reader while at SXSW. ( http://feedafever.com/ ) Simply put, it's amazing. Shaun designed and coded the whole thing himself, and he did it in a year's worth of time rebuilding the entire product three times over. The Shaun Inman's of the world are the future in this field with regard to skills, craft and aesthetic.

-- Andrei Herasimchuk

Chief Design Officer, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

Dave & Andrei,

I completely agree that our ability to produce interactive prototypes has increased significantly. Better libraries, better tools, and better platforms (web standards FTW) have made it easier than ever to produce models of interaction.

I think I may have misunderstood Dave's point about not needing GUI developers — I was approaching it from the point of view of production engineering, and I see now that he was talking about prototype development.

I was trying to make the point that front-end production is getting more complex. Look at the work that Douglas Crockford and others have done in bringing sane development patterns to Javascript. They make JS more powerful, but at the expense of requiring a much deeper knowledge of the language and OO design patterns.

-- jackson

Posted from the new ixda.org
http://www.ixda.org/discuss?post=39701