as a decoy so that you don’t try to find
where they actually hang out. I’m sorry
you had to learn that here.)
4. Design isn’t how something
looks; it is how it works.
Steve Jobs famously said, “Design is
not just what it looks like and feels like.
Design is how it works.” UX designers
don’t sit around trying to decide what
color the menus will be, or if buttons
will be round or square. They determine what the workflow and interactions will be.
Will the user be presented with one
screen with three choices, or will the
choices be presented one screen at a
time? The decision requires psychology, empathy for the user, and testing,
One of the biggest challenges of UX
design is that once you know the system well, you lose the ability to predict
what a new user will expect. The person
who designed the system is automatically disqualified for predicting what a
new user will need.
I remember the first time I had the
opportunity to watch users through a
one-way mirror as they used a product
I was involved with. “It’s the button on
the left! Look to the left! Oh god, why
aren’t they clicking the button on the
left!” Then reality sets in. Our brilliant
placement of buttons was brilliant only
because we knew the system so well.
Therefore, testing with real users is
required. This could be as simple as
recruiting a coworker who has yet to
see the system, or as complex as using
a double-blind study with one-way mirrors and eye-tracking systems.
I also remember watching someone
test Google Maps. The user was asked
to route from New York Penn Station
to a particular hotel. After that task
was completed, the UX designer asked,
“What do you think you would want
code, or in the underlying software
frameworks and systems that it is
built upon. Your software may be per-
fect, but I assure you that over time
people will find security holes in the
platform it is built on.
It is your job to expect an organization that recognizes this.
The way we recognize this is to build
an organization that confidently produces new software releases at regular
intervals. When fully automated testing and other engineering disciplines
are in place, we build confidence.
This confidence creates the ability to
eschew multiyear release cycles and
instead ship high-quality software
quarterly, monthly, or even weekly. The
particular frequency isn’t important;
confidence is. Confidence leads to faster innovation.
This also means rejecting project
plans that involve one perfect release,
then no more. Or plans that do not involve sufficient testing, or eliminate
the beta-test period, or allow developers to make changes to live production
systems instead of having an approved
and tested path to release. Features
that make software more shippable
should not be left until the end; ease of
shipping has business value.
Lastly, let’s stop with software projects that are allowed to run for multiple years before showing any progress. Release early and often. Require
a minimum viable product to launch,
followed by periodic releases that add
features. The first release might be just
the basic framework or support only a
few edge cases. Each release provides
an opportunity to get feedback and
change course. Early releases might
run only in a beta area, inaccessible
to real users. At least you have started
the feedback cycle. Beta testing saves
Of equal importance, behind-the-scenes operations now have a chance
to begin developing their processes
and procedures, build and vet infrastructure, and test the invisible foundation that supports everything else.
Imagine if the Obamacare website
had first supported only Rhode Island, then added support for states
one at a time. The experience from
each iteration would have propelled
it forward and made it a success from
3. Software is a team effort;
nobody can do it all.
The software developer is neither product manager nor UX (user experience)
designer nor quality assurance analyst
nor security guru nor technical writer
nor operations engineer. You need
No executive would propose that
each salesperson do his or her own
marketing, or that the sales force
should be fired because marketing
understands the product and can do
sales, too. Marketing and sales are related but different. Therefore, a division of labor exists between the two.
Likewise, software teams need separate people for requirements gathering, quality assurance and test engineering, technical writing, and so on.
There is a myth of the developer
who “does it all,” known as the “full
stack developer” or “10x engineer.”
This doesn’t exist outside of the small-est company. Yes, a very small company may have a single person who
does both marketing and sales, but
you probably don’t work for a company
that tiny. Neither do your engineers.
Yes, your 12-year-old son made a
website all by himself. Don’t let that
make you think that it cannot be that
difficult, or that coding is “just typing.”
I assure you Johnny’s website isn’t
processing billions of financial transactions per hour. When I was 10 years
old I built a “robot” out of cardboard
boxes. My parents were smart enough
to take that as an indication that I was
interested in engineering, not to think
I could skip calculus.
Which reminds me: Dear Parents,
Just because your child is “good at
Facebook” doesn’t mean he or she will
be the next Zuckerberg. Stop saying
that at cocktail parties. It’s embarrassing. (P.S. No teens use Facebook any
more. Your kids post to Facebook only