|
|
|
|
|
|
|
|
|||||||
|
Argentine tango blog: Interaction Design interludes by Oleh Kovalchuke |
|
|
|
|
|
|||||||||||||||||||||||
|
|
|
 |
 |
 |
 |
|
|
|
|
|
|
|
|
|
|
||||||||||||||||||
 |
 |
 |
|
 |
|
||||||||||||||||||||||
|
 |
|
|
|
|
||||||||||||||||||||||
|
 |
 |
|
|
|
|
|
|
|
Interaction Design Process and Tools
July 3, 2006 - Process and people
No process will substitute for talent and for human relationships. It must be obvious, but often it isn't (due to peculiar property of human mind to look for the simplest and uniform solutions). And so the self-evident reminder is due here: Process is not solution, it is only facilitator - it can remove some of the hindrances to personal contribution and to effective team work, but it will not replace talent. Emphasize outcomes, play to personal strengths and process will evolve around available personalities.
June 9, 2006 - Well-run interaction design process [designer perspective]
"Creating cooperative technology requires cooperation among team members."
Isaaks & WalendowskiI. Research product necessity and goals
- Find out business goals via meetings with marketing, sales, and management.
- Find out user needs, stereotypes, language, coping habits, cultural norms, environment, relevant experience via contextual interviews, marketing research, competitive analysis, questionnaires, support, QA and sales feedback.
- Build model user persona as validation reference.
- Establish rapport and involve engineering.
Outcome: Functional requirement document: well-formed reasons for doing this work, networking, good karma; user goals and task list; prioritized task list: Core (impossible to use without), Important (can't ship without), Nice-to-have Great Idea in Excel spreadsheets or Word docs.
II. Build conceptual model
Build conceptual workflow from user perspective. Consider usability, learnability, simplicity, safety, change
- Define user-product interaction objects and transactions on the objects, brainstorming
- Group objects into frequency and commonality matrix
- Group objects into task relevancy and importance matrix, card sorting
- Define at least two task flows from user perspective - cognitive walkthroughs: ideal and with errors
- Validate conceptual model (especially language) with users, focus groups, interviews
- Validate conceptual model with engineering, involve developers in the interviews, solution meetings, brainstorming.
Outcome: Information architecture and task flow in Excel spreadsheets or Word docs, Visio diagrams
III. Design interaction prototype
- Build wireframes in Visio, PowerPoint, PhotoShop, Flash, pencil-n-paper etc.
- Usability test wireframes with users, heuristic evaluations with design experts.
- Validate prototype feasibility with developers.
Outcome: Prototype wireframes in Visio, PowerPoint, PhotoShop, Flash, pencil-n-paper etc; good karma
IV. Design visual prototype, templates, write guidelines
- Design PhotoShop layouts
- Functional specs for development: visual screens complemented by detailed interaction description - Visio and/or Word document.
- Usability test the prototype
- Code HTML templates
Outcome: UI functional specs and guidelines for visual implementation and interaction (annotated storyboard). Feature list.
V. Build working product with core features only
- Usage test with users, get logs, feedback, direct user observation, surveys.
Outcome: Smooth interaction for core tasks. Interaction bugs revealed.
VI. Tweak core features, build the rest of the product as time allows
"And they looked upon the software, and saw that it was good. But they just had to add this one other feature..."
McCormick.
- Usage test with users, get logs, feedback, direct user observation, surveys.
Outcome: Enjoyable user experience, sales. List of user tasks to include in the next release.
Known impediments to the well-run process: (should be addressed at stage I): historical approaches to development, inertia, social ineptness of designers, misconceptions of designer role, management buy in.
Notes:
- Some of the steps are optional, depend on product (conceptually new or upgrade, content, hardware) and on domain knowledge of designer. Some of the steps are iterated several times based on validation feedback.
- Usage testing is preferred for frequently used products [IM, email apps.]. Usability testing - for infrequent use (ATM, web).
Sources:
Cooper & Reimann "About Face 2.0", Csikszentmihalyi "Good Business", Johnson "GUI Bloopers", Isaaks & Walendowski "Designing from Both Sides of the Screen", Kelley - "The Art of Innovation", Leveson "Safeware", McConnell "Rapid Development", Norman "The Invisible Computer".
February 16, 2008 - Good talks from the first IxDA conference (Interaction 2008, Savannah, GA)
The Design Ecosystem by Bill Buxton, Microsoft Research.
Design culture - right tools, process, technique, partners, attitude (and design politics of mutual understanding of business, design, and engineering goals). Many ideas bring along good ideas, thus the importance of "throwaway sketching".
Concept Models, A Tool for Planning Interaction by Dan Brown, EightShapes
Mind mapping to analyze and understand domain. Concept models (Joseph P. Novak from Cornell) precede flowcharts and wireframes, at the very least vocabulary is agreed upon. They define scope - inventory of concepts (list of nouns from domain experts) and interactions (remove redundancy). "Views" and "components". Validation - implications (importance, what is missing etc.). The concepts from the expense report as an example. Circling nouns in the requirements doc is an interesting approach.
User Interface Design in an Agile Environment Jeff White and Jim Under, Jewelry TV.
Description of Agile development (role sharing, mentoring, sprints, team ownership).
"Design Studio" - brainstorming with examples:
- define user goals, IA (the data, the objects, the interactions, which should be included in the prototype), scenarios (empathy), tasks, concept models - 5-6 days to 1 month
- brief engineers
- everyone comes up with possible sketches (~2 h, 4-7 concepts per person, not one elaborated concept)
- the sketches are discussed (facilitation), agree on the best ideas (explain why): 2 minutes per concept presentation, 8-10 minutes discussion (write good/bad ideas from the concept on giant post-it notes)
- take a break, review the goals. Consolidate good ideas into one design.
Redesigning Sony Ericsson's Product Catalog by Saskia Idzerda, Media Catalyst
Good, practical and illustrated story of website re-design with international perspective. Agile prototyping. As far as I could see, the sliders were tested with one pointer only. I wonder, if the testing results would be different, if the sliders had two pointers to select a range of values. Also"green" is not good indicator of size. Good observation on limitations of usability testing vs. statistical analytics (multivariate or A/B tests).
July 19, 2006 - Process (and IxD politics) insights from IxD list
From John Schrag on control of initial design
One thing we've been doing with some success is getting all these people together not for a 'design' meeting, but for a 'requirements' meeting. This keeps everyone focused on the problem they're trying to solve, and not how to solve it. I ask questions like "What should the user be able to do when we finish this that they can't do now? What other features does this have to work with?". When the discussion gets to UI design (as it always does), I say "I've noted that idea, but let's not worry about details of the UI design until we get all the requirements down."
I find that it is useful to have developers, marketers, QA, etc involved at this stage, because they are often aware of technical, competitive and business requirements which are beyond what your user studies might have shown.
We design the UI outside of that meeting, and then usability test and refine it. Then we bring it back. We still run into debate about the UI at this point, of course, but it's powerful to be able to say "Well, it meets all the requirements we came up with together, and it tested really well. Which part of that do you want to change?"
From Dan Saffer
Alan Cooper in one of his books suggests that interaction designers should have two reasons for every design decision they make. The reason, he says, is for just this purpose: when people want authority over your design, you have ammunition. Otherwise, your "opinion" is just that, and everyone, right or wrong, can have one.
From Russell Wilson
On one product we have had the ability to do this (define the vision early) and I've had quite a bit of success. However, I'm encountering much more difficult issues when redesigning existing products where there are many problems, little to no conceptual integrity, but developers are *defensive* of their existing work.
From Sabine Junginger
You might have already tried this, but from my experience it is very effective to demonstrate the consequences of the conceptual *dis*integrity from a user's perspective, documenting the resulting disconnects and detours in terms of the user pathway. Many developers do not understand these consequences until they hear it directly from the people they think they know so well. Once you introduce the user, user pathways and user experience, the tension is no longer between the old "designers" (which is what most developers consider themselves to be) and the new design experts, but about the need to make it easier and more enjoyable for people external to the organization to use their products.
From Lada Gorlenko
Think big and fight big. Separate design critical decisions from the rest. Trade non-critical decisions, if they buy peace and progress. Don't come across as someone who always wants to be right about design, even if this is exactly what you are paid to do. Come across as someone who fights only when the fight is worth it.
From leo frishberg
So, let me start by using my favorite counter-argument to the notion that the embedded software and hardware team should have an opportunity to opine on the UXD: "Would you like my input on the chip layout? Would you like my opinion about your object classes?" This usually causes them to pause, laugh nervously and we move on.
I have had inordinate success here in wrenching "design" (specifically UXD) from the development team for several reasons:
1) The group tried several different strategies prior to my arrival (this took many years of different trials-by-error) before they figured out that they really didn't know what they were doing
2) The group also determined, through these experiments, that they needed a professional immersed in the science and art of IxD/UXD.
3) They also figured out that they couldn't do this with part-timers (either contractors or individuals from our central engineering team) because of the need for deep domain knowledge.My "success" results not so much from my own "genius" or "great design" work (I haven't really had the time to show off anything that would cause anyone to gasp in astonishment), but instead from the team's active engagement in sincerely trying to improve their design/development process and failing with every attempt to date.
With that said, however, I haven't been sitting idle for two years. Instead of rushing in and attempting to revolutionize the application interface, I suggested that we needed a solid body of user-centered research to help guide us. Note the 1st person plural. While it was primarily ::me:: doing the research, I made sure that development / marketing team members accompanied me whenever possible.
During the very frequent feedback sessions to the team about the research progress, I revealed to them patterns of use that they found simultaneously familiar and surprising. An odd mixture, but one that helped establish my credibility: "Our users are doing such-and-such - sound familiar? But we aren't providing an interface to support that activity....why not?" I suppose that this dovetails with the discussion about requirements gathering mentioned so far. But it goes beyond that - it is changing the culture of the development team from focusing on ::me:: and focusing instead on bona fide ::users:: a critical shift if I'm going to get them to stop opining about what the UI ::should:: do.
With that foundation established, it has been relatively smooth sailing to begin changing the interface; in some cases radically. The conversations I have with development are predominately around what is technically feasible, where the big infrastructure "gotchas" are and so forth - exactly the rich discussion that should be going on. In addition, the marketing and development teams are required reviewers of the UIS, and I'm very glad for it. Both functions have found holes in the spec, seeming contradictions, apparent violations of O/S standards, etc. which only numerous pairs of eyes can find. Thankfully, in all of the reviews, very little discussion about what the UI "should do" have come up; instead the presumption is that the proposed UI is good for the user and we need to make it even better.
From: Mark Schraad
1) Sometimes the engineers are right, and it is worth giving them some real consideration.
2) If you are an ethnographer debating a positivist (sometimes qualitative vs. quantitative) it helps to be have sufficient expertise in the oppositions camp. This establishes credibility and allows you to debate with a common language.
3) I have had great success using evidence. And, qualitative is evedentury. I have also had better success with cognitive speak than behavioral speak. To many, cognitive is perceived as science and behavioral as art.From Dave Cronin
- Base your decisions on ethnographic research. I've found few things that silence critics as quickly as apt anecdotes and observed behavior patterns.
- Define (and agree on!) the problem before proposing or evaluating solutions.
- Figure out constructive ways for the whole project team to participate early enough in the process to entertain divergent thinking without it becoming counterproductive. I'm not necessarily advocating playing with legos or brainstorming (though those are both fun).
- Depersonalize solutions by focusing on serving the needs of personas/user models/roles/whatever you like to use (i.e. it's not about "my idea" versus "your idea," but about serving the needs of "nancy.") This also helps with the defining the problem bit.
- Be willing to throw your ideas out. If you're a good designer, and you've got a strong solution to a complex problem, my experience is that nothing is going to freak the team out more than going back to a blank slate. After about 5 minutes they usually come running back to what you proposed (whether they give you credit for it is another question ;).August 26, 2006 - Required personal skills for interaction designers
Successful interaction designers are organization hubs, they have to interact with variety of people across organization. Therefore an important and unavoidable part of interaction design is politics. I don't think political skills are taught in design schools. To make matters worse, not every personality type is adept in social interactions.
"First, Break All the Rules" (good book) describes environment in well-run companies. It touches on, but doesn't cover in detail internal politics, especially those in the not-so-well run companies, where managers do not read insightful managerial books. The topics touched upon in the book are importance of personal status and relationships.
-------------------------------Let's see... The useful personality traits for interaction designers: analytical, creative, socially adept (communicative, assertive, amicable, perceptive of group dynamics) + technically knowledgeable. Taken singly these personal traits can be found with relative ease. All together, in one body - not very common combination. Moreover this is the same infrequent combination of personal traits often found among entrepreneurs - a drain on the pool of available employable designers.
Hm. Add good sense of humour and you have someone almost good enough to take out for dinner and long walks on a beach...
September 17, 2006 - Bits of wisdom from Jared Spool, Inc.
First, several interesting audio clips (in mp3) of Jared talking to other knowledgeable design and usability folks. More usability audio at UXpod User Experience Podcasts by Gerry Gaffney.
Second, very good, insightful article on usability testing: Seven Common Usability Testing Mistakes (with concrete approaches to fixing the mistakes). There are more articles where this one came from.
July 2, 2006 - In defense of Vision-Centered Design (Activity-Centered Design vs. Human (User)-Centered Design)
Stimulating if meandering article by Donald Norman: Human-Centered Design Considered Harmful.
The starting postulate is simple: human centered design process is well suited for incremental design improvements – it evaluates if and how design idea conform current set of user expectations, current user goals, mental models, practices. Human centered design process is less suitable for evaluation of disruptive technologies, ideas.
This is not limitation of process per se. This is due to natural limitation of our human mental abilities (and, by the way, relates to recent thread on cognitive load): we have hard time imagining alternative outcomes.
According to Klein’s book on decision making, when we construct mental simulations we are limited to three changing objects interacting for six consecutive steps. Disruptive ideas, technologies are disruptive precisely because they don’t fit with the rest of common expectations, they re-arrange many more than three existing practices in novel ways. The corollary, born in history, is that we, humans, are notoriously poor predictors of future developments of disruptive technology ("The phonograph has no commercial value at all." - Thomas Edison, 1880s; many books are filled with examples of this phenomenon).
Robert Reimann writes: "I would argue that understanding human goals in the context of products and systems provides the clear vision of the end result that Norman finds elusive, while significantly mitigating the risk of failure. I believe that this understanding comes from well-developed user models that capture the essence of human behaviors and motivations pertinent to the design problem at hand."
----------------------------------------------------------
Given natural limitations of human mind, Norman’s concerns about constraints of evaluations used in HCD process appear to be well-justified. The crucial questions, unarticulated in his article then are these: “Who is going to be the judge of applicability of disruptive design idea?”, and: “What is his/her track record as far as disruptive ideas are concerned?”
----------------------------------------------------------We know the answer at Apple (Steve Jobs). The answer to these questions doesn’t mean that human centered design process should be discarded (here is where Norman went wrong), rather that it should be applied with gusto where there is need for incremental improvements. There are many, many areas where this is true. On the other hand, negative results of HCD user modeling and evaluations should always be taken with doubt, and possibly dismissed by stakeholders whenever disruptive technology is suspected (here is where Norman went right).
Finally, activity centered design process should be encouraged as long as it’s own limitations are understood: it is not a magic bullet - ACD removes focus on current user expectations, and thus might facilitate innovation, however someone (human, not process) still has to dream up the crazy idea, which may or may not be viable after the venture capital financing runs out.
Or as Norman states: "Great design, I contend, comes from breaking the rules, by ignoring the generally accepted practices, by pushing forward with a clear concept of the end result, no matter what. This ego-centric, vision-directed design results in both great successes and great failures. If you want great rather than good, this is what you must do."
An interesting follow up question then is this: "Which technologies could be disruptive today?". I will not break any new ground if I say digital appliances, designed for specific activities. Hm, "designed" for "activity" - "Activity Centered Design"?
-----------
As I said in the beginning, the article is meandering: there are interesting observations on dynamic nature of interaction, and on error handling, on system approach to design - all of these can and should be addressed within framework of HCD process.
October 22, 2006 - Four categories of design
James Leftwich, IDSA wrote:
"Perhaps two, if not more categories in place of one labeled "genius design" would be better. As it's currently being defined, it would probably be better renamed, "inexperienced, unskilled, untalented design," since that's exactly what's going to produce failure."
In any design process there are at least two important parts: information about future use of the product, and then there is creation part. Quality information facilitates, but does not guarantee brilliant final creation. On the other hand, poor information will most probably impede creation of useful, good designs.
"Misinformed", and occasionally "uninformed design" would be better labels for failed "genius design" to distinguish it from "UCD", reflecting the fact that significant part of UCD process is gathering information about the future use.
The information can be accumulated via UCD research or via extensive personal ("expert") experience in the field. Creation, on the other hand, is driven by specific individuals.
Since creation part depends on personal abilities, the value of individual "expert design" can be enhanced, but cannot be replaced by information provided by UCD research. Thus "untalented design" is always a possibility. However one can find "untalented" designs created either via user-centered or via less-obviously-user centered process.There you go...
Four design process categories:
- informed + talented => successful genius, successful UCD
- informed + untalented => failed UCD
- misinformed + talented => failed genius
- misinformed + untalented => failed "genius"
Four comments about this classification:
- It is too simple. There is no such thing as all encompassing, perfect classification - read Women, Fire, and Dangerous Things by George Lakoff for details.
- It does not detail how one becomes informed.
- It does not cover the complex process of design implementation (admittedly, an important part of any successful design).
- It does highlight user information gathering of USD process.
May. 3, 2006 - Brainstorming - get physical
A month ago I wrote that lowly Post-It notes might be better tool for brainstorming than mind mapping software, since the notes "seem to be more collaborative ... because people get a chance to physically move around, play with their hands while pasting notes on white board."
I was browsing through 'The Art Of Innovation' by Tom Kelley (someone recommended this book to IxD list) and in the chapter on 7 brainstorming secrets I have found Secret 5. The Space Remembers on the power of spatial memory, and Secret 7. Get Physical on using sketching and other visual and physical tools. They do not use Post-It notes at IDEO preferring giant wall paper to jot down the ideas. Otherwise the notion of benefits of physical involvement in brainstorming is validated (IDEO designed more than 4000 products by year 2000, brainstorming is standard tool in the company).
Mar. 28, 2006 - "The Brain", and "MindManager", and Post-it notes
I wonder if anyone used the low tech approach: mind mapping, brainstorming and categorizing with Post-it notes. How does it compare to software?
On positive side Post-it notes approach seem to be more collaborative, to have lower participation threshold by virtue of being low tech (similar to paper prototypes) and because people get a chance to physically move around, play with their hands while pasting notes on white board. Is this correct assumption about ease of collaboration?
The setbacks I see: 1. No remote participation, 2. Archiving results for reference and 3. Revising them later on. #2 can be easily solved by taking a picture of final map and printing it. Solutions for #1 and #3 are possible but messy.
Lyle Kantrovich wrote:
I've been using MM for about 4 years. I love it for notetaking, crafting agenda, brainstorming, analysing concepts or hierarchies, and for quickie sitemapping.
What's great is it frees you (and prevents you) from thinking much about presentation, and focuses you on the content. Visio, on the other hand leaves you playing with boxes and connectors way to much. Sometimes I'll move from MM to Visio or another tool, but MM has become a "must have" app for me.Apr. 7, 2006 - Reality bats last
On brainstorming new designs Josh Seiden wrote about approach used by Cooper:
"reality bats last" means that eventually, reality will impose itself upon your thinking. Reality never needs an advocate.
To illustrate the inevitable imposition of reality further: you are an interaction designer (first reality imposition); someone asks you: "Could you redesign this ATM card?" (second reality imposition); you reply: "Who needs ATM?" and go to live in a desert for the rest of your life (I have skipped couple steps here).
Well, this kind of reasoning is exceedingly rare (Buddha comes to mind). Hence "You do not need to advocate for reality it will take care of itself" is really good approach. New solutions (creativity) will always be based on rearranging patterns from experience anyway (another plug to Hawkins book is due here). Try to reach for untapped, weakly connected patterns.
Mar. 20, 2006 - On functional specs and prototypes
Two interesting links: Cooper's article and No Functional Specs. Both make sense.
Random
Two books:
"Surely you must be joking, Mr. Feynman!" by Richard P. Feynman - occasioanlly annoyingly coy. It was curious to see the transition from "what is [annoyingly] clever" to "what is needed" in his motivation since I went through the same at some point. The same transition has happened and is mentioned in Alan Cooper's book on interactive design "The inmates are running the asylum". Since the inmates are still mostly young interactive design has to be separate discipline.Another analogy found in "Surely you must be joking, Mr. Feynman!" and "The inmates are running the asylum". Both guys use concrete examples to quickly assess viability of assumptions. Cooper builds fictional yet well defined personas to see in his mind if specific software feature is helpful to users, Feinman uses examples provided by theory creators.
From Louise Ferguson (who spends much of her time on ethnographic research in organisations):
Anthropologists know that 'why' is not a good question. People are forced into a corner and rationalise. 'How' works much better, and generally brings out the latent whys.
That's why contextual interviews are more effective for finding out user goals than marketing surveys or business analyst's question-'n-answer interrogation technique.
Incidentally asking how questions instead of why is good approach in personal relationships too.
Aug. 22, 2005 - You get what you measure
I have went to Turnverine practica in Denver last week where it was proudly announced that membership in Tango Colorado will soon hit three hundred and and the announcer urged everyone to pull together to reach that number sooner than later. This focus on numbers has been persistent for a while.
"You get what you measure" - I think this notion is from the Dilbert's book on management I have read recently. Numbers are easy to measure and often could be useful metrics in business especially when if one measures cash flow analysis and such. However when it comes to measuring growth in the essentially recreational activity, some measure of people's satisfaction with their experiences would be better metrics.
For instance one could bump up membership numbers by making members activities more exclusive via price incentives, members only privileges... Membership numbers will go up. Will overall health and satisfaction in a given tango community at large increase? I do not know since these things are not measured (harder to measure of course). However, as far as I am concerned, arm twisting approaches in general do not build a lot of good will as far as I recall from some less than pleasant high school experiences. These approaches are also divisive by nature, not inclusive.
Jan. 17, 2006 - Marketing and blinking decisions
First marketing quote from Harvard Business School article:
"People don't want to buy a quarter-inch drill. They want a quarter-inch hole!" - Harvard Business School marketing professor Theodore Levitt
The above statement is the essence of goal-oriented design. In this case Marketing overlaps with User Experience. The common difference between the two is that Marketing deals with buyers and therefore emphasizes immediate visceral perception of the product, while User Experience is about users and is concerned with long term effect of the product on the customer.
Another article is from Nature, Web users judge sites in the blink of an eye essentially reiterates conclusions of Blink by Gladwell this time for websites. Visceral, reflexive choices (Norman) made via ventromedial prefrontal cortex (Gladwell) due to repeated exposure to 10-20 favorite sites such as Google. In fact the title of the article hints at that book.
Google factor:
"These days, enlightened web users want to see a "puritan" approach"
"People enjoy being right, so continuing to use a website that gave a good first impression helps to 'prove' to themselves that they made a good initial decision."The last quote describes common "Aesthetic-Usability" effect. Mimicry via pure graphic design also might create it. Keeping and deepening this effect with subsequent usage is what frequently overlooked by Marketing, of concern to Usability and where blink judgement could fail.
May. 8, 2006 - What is the best way to explain Interaction Design to Marketing?
To paraphrase Drucker: from a business point of view Interaction Design has the same objectives as Marketing - it makes Selling superfluous.
May 9, 2006 - Marketing and Interaction Design interactions
From Jim Leftwich:
This is actually an excellent, if fairly complex question, since any answer or discussion would depend upon the configuration, hiearchy, workflow, and interdepartmental interrelationships within your (or any) company. While many companies share some of these in common, in general, each company structure and culture is likely to be different.
First off, I notice that many people don't often differentiate between "Product Marketing" and "Marketing Communications." Product Marketing is deeply involved in defining product requirements, often resulting in a document with a name like MRD (Marketing Requirements Document). This is often the result of both market research as well as external partner/corporate customer requirements. Marketing Communications (MarCom), are the folks that deal with advertising, tradeshows, etc.. In some, generally smaller corporations, these may be combined. Or, it may be a single department, with individuals within filling these roles.
FIrst off, as a designer you need to understand how Marketing and Design are historically/currently configured in your corporation.
Product Marketing, particularly in companies that have close working relationships with other entities (for example the mobile device industry, where a handset manufacturer or software company will often have much of their functionality and features aligned with the requirements of a carrier. The same holds in the settop box/cable operator field). In companies like this, Product Marketing is (in every corporation I've been involved with) *the* group that interfaces with these large entities. Often in these companies, Product Marketing leads design (either directly, or in the chain of workflow). Designers in these companies, if not empowered (another issue/discussion), often might as well wear paper hats and ask "Would you like fries with those icons/interface flows?" ;^) In other words, in those configurations, design doesn't lead. It fills orders.
In those situations, it's best to approach Product Marketing as you would your new large cellmate. Heh. They're likely to call the shots.
Also, the age of a company will often affect how Product Marketing is positioned and empowered. If your company is currently selling Blahware v18.0, and there's a big nasty bloated feature list as long as your arm, that will generally indicate the hand of Product Marketing. Remember, that kind of product direction is not always what a designer might do, if in charge. A designer might want to radically simplify and purify the user experience. Be forewarned that this is a conflict that is fundamental in companies where *improvement* means feature-bloating. And in companies where design is unempowered, well... bend over.
It's a complicated issue, however, because not all feature addition is bad (of course). It's just that the Product Marketing values are not always the same as Design values.
As for explaining design to Product Marketing, find out first how they understand Design. You'll need to start an explanation at the point they're familiar with, and lead them toward whatever vision or role you see Design as having. Invite them to observe your Design process. Show past projects and workflows. Show past gains and improved products.
Ultimately, strong, design-informed Product Marketing together with experienced and big-picture-informed Design makes the very best combination within a company.
Jan. 15, 2006 - Kingdomality – an astrology for modern age
I went to community dance at Denver Turnverine this Saturday. The very first thing one of the girls has asked me there was: "In which month have you been born?". The question is so common that instead of April I have answered: "I am Aries".
Why is it that so many people are taken with astrology even these days when we know that humans are rather insignificant in scale to be of any concern to planets and stars? The reason seems to be that we find comfort in simple labeling. Knowing that someone is Ram and Tiger let us project their behavior, future income and even prospects of successful of marriage to Scorpio Rooster. In other words by using conceptual models of human interactions astrology explains society in simple understandable terms. Too bad that stars and planets are not aware of the ulterior motives assigned to their movement. Given this celestial ignorance mistakes about projected outcomes of human interactions are bound to be made. The inevitable misfires are explained away by human error of the interpreter – "stars suggest" etc.
It is fairly obvious that there is persistent need to be able to answer the perennial question: “What is the Matrix?” or as others put it thousands years ago “What is the perfect City?”. Here is where numerous personality classifications step in. By the way I think Aristotle’s engineered totalitarian City was overly mechanical and therefore both exceptionally cruel and unexceptionally preposterous.
I like personality type classification presented in Kingdomality for two reasons. First, the classification is simple, rational and therefore easy to apply. Second, interactions among different personality types are clearly defined. Thus one can easily see not only his own strengths and weaknesses but also how those are amplified or subdued by interactions with other personality types. In other words it provides “good enough” model of society on personal level. As a purely practical application personality types of Kingdomality can be used by interaction designer to provide initial rough sketch of primary user persona. I'll use it to describe primary persona of typical engineer.
September 30, 2006 - More on personality profiles
Suddern burst of discussion about personality traits of interaction designers on IxD list. Cheryl Kimble wrote:
does anybody have this issue?
my old boss was an intj and i an infj. we absolutely couldn't work together. the f was so abstract (idealists) and the t was so concrete (rationals) that we never seemed to understand where the other was coming from. also, f's like to work in teams and t's like to work alone.
This is why I got interested in personality profiles - to understand where the other people are coming from and where to forward them in their further journey.
By the way, rumor is that women come from Venus... Could be true according to one of the articles The Scientific American Book of the Brain. Another article in the same volume dicusses IQ and is relevant to the recent thread on social classes and interaction design. Good book for casual, spare time reading.I have written about personality profiles before, when I was reading about them extensively [1], [2]. Incidentally, I am INTP, and Prime Minister. Just took the test again and got INTJ instead of INTP.
|
|
|
|
 |
|
||||||||||||||||||||||
|
|
|
|
|
|
||||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
