Jobs on Entrepreneurship

And a few words from Jobs on the hardcore challenges of being an entrepreneur, also circa 1995:

I get asked this a lot and I have a pretty standard answer which is, a lot of people come to me and say "I want to be an entrepreneur". And I go "Oh that's great, what's your idea?". And they say "I don't have one yet". And I say "I think you should go get a job as a busboy or something until you find something you're really passionate about because it's a lot of work". I'm convinced that about half of what separates the successful entrepreneurs from the non-successful ones is pure perseverance. It is so hard. You put so much of your life into this thing. There are such rough moments in time that I think most people give up. I don't blame them. Its really tough and it consumes your life. If you've got a family and you're in the early days of a company, I can't imagine how one could do it. I'm sure its been done but its rough. Its pretty much an eighteen hour day job, seven days a week for awhile. Unless you have a lot of passion about this, you're not going to survive. You're going to give it up. So you've got to have an idea, or a problem or a wrong that you want to right that you're passionate about otherwise you're not going to have the perseverance to stick it through. I think that's half the battle right there.

Blogged with Flock

Steve Jobs on Organizations

A small departure from studio-based lessons from Andrei...now let's hear what Jobs says about organizations vs. start-ups, circa 1995:

One of the things that happens in organizations as well as with people is that they settle into ways of looking at the world and become satisfied with things and the world changes and keeps evolving and new potential arises but these people who are settled in don't see it. That's what gives start-up companies their greatest advantage. The sedentary point of view is that of most large companies. In addition to that, large companies do not usually have efficient communication paths from the people closest to some of these changes at the bottom of the company to the top of the company which are the people making the big decisions. There may be people at lower levels of the company that see these changes coming but by the time the word ripples up to the highest levels where they can do something about it, it sometimes takes ten years. Even in the case where part of the company does the right thing at the lower levels, usually the upper levels screw it up somehow. I mean IBM and the personal computer business is a good example of that. I think as long as humans don't solve this human nature trait of sort of settling into a world view after a while, there will always be opportunity for young companies, young people to innovate. As it should be.

Blogged with Flock

How to properly capture screenshots for a spec

- Open the file in PS
- Crop down to the UI element to be doc'd
- Convert to index color
- Set the image dimensions in the Image Size dialog box in increments of 100 percent (set the droplist value to "percentage")
- Set the resample image droplsit menu to Nearest Neighbor to ensure pixel accuracy
- Do the redlining/annotations in PS itself (create a new layer, etc.)
- Save that as a PNG (flattened)
- Import it into Word (which will likely have its own set of issues, but that's a separate problem :-)

Consistency vs. context

It's vital for UI elements to be consistent across different parts of an application, so as to improve learning curves, encourage familiarity, ease of use and recall of how to use. However, if a particular part of the application requires a different visual treatment or UI element or behavior due to the nature of the context (a form layout vs. a table or tree), then by all means just do what makes sense for that context--do the right thing! Forcing consistency for the sake of consistency isn't the best prescription if it conflicts with the needs of a certain context/situation.

Upcoming design conferences

FYI, several design conferences coming up this year; better start booking now! You know, if I won the lottery I think I would go "conference hopping" from venue to venue, while drawing comic books on the plane rides :-) Enjoy!

-------------------------------------

Game Developers Conference (san fran): Mar 5 - 9
Various passes from $200 to $2100

SXSW (austin): Mar 9 - 13
Various passes from $300 to 850

O'Reilly Emerging Tech Conf (san diego): Mar 26 - 29
$1390 just conf sessions

CHI 2007 (san jose): Apr 28 - May 3
$725 for members / $925 nonmembers (early Reg)

MIX 2007 (vegas): Apr 30 - May 2
$995 early / $1195 regular

HOW Conference (atlanta): June 10 -13
$935 / $1125 with workshops

SIGGRAPH (san diego): Aug 5 - 9
fees to be posted soon...

Flash Forward 2007 (boston): Sep 19 - 21
various passes, from $50 for exhibits only to $1100 for a 3-day pass

AIGA National (denver): Oct 11 - 14
$725 members / $925 nonmembers

IDSA/ICSID 2007 (san fran): Oct 17 - 20
$895 members / $995 nonmembers (early Reg)
(warning: it's a terrible flash site with audio)

DUX 2007 (chicago): Nov 5 - 7
fees to be posted soon...

The box exercise

Not to be confused with the "box model" of CSS layouts, but somewhat indirectly connected later on in the UI process, the box exercise is foremost a collaborative method of organizing information into potential layouts that can serve as a baseline for photoshop-level comps/explorations. The method connects two traditional but typically separate activities that seemingly have nothing in common: card sorting and magazine layouts. To make this method work, you gotta have a) key members of the team participating (marketing, engineering, design, etc.) b) tons of post-it notes and c) a huge whiteboard to stick and re-stick those post-its.

Basically the process goes like this (block out a few hours, too):

1. Unpack all the contents of the UI to be designed and write them down on post-it notes (one concept per note). For example, if re-vamping a navigation bar, write down all the menu items, tabs, search fields, etc. that constitute that navigation area. Having the product team domain experts (from mkting, engin, QA, etc.) is crucial for this to work well.

2. Gather those notes into groupings that seem to make sense in a semantic way (caution: semantic is a hugely loaded word so please use this term lightly in this case; ie, i'm not referring to XML semantic validity, etc.)

3. Iterate successively on those groupings, constantly questioning why the clumps are what they are, why can't this item go over there, etc. Move towards smaller, meaningful groups of notes. This is why you want folks from dev and PM--starts to force questions about assumptions, functions, relationships, etc. and lots of "why do we have this anyway?" kind of thinking...

4. While grouping, assign a simple, meaningful label for each group that captures the gist of what that group is about. Naturally there will be changes and debates but pick something and move on. Avoid marketing terms, just get to the heart of what it's about functionally or semantically. Use the domain jargon if appropriate for the user audience.

5. List out the groups on the side, giving an approximate percentage of importance for each group. For example, File Exchange functions might be 75% of the navigation bar because it's for a data transfer application, while User Prefs would be only 5% since it's done once and typically not re-visited after that. These percentages will be useful for the next step.

--- So that is basically the card sorting portion of the exercise. Usability purists will note that a true card sort activity can last for days, usually involving hours spent with one domain expert at a time, not multiple folks simultaneously. And of course a detailed report suggesting recommendations emerges from the activity. The goal here is expediency and getting to action/decisions to move the process forward in a real-world product development situation. Remember, real artists ship! ----

5. Now we get into the magazine layout part of the process. Mindful of the group labels and their respective percentages, draw on the whiteboard some boxes for the groups--they're just layouts. NOT UI controls or widgets! That's later on... You want to do this fairly quickly, no more than 2 minutes per layout drawing, generating 3-4 per person (yes, force those PM's and developers to draw!). Helpful to use different colored markers for each person.

6. Now step back and discuss each layout, the rationale and issues (but not getting into UI widget stuff or style ideas yet) and vote successively on a) which one approximates the ultimate ideal b) which layout is most like today's and c) which layout is a good transition from today to the ideal.

7. Based upon these drawings and groupings, the team is ready to proceed to the next phase: visual mockups and explorations, including UI controls and styles...

To summarize, the benefits of the box exercise include:
- Cross-disciplinary collaboration in a) understanding the functions and b) generating improved alternatives
- Connecting a common usability activity with designing, "making something" that moves the overall UI design forward
- Involves non-design members to contribute ideas
- Leverages a simple drawing scheme: boxes! anybody can draw a box.
- Encourages critical thinking about the content and functionality, before entering the UI widget/style stage

What is a pixel anyway?

An abbreviation of "picture element" but so much more! Basically it's a mathematical abstraction, not simply a "dot on the screen", as one may mistakenly presume. Nor does it have a physically determinate size, since it's size is dependent upon many factors, including screen resolution of the display device. This can become very metaphysical very quickly, but essentially as an abstraction that is processed electrically via "computer parts" (extreme layman's terms) and represented on the display via RGB color values, pixels are in effect not "real" but simulations/representations of mathematically defined logical structures/units. Sounds like the matrix, doesn't it???

More to it than this...trying to find papers/books that refer to this deeper view of pixels and will update shortly.

Only real artists ship

Another one of those colorful epigrammatic statements from Steve Jobs, meant to inspire and motivate a development team to fully complete an ambitious project, especially once the "train has left the station": designs are largely decided, prototypes rapidly being built and approved, and back-end programming has begun, signalling that "This is for real, folks!", no longer some design concept or skunkwork exercise. The implication: decisions gotta be called and owned up to, tradeoffs made, and just drive towards making this real for the customers.

A little googling about this reveals the broader context for this particular slogan-- shipping the first release of the Macintosh computer, which at the time was way over-schedule, etc. etc.

Below is a quotation from Steven Levy's chronicle of the first Mac, titled Insanely Great, explaining the slogan:

Jobs’s speeches were punctuated by slogans. Perhaps the most telling epigram of all was a three-word koan that Jobs scrawled on an easel in January 1983, when the project [the release of the first Mac] was months overdue. REAL ARTISTS SHIP. It was an awesome encapsulation of the ground rules in the age of technological expression. The term “starving artist” was now an oxymoron. One’s creation, quite simply, did not exist as art if it was not out there, available for consumption, doing well. Was [Douglas] Engelbart an artist? A prima donna—he didn’t ship. What were the wizards of PARC? Haughty aristocrats—they didn’t ship. The final step of an artist—the single validating act—was geting his or her work into boxes, at which point the marketing guys take over. Once you get the computers into people’s homes, you have penetrated their minds. At that point all the clever design decisions you made, all the tists and turns of the interface, the subtle dance of mode and modeless, the menu bars and trash cans and mouse buttons and everything else inside and outside your creation, becomes part of people’s lives, transforms their working habits, permeates their approach to their labor, and ultimately, their lives.

But to do that, to make a difference in the world and a dent in the universe, you had to ship. You had to ship. You had to ship.

Real artists ship.

Invisible gridlines

Grids are of course a common and valuable device for visual designers; much has been written about "the grid" from the standpoint of design criticism, theory, and history. However, it's also important to develop a sensitivity to see the "invisible gridlines" lying behind the composition of UI controls in a dialog box, for instance...and minimize the number of intersecting lines. That's actually how one can achieve a cleaner layout and design, with greater alignment of objects at the most tedious level of detail: x-heights, widths, outside borders, etc. It's focus on that level of detail that can help distinguish one's design as truly perfected, rather than merely sufficient.

Exaggerate the differences

Other times, while crafting the visual design of a UI object, you need to exaggerate the difference, to make the object more prominent as opposed to an "accident" or "mistake" that's only slightly emphasized. For example, if a widget is supposed to appear layered on top of another object, then dramatize the pixel movement and drop shadow for depth effect. And then scale it back gradually as you consider the entire composition. Go out far for drama, then bring it back in for balance.

It's the cumulative effect

When creating the visual design of a UI object, such as a calendar widget within a form layout, it's important to consider the cumulative effect of multiple subtle visual cues, as opposed to several dramatic changes in color, line weight, fonts, lighting, etc, all at once. This can help prevent imbalanced visuals that awkwardly draw too much attention or visuals that are simply overpowering, thus undermining the composition overall. So, in this era of glossy, glowy visuals with drop shadow promiscuity, it's important to remember how subtle changes can stimulate visual perception, in an eye-pleasing manner that maintains overall balance and cleanliness.

On labeling/naming of items in the UI

Coming up with an accurate, memorable name for an object within the interface of an enterprise app (or any product for domain-specific audiences as well) can be a very challenging task--but it doesn't have to be! Simply focus on getting to the essence of what "it" truly is. Keep asking, "what is it" over and over again til you nail it, avoiding any and all marketing terms and gimmicky phrasing that try to make "it" sound cool or marketable. Focus on what it is for the user, in terms of their mental model and common jargon (for that industry or domain). Avoid the gimmicky.

Often the usability problems encountered with software products are due to faulty labeling. Nailing this can in itself resolve much of the interaction design issues!

Timeless, not faddish

This is totally from the the Paul Rand school of thought, as well as many other leading (and legendary) designers like Eames: Designers should leverage timeless principles (of form, content, quality) and embody a beauty (in all its multidimensional senses) in their work, outlasting momentary styles and fads. It's admittedly an idealistic view that speaks to issues of craft and cultural value.

On the opposite end perhaps are those who seek to serve and influence the fashions of the day, whatever may be considered "cool" for the hip and savvy set. A former creative director of Nike and Quokka (now VP of Product Experience at Adobe) recently proclaimed that "we're all fashion designers now". Not too sure if I agree with that :-)

Couple quick examples of successful fashion-based adaptation:

* Madonna has done an extraordinary job morphing herself every couple years in terms of her style and music.
* Relatedly, MTV is a major commercial brand that must adapt to changing styles and fads to stay relevant to its savvy audiences, especially at a global scale!

It's not enough to have an idea

You gotta mentally work through that idea towards implementation, carefully assessing the consequences for other members of the team (dev, design, QA, doc, PM, etc.) and overall impact on the product design direction. Consider the following questions:

What's the impact on aesthetics? Does it deviate from pre-set styles (like CSS)? Does it introduce new (undesirable) modalities or unfamiliar behaviors inconsistent with the rest of the product? Does it interrupt the natural workflow? Is it something "cool" for the sake of hipness without real benefit to solving a user's problem? Is it introducing scope creep given the current cycle/release? (ie, being a consultant it's important to be mindful/respectful of the client's situation, helps build cred and relationship)

Make the deliverable count

Just to iterate again about the need to be smart and efficient about what deliverables to spend effort/time on...

1. Make sure it helps the team make decisions about the UI.
2. Make sure it moves everyone closer towards the prototype.

Enabling UI decision-making

No, I'm not the "decider" (especially as a consultant, where I primarily "recommend" :-) But in the course of product development whereby the design of the UI colors the overall user experience (initially expressed as the prototype), decisions about "which widget goes where" are critical. Such decisions must be regarded seriously in terms of consequences upon the page layout, user interactions, system responses, technical abilities, etc. A few things to keep in mind about these vital decisions:

1. Make sure all the relevant parties (engineering, marketing, QA, doc) who can/will be affected by the UI decision are in the room together to hash it out in real-time.

2. Once a decision has been made (achieved via consensus or collaborative weighing of pros/cons), record it, commit to it and give it a deadline. A common problem is lack of follow-up or accountability for a design decision, or simply lost in a flurry of other decisions.

3. Designers love to make all kinds of artifacts/deliverables, but due to constrained time/resources/dependencies, the designer should ask herself "Does this artifact move us towards better design decisions?" or is it something simply to "help the client feel good" or for internal bureaucracy/political goals? (ie, furthering the machine of bureaucracy for the sake of Process)

Designers should create (and send onward) only those artifacts that are meaningful towards helping the client make a decision about the UI. For example, a designer may rapidly sketch out with his pen several possible solutions or a quick concept map of system objects to help him think through the problem, as a natural part of his process. But should he take the time to scan in those sketches and send them to the client? Should he spend the effort to rebuild them in Visio or Illustrator as a formal document? Only if the result will help the team make decisions about the problem and solution...and of course move everyone closer to the prototype!

It's all about the prototype

Perhaps the first, and most pertinent driving principle of interaction design is that the prototype serves as the record of truth for the development team, as a vital stepping stone towards accurate implementation of the intended behaviors. The prototype also provides more visceral, accurate, assessable information for evaluating the design's utility and enabling non-designers to buy-in, stakeholders to sign-off, and customers/users (preferably alpha users) to effectively judge. And the prototype, in demonstrating both visual as well as behavioral qualities, can provide a more "well-rounded" sense of what solution is supposed to be, helping implementation experts estimate for resources, timing, and methods needed to make the actual shippable product.

So, if the prototype is that critical for the design process, then you're correct to assume that every step of the design process and every deliverable created along that path should be directed towards getting to the prototype quickly and efficiently. In other words, don't waste time making a perfect flow diagram or set of wireframes ...satisficing (from herb simon, the idea of sufficient yet valuable) is paramount to sustaining forward momentum.

Why am I using blogger?

OK, one quick point to clear up--Why blogger? Well, frankly it's fast, free, and easy! And of course those great templates by CSS gurus like Cederholm and Zeldman. Seriously. Seriously. Seriously. (that's for fellow Grey's Anatomy fans :-)

But at some point I do plan to use wordpress like a true design pro, with a completely redone (standards-compliant) website as well, sorta like what this guy has done. One day...

A little more about me...

Before getting to the notes themselves, a little bit more about me...

I'm a software UI designer in Silicon Valley, having worked at a variety of large companies (Oracle, BEA, Adobe) after earning degrees in industrial design (Michigan) and interaction design (Carnegie Mellon). I have also published & spoken at conferences, including IDSA, DMI, and the annual IA Summit to cultivate a substantive body of design knowledge.

But after a brief stint with frog, I recently left the corporate world (for now?) to join a small but growing design studio, focused on digital design problems. While I have a great portfolio of experiences and methods from prior places, this new gig is a wonderful chance to learn hands-on about consulting and the fundamentals of "good design" from some deep, skilled, and influential folks.

There truly is a whole other world outside the corporate cubicle and I intend to soak it all up!

What's this all about?

This blog is a means for me to quickly/frequently record the various lessons (in a admittedly pseudo stream-of-conscious manner) I've been learning recently at my new job at an small design studio/start-up in Silicon Valley. This includes lessons about visual design, standards-compliant markup, UI design issues, client engagement, and application design in general.

In addition, I want to share this with others who may benefit from the extraordinary opportunity and experience I'm lucky to have this year, working directly with one of the legends of software design in the valley who helped found the original Adobe UI Design team.

Hope you enjoy it!