The Reluctant Server Admin

Article 1 of 14 on Amazon’s 14 Leadership Principles

This is one part in a series relat­ing my pro­fes­sion­al his­to­ry to Amazon’s 14 lead­er­ship prin­ci­ples. It was orig­i­nal­ly con­ceived to prac­tice my sto­ry­telling in prepa­ra­tion for Ama­zon inter­views. I didn’t get the job(s). Which is fine, total­ly fine.

Amazon Leadership Principle #1

Customer Obsession

Lead­ers start with the cus­tomer and work back­wards. They work vig­or­ous­ly to earn and keep cus­tomer trust. Although lead­ers pay atten­tion to com­peti­tors, they obsess over cus­tomers.

The Reluctant Server Admin


First, let’s look at Amazon’s word choice; “Cus­tomer” and “Obses­sion”. Cus­tomer, in the con­text of soft­ware design, reach­es beyond just the end user. Cus­tomers are also your stake­hold­ers and depen­dent teams, any­one who might con­sume your work. Obses­sion is a pow­er­ful term. Beyond the dic­tio­nary def­i­n­i­tion, obses­sion is deeply per­son­al. It push­es near­ly all oth­er top­ics from your focus, it pro­vides no choice, it is your train of thought.

Microsoft, Redmond, USA. A time long gone when software shipped in boxes, written onto compact discs, 2005ish.

I had recent­ly joined the design-poor Serv­er Divi­sion as a fresh UW design school grad­u­ate. My job: design the UI for the next great Small Busi­ness Serv­er release. It’s goal: to enable non-tech­ni­cal small busi­ness own­ers with a dead sim­ple, self-ser­vice yet fea­ture rich serv­er admin­is­tra­tion inter­face.  Before the cloud, busi­ness own­ers would buy and oper­ate their own hard­ware. Crazy I know. My design would have to be so easy to grok that any mom-and-pop-shop could rig their serv­er for the bet­ter­ment of the bot­tom­line. All I had to do was design it. It was time to get obsessed.

Before UX design, I swam in the warm and dark waters of fine art. From a very young age it taught me patience and gave me grounds to prac­tice sin­gle-mind­ed­ness. Fine art feeds on emo­tion, so I learned to pour myself into that water, then once I had a grip on my vision, there was no let­ting go until I had pulled that work out of the dark water for all to see. I didn’t label it Obses­sion then, but it fits.

The tar­gets of my focus were both the more senior Microsoft­ies, which was pret­ty much every­one around me, and the end-user small busi­ness own­er. As a young design­er, I could lever­age my recent­ly acquired design ideals to my advan­tage. One of the great things about design is that you are equipped to craft all of your out­put to meet the needs of your Cus­tomer. Every email, design option, and pre­sen­ta­tion was designed to the Nth degree. It was, of course, my goal to con­sis­tent­ly exceed expec­ta­tions, and I took every oppor­tu­ni­ty to design myself into that mold. This is both self-serv­ing and altru­is­tic; I would look good in the eyes of my supe­ri­ors and the prod­uct would be user-cen­tered.

My knowl­edge of inter­nal cus­tomers expec­ta­tions improved with each dai­ly inter­ac­tion. Each pass­ing week taught me how to wow them more and more. Hav­ing earned the team’s trust, I set out to learn as much about my small busi­ness own­ers as pos­si­ble. My big gam­ble was that this knowl­edge would give my beau­ti­ful, still imag­i­nary user inter­face the best chance to suc­ceed in the design-acidic Serv­er Divi­sion.

His­tor­i­cal­ly advanced-slash-bor­ing admin tasks such as man­ag­ing Active Direc­to­ry users and groups, con­fig­ur­ing net­work stor­age, set­ting up secu­ri­ty, and deploy­ing file shar­ing need­ed to become intu­itive and obvi­ous. These users knew their craft, what­ev­er it was, but were not com­fort­able “using com­put­ers”. I want­ed to deliv­er these blue-col­lar Amer­i­cans the sim­plest pos­si­ble serv­er admin expe­ri­ence despite work­ing in a Serv­er Divi­sion where this design was as for­eign as a data­base key con­straint.

I made some like-mind­ed friends in UX research. In my expe­ri­ence, Microsoft excels at UX research. My pals armed with per­sonas, which I marched around like the Army of Design Ratio­nale. Per­sonas gave me some­thing to work for and work from, to relate the need for sim­plic­i­ty and clar­i­ty to the prod­uct team. In each design review, I faced crusty, tech-first oppo­si­tion but I brought weaponized usabil­i­ty data designed to dri­ve the data home. The Serv­er moss­backs didn’t argue much with data. I knew my users well now. It was pay­ing off to have done those in-per­son inter­views, those one-way mir­ror usabil­i­ty stud­ies, and all that on-site research in places like Lit­tle Rock, Arkansas, where com­put­ers were still beige.

Days and nights were con­sumed with this deli­cious­ly com­plex chal­lenge. Cliché as it may be, I remem­ber a leap of inspi­ra­tion about the nav­i­ga­tion motif that occurred to me dur­ing a morn­ing show­er. My focus shift­ed from learn­ing who my user was, to deliv­er­ing my work for them. Progress bat­tled for­ward. These bat­tles rein­forced my user-first posi­tion and earned the respect of my team and stake­hold­ers. My UI solid­i­fied into a mar­ket-ready prod­uct and won some ground for design in Serv­er.

I learned to nev­er back down in my advo­ca­tion for the user, even when going toe-to-toe with a VP or a big-brained senior dev. It was the con­cep­tu­al­ly sim­pli­fied, user-first prod­uct that shipped. I’m hap­py with the suc­cess of Small Busi­ness Serv­er, such that it was, and know it was due in part to my prac­ticed abil­i­ty to com­mit whol­ly to my work.

This is an old sto­ry rel­a­tive to my cur­rent expe­ri­ence but it set a foun­da­tion that I have depend­ed on since. User first, user always. I hadn’t before used the term “obses­sion” but if not for my focus on learn­ing every­thing I could about my cus­tomers, I know my work would not have been as fruit­ful.

Amazon’s 14 Leadership Principles

  1. Cus­tomer Obses­sion
  2. Own­er­ship
  3. Invent & Sim­pli­fy
  4. Are Right, a Lot
  5. Learn & Be Curi­ous
  6. Hire & Devel­op the Best
  7. Insist on the High­est Stan­dards
  8. Think Big
  9. Bias for Action
  10. Fru­gal­i­ty
  11. Earn Trust
  12. Dive Deep
  13. Have Back­bone; Dis­agree and Com­mit
  14. Deliv­er Results

How I Would Bring UX to a New Project

This arti­cle is a thought exper­i­ment. Imag­ine we have a chance to join an enter­prise com­pa­ny as it spins up a new team, to tack­le a new project with visions of tak­ing today’s prod­uct into tomor­row.

Offered here is a descrip­tion of how I would approach join­ing a hypo­thet­i­cal, new prod­uct endeav­or as the team’s UX design­er. Assert that the project is brand new, the team is expe­ri­enced yet fresh­ly amassed, and the stake­hold­ers have a clear vision of this product’s busi­ness val­ue. The read­er is invit­ed to put your­self in UX design shoes and imag­ine how you might align or diverge from my high-lev­el approach. Our chal­lenge is to estab­lish all design prac­tices, earn trust, pro­duce top-notch UX, and deliv­er this beast to mar­ket.

Let’s break this prob­lem into three cat­e­gories; What, How, and Why.

What Would You Say You Do Here?

User Expe­ri­ence design­er? Wow, sounds awe­some! What do you do all day?  // My Aunt at Thanks­giv­ing

Prod­uct com­pa­nies, large and small, will have some estab­lished design cul­ture, healthy, ill, or a mix of both like an ath­lete with a hang­over. Let’s say the new team’s lead­er­ship is wor­ried. They don’t want any unhealthy UX prac­tices leak­ing in from the mossy cor­ners of the Seat­tle head­quar­ters. Con­grats! We get to pro­vide clean design process as the badass UX design­er on the badass team. It’s a big chance to prove we’re next-lev­el, to our­selves and the indus­try.

Let’s set some more basics: This is a soft­ware prod­uct. It will be devel­oped by a team of engi­neers on- and off-site with the design­er. Col­lab­o­ra­tion between dev and design is expect­ed. The team has been chal­lenged to invent a new prod­uct, there is no pre­cise def­i­n­i­tion of What we’ll build. Final­ly, as any sol­id enter­prise oper­a­tion will, we are giv­en equal­ly sol­id mar­ket data for us to inter­pret into action.

We’re glad to have this mar­ket data, but how do we start defin­ing the UX after read­ing and re-read­ing it? We need to pro­duce clear answers to sev­er­al impor­tant ques­tions because What we build depends on:

Who are the users?

What are their moti­va­tions, incli­na­tions, and cur­rent tools?

We will con­struct Per­sonas and Jour­ney Maps in a team work­shop to cod­i­fy answers. The team learns to sup­port these items through par­tic­i­pa­tion in our work­shop. Now we have cre­at­ed, col­lab­o­ra­tive, excel­lent aides to progress the prod­uct design.

What are the prioritized business goals of the product?

How will it prof­it the com­pa­ny? What are the sales and use expec­ta­tions? What met­rics can be mea­sured now and in the future to prove the new prod­uct is pro­vid­ing busi­ness val­ue?

Col­lab­o­ra­tion between design and dev is already expect­ed, but, as mas­ters of empa­thy, we will push coop­er­a­tion beyond expec­ta­tions, part­ner­ing with “the busi­ness” to ensure they are a real part of the prod­uct team. Wel­come aboard Sailor! Our busi­ness-types take awhile to get their Scrum sea legs but with coach­ing and patience, we get our list of to-dos in order.

What is the state of the data that will drive this new application?

Are the back­ing APIs owned by the prod­uct team or pro­vid­ed by a sep­a­rate group? How can the team ensure user-cen­tered design think­ing informs the design of these APIs?

APIs are the fuel injec­tion for every app. Let’s say in our hypo­thet­i­cal, we have an 80/20 split of new-to-old APIs. Effi­cient inter­faces will give us a crit­i­cal per­for­mance pil­lar for the user’s expe­ri­ence. Though it may not be pix­el-based design, API design is with­in our domain as it relates to the user. Bring on the JSON. Let’s sit in on that dev meet­ing about the APIs, then we’ll present how our infor­ma­tion archi­tec­ture ben­e­fits the user and helps the API devs learn more about the upcom­ing needs of the inter­face design.

Cool col­lab­o­ra­tion with oth­er roles will answer What the team will design and build. Cus­tomers take many forms, from end-user to VP stake­hold­er, and all the depen­dent teams up and down­stream of our prod­uct. Fol­low­ing through on the ear­ly design process steps of Dis­cov­ery and Analy­sis enables every­one on the team to smooth­ly answer to “What are you build­ing?” with con­sis­tent clar­i­ty.

Good job us. Now we can get start­ed…

How Do We Make UI?

Short answer: fol­low the prod­uct design process.

We are rely­ing on a process estab­lished through prac­ti­cal appli­ca­tion in the busi­ness envi­ron­ment. A more in-depth look at the UX design process can be viewed on my web­site. At a high-lev­el, we pre­scribe this approach for our­selves and the dev team:

  1. Strate­gize
  2. Dis­cov­er
  3. Analyse
  4. Design the UX
  5. Design the UI
  6. Mea­sure
  7. Go to Mar­ket

This process is non-lin­ear. Cer­tain steps feed back into ear­li­er steps, bet­ter inform­ing the design out­put of the team. Strate­gize, Dis­cov­er, Ana­lyze, and lat­er, Mea­sure, are fair­ly self-explana­to­ry and are shared by many oth­er roles in soft­ware. These steps ini­ti­ate a project with its frame­work, research, and action­able data, based on all cur­rent prod­uct knowl­edge.

Let’s unpack the UX and UI design steps, these pro­duce our bread-and-but­ter arti­facts that define the product’s user expe­ri­ence and give our work lives mean­ing! Time to aim high friends, let’s show’em how we do.

We think UX design is pret­ty spe­cial. It super­sedes near­ly all oth­er design dis­ci­plines in the prod­uct con­text. It informs high detail design work by pro­vid­ing a back­bone of doc­u­ments, each matur­ing through its own iter­a­tion and pre­sen­ta­tion:

  • per­sonas
  • jour­ney maps
  • infor­ma­tion archi­tec­ture
  • work­flow design
  • sketch­es
  • wire­frames
  • pro­to­types

Each extends the pre­ced­ing and gives a con­tin­u­ous and con­crete ref­er­ence for our pals in dev. Your big-time stake­hold­ers will real­ly start lik­ing you now as the product’s direc­tion gains clar­i­ty. UXer’s are a pret­ty gre­gar­i­ous bunch, and even if we’re lean­ing intro­vert­ed today, we will be sure to show and tell, shout and yell, all our visu­al progress. Design is a visu­al sport so we will wear a path into the car­pet between our desk and the best print­er in the house.

Let’s zoom in from UX to design­ing the user inter­face. UI design is where the prod­uct meets the pix­el. It pro­vides the appear­ance and per­son­al­i­ty to the pre­ced­ing intan­gi­ble UX work. The user inter­face is defined in two major ways; Visu­al design and Inter­ac­tion design.

Visu­al design defines how our prod­uct will look and Inter­ac­tion design defines how it will feel and behave. These dis­ci­plines pro­duce high-fideli­ty, pix­el-per­fect ren­der­ings for test­ing and for the dev team’s ref­er­ence. Our visu­al work will take exter­nal depen­den­cies into account, com­pa­ny and prod­uct brand are major influ­ences on our visu­al lan­guage.

Inter­ac­tion design is eas­i­er than it used to be. Now, it ben­e­fits from exist­ing, estab­lished behav­ioral pat­terns which have emerged as either soft­ware man­u­fac­tur­ing best prac­tices, as user expec­ta­tions, or both. Even with all this ground­work, we will not skimp on IxD. Con­trols will be mod­eled, behav­iors and states will be spec’d. Our brains are in inter­ac­tion design mode, so it seems obvi­ous that we deliv­er the goods through an inter­ac­tive spec sheet host­ed so any­one on our team can hov­er, spin, and ani­mate to their heart’s con­tent.

Visu­al design and Inter­ac­tion design also depend on the feed­back loop to cull the weak from the visu­al herd. We have an eye for detail, and our craft skill is as sharp as our X-acto knife. Focus­ing on these crit­i­cal attrib­ut­es of design pre­sen­ta­tion is what will ele­vate our work from good to great.

Agile method­ol­o­gy is also a major con­sid­er­a­tion as it relates to deliv­er­ing these pieces, a top­ic wor­thy of its own arti­cle. For the sake of brevi­ty, we will rely on the three levers used to con­vert any idea into real­i­ty; resources, time, and require­ments. Con­ced­ing depth in any one relies on the strength of the oth­er two. Design deliv­er­ables are no dif­fer­ent, a large team can pro­duce rich work quick­ly where­as a sole design­er may need to rely on less depth to deliv­ery in a time­ly fash­ion, or con­cise com­mit­ment to a short list of detailed work, to fit with­in a Sprint. It’s all about deliv­ery, so as the sole design­er, we recite that per­fec­tion paral­y­sis is the antithe­sis of progress.

Why Us?

Why would our par­tic­u­lar pres­ence be valu­able to a new project team like this? This design role, on this team, requires two molds; Design­er and Leader. The Design­er must deliv­er all of the arti­facts list­ed above on time and at high qual­i­ty. The Leader must install design think­ing and process, estab­lish and nur­ture rela­tion­ships with depen­dents and stake­hold­ers, and most impor­tant­ly, con­stant­ly advo­cate for the user. What more could we ask for in a gig right? We must stay loose. Inspi­ra­tion strikes at odd times. We are sure to allow space to drift and day­dream, so that light­ning has room to strike.

Nice­ly done design­er, now go draw some­thing.

Design Q&A


I recent­ly applied to Qualtrics for a Senior UX design­er role. Their appli­ca­tion process took me through a ques­tion­naire, some­thing few oth­er com­pa­nies require. Kudos to Qualtrics design group for vet­ting can­di­dates so deeply. Here are is my Q&A  //

What is the most com­plex web appli­ca­tion you have worked on? Why was it com­plex? What was your con­tri­bu­tion?

I have many exam­ples of con­cep­tu­al­ly com­plex prod­ucts in my his­to­ry. In terms of user expe­ri­ence, we can define com­plex­i­ty as the oppo­site of sim­plic­i­ty and view it from two per­spec­tives; inter­face design and men­tal mod­el. I designed a prod­uct called Opti­mize while with a start-up (lat­er pur­chased). My con­tri­bu­tion includ­ed all the UX design, research, tech­ni­cal writ­ing, test­ing, and some of the imple­men­ta­tion as well. This prod­uct was designed for non-tech­ni­cal users to cre­ate, man­age, and report on A/B and Mul­ti­vari­ate web con­tent tests. The com­plex­i­ty here was pri­mar­i­ly due to the men­tal mod­el that the user had to hold in mind in order to con­struct these test objects as defined by the math­e­mat­i­cal­ly rig­or­ous back­end. I spent a lot of effort design­ing an infor­ma­tion archi­tec­ture that mapped to the user’s exist­ing, Mar­keter object def­i­n­i­tions to the appro­pri­ate back­end items. This elim­i­nat­ed the user’s men­tal mod­el com­plex­i­ty with­out com­pro­mis­ing nec­es­sary, func­tion­al back­end com­plex­i­ty and allowed me to design a sim­ple inter­face to match.


What is the most com­plex data visu­al­iza­tion project you have worked on? Why was it com­plex? What was your con­tri­bu­tion?

Data sci­ence, such as pre­dic­tive ana­lyt­ics, is becom­ing increas­ing­ly acces­si­ble to prod­uct teams. Two exam­ples from my past, both of which I was the sole UX and UI design­er; mul­ti­vari­ate test result report­ing in Opti­mize, and a data cen­ter dash­board web app for Microsoft. Both uti­lized pre­dic­tive analy­sis to project future per­for­mance based on his­tor­i­cal data. This type of data intro­duces uncer­tain­ty as a con­fi­dence inter­val. Addi­tion­al­ly, I designed an inter­face for the user to con­trol over­all sta­tis­ti­cal con­fi­dence, increas­ing or decreas­ing the inter­val mar­gin as a result. This allowed the user to fine-tune the pre­dic­tive reports in both apps to test their busi­ness hypothe­ses. The com­plex­i­ty here is due to the sta­tis­ti­cal under­stand­ing need­ed to accu­rate­ly design a sim­ple inter­face for users who may not have loved their sta­tis­tics math class as much as I did.


Can you give me an exam­ple of a recent prod­uct that you came across that you thought was par­tic­u­lar­ly well designed? 

This is a very hard ques­tion for me, I can find well designed aspects in many prod­ucts. My acoustic gui­tar, for exam­ple, is a hand-craft­ed wood­en instru­ment, expert­ly designed for great sound and per­for­mance feel. It is well designed because it makes users’ needs fore­most; as a play­er, I can feel the per­fect­ly craft­ed neck as I move around, and as a lis­ten­er, the guitar’s body projects the sound out­ward, allow­ing clear and rich music. The maker’s expe­ri­ence is what sep­a­rates this gui­tar from one I may build, just as a senior UX design­er can bring more to the prod­uct team.I often imag­ine soft­ware as a three dimen­sion­al thing. This casts each but­ton and field in a new per­spec­tive, mak­ing it eas­i­er to imag­ine each detail as a hand­craft-able piece of the user’s expe­ri­ence.


What does your design process typ­i­cal­ly look like?

First is research; I want to know as much about the prob­lem, the user, the busi­ness bound­aries, the stake­hold­ers, require­ments, exist­ing design sys­tems, etc. as pos­si­ble. This allows me to exe­cute designs with lim­it­ed waste. If nec­es­sary and time per­mit­ting, I have seen great val­ue in per­sonas and asso­ci­at­ed jour­ney maps. Next is ideation; white­board­ing, ide­al­ly with the prod­uct team or stake­hold­ers. Wire­fram­ing allows dig­i­tal or paper pro­to­types to test the cen­tral inter­ac­tions and work­flows at low cost. Fideli­ty increas­es as out­stand­ing ques­tions are answered, even­tu­al­ly amount­ing to full-fideli­ty comps ready for imple­men­ta­tion by myself or my dev team. Red­lines are specs are often nec­es­sary.


How do you decide if a design is good enough?

Good enough” is a slip­pery slope, I pre­fer to always shoot for excel­lent or game-chang­ing. “Good enough” means the design meets all the busi­ness require­ments, it fits in with the sib­ling designs, it is func­tion­al and doesn’t influ­ence the user’s opin­ion much if at all. It is easy to begin the design process already at the “good enough” state by lever­ag­ing the wealth of inter­ac­tions and mod­els already estab­lished by a decade of smart­phone apps and many decades of soft­ware design. This pro­vides a great advan­tage to a team com­mit­ted to work­ing from Good to Excep­tion­al. Design sys­tems pro­vide a more cus­tomized, brand­ed sta­tus-quo to be estab­lished with­in a com­pa­ny, this sets how good “good enough” looks and is impor­tant for rapid prod­uct devel­op­ment and increas­es the num­ber of excep­tion­al solu­tions com­ing out of the prod­uct design/dev team.

For the last few years, how has your time been divid­ed between the fol­low­ing things: Inter­ac­tion design, Graph­ic design, Infor­ma­tion archi­tec­ture, Design evan­ge­liza­tion, Managing/mentoring oth­er design­ers, Usabil­i­ty test­ing, Pro­to­typ­ing user inter­faces, Cod­ing User Inter­faces.

45% inter­ac­tion design
10% graph­ic design
10% infor­ma­tion archi­tec­ture
5% design evan­ge­lism
10% man­ag­ing design­ers
5% usabil­i­ty test­ing
5% pro­to­typ­ing
10% cod­ing UI


Now that mate­r­i­al design is near­ing its peak, what do you think will come next?

A rich­er, yet still abstract, design lan­guage. More use of pat­terns and motion to sep­a­rate fore­ground and back­ground, more detailed inter­changes between user focus­es. Flat­ness is best when in con­trast to rich detail, so I believe we will see an increase in the lat­ter to pro­vide this con­trast. One major strength of material/flat design is that it is fast and cheap for a phone or brows­er to ren­der. As pro­cess­ing pow­er con­tin­ues to increase, there will be more tech­ni­cal space to fill with more dynam­ic, rich­er designs.


How would you describe your style?

Out­side of the office, I am very laid-back, my style is cen­tered on patience and focused on the moment. In the office, I can be quite assertive, cer­tain­ly when it comes to defend­ing what I can prove is the best design path. I am always cere­bral and rarely emo­tion­al. A healthy office deserves the best from us, and I always show up ready to play ball.Visually, I think my style can be adapt­ed, though most of design work has been in busi­ness-to-busi­ness tools, which calls for lim­it­ing expres­sive­ness. I would love to work on a prod­uct that chal­lenged me into a new style. There is so much great con­tent out there to learn from, I would real­ly enjoy push­ing myself in this way.


If you had to present designs to a devel­op­ment team, how would you struc­ture your pre­sen­ta­tion? How would you struc­ture things if you had to present to an exec­u­tive team instead?

The dev team needs doors, the exec­u­tives need deci­sions. I design dev team pre­sen­ta­tions to force dis­cus­sions and deci­sions on require­ments. This means inten­tion­al­ly exag­ger­at­ing expen­sive or incom­plete require­ments in a cer­tain fea­ture to enable the group to talk through this weak­ness. The dev team is also excel­lent at eval­u­at­ing new ideas and I often reserve some time in these pre­sen­ta­tions to review uncon­ven­tion­al solu­tions. The struc­ture is inter­ac­tive, using prints or pro­to­types as fit­ting to the design process.Executives want to see the deci­sions and under­stand the process that when into them. They need to see the research and the pile of reject­ed ideas so they can be con­fi­dent in the final design deci­sion, even when UX is not their exper­tise. A design­er must invite crit­i­cism to ensure the design is as good as it pos­si­bly can be, and the exec­u­tives are often opin­ion­at­ed. The design­er must also be ready to refute exec­u­tive ideas appro­pri­ate­ly, which is anoth­er ben­e­fit of UX research and test­ing.


What is your ide­al mode of coop­er­a­tion with devel­op­ers?

High­ly col­lab­o­ra­tive. Designs rarely pass from comp to code with­out some com­pro­mis­es. It is a bet­ter design­er that under­stands the tech­ni­cal con­straints of their medi­um, just as an oil painter would not attempt cer­tain tech­niques, the devs are con­strained by the front-end tech­nolo­gies. I have enjoyed writ­ing code since I was in ele­men­tary school, and my time as Appli­ca­tion Dev Mgr at Web­trends allowed me to get neck deep in archi­tec­ture and code while still main­tain­ing focus on the over­all UX. I love mak­ing soft­ware. It is a team sport and I am made a bet­ter role-play­er by know­ing the oth­er roles on my team.


If you had to give a rec­om­men­da­tion to design pro­fes­sion­als for an online resource or a book to read, what would it be?

Hon­est­ly I don’t have a sin­gle go-to. Cross­ing the Chasm by Geof­frey Moore was a short read was a valu­able influ­ence on my per­cep­tion of prod­uct and busi­ness. In terms of design, I fol­low many art and design blogs. I would rec­om­mend some­thing suit­able to the chal­lenge at hand, if it were web design, there are many great arti­cles on Smash­ing, it if were visu­al design, I often pull inspi­ra­tion from fine art. There are some many great sources of con­tent, it’s tough to call out a pri­ma­ry.


Is there a par­tic­u­lar design pro­fes­sion­al that you admire? Why?

Tin­ker Hat­field. The shoes are great, sure, but his inter­nal hon­esty is what I admire. He has found great suc­cess on his own terms, fol­low­ing his own process. He has found a niche for him­self that required zero or min­i­mal com­pro­mis­es and I aspire to this state of being.

The Client’s User Experience

User Expe­ri­ence (UX) design is often con­flat­ed with inter­face design and visu­al or graph­ic design. Where are Prod­uct design and Cus­tomer Expe­ri­ence in this Venn dia­gram of design? To most folks who are not design­ers, these dis­tinc­tions are not need­ed in prac­ti­cal terms; as long as the end prod­uct looks good and does the job well, then the design­er did their job, and the spe­cif­ic design dis­ci­plines employed are irrel­e­vant.

For the most part, this is a harm­less prac­tice. Sub-gen­res can be con­glom­er­at­ed into gen­res with­out injury. How­ev­er, edu­ca­tion is empow­er­ing, and I have seen many groups, from all lev­els of busi­ness ben­e­fit from bet­ter under­stand­ing these design sub-gen­res. UX design cov­ers a lot of ground, it includes all of inter­face and graph­ic design, essen­tial­ly any time there is a user involved, we open the user expe­ri­ence design tool­box.

Inter­face design, by con­trast, focus­es com­plete­ly on the inter­face itself; the imple­men­ta­tion, speed, weight, effi­cien­cy, acces­si­bil­i­ty, local­iza­tion, etc. It is a spe­cial­iza­tion of focus, a nec­es­sary part of excel­lent UX design, but inter­face design does not fill the UX design tool­box all by itself.

Some of the best design reviews I have had with clients and stake­hold­ers evolve into design class­es. The client is bet­ter able to artic­u­late ideas and pro­vide crit­i­cal feed­back when they have some design tools of their own. Design is a game of mak­ing rules, and then break­ing rules. Rules about con­trast, typog­ra­phy, semi­otics, infor­ma­tion archi­tec­ture, etc. are easy to explain in the con­text of a project that every­one in the room under­stands. Each design review brings an oppor­tu­ni­ty to edu­cate the client in these aspects of design. They can take these away from the meet­ing, and maybe, bring them back next time. More under­stand­ing increas­es the per­ceived val­ue of design as a ser­vice and enables a col­lab­o­ra­tive, team envi­ron­ment, rather than a client-vs-ven­dor face off.

It is crit­i­cal that the user expe­ri­ence design­er is equipped to answer the ques­tion Why? Design with­out ratio­nale is hol­low and will like­ly fail to meet busi­ness objec­tives. Ratio­nale allows for test­ing, anoth­er impor­tant tool in UX design. Visu­al hypoth­e­sis test­ing is com­mon prac­tice in mar­ket­ing, a depart­ment famil­iar with A/B test­ing tools like Google Opti­mize. A mar­ket­ing client may not be famil­iar with usabil­i­ty test­ing but can appre­ci­ate the val­ue and process because they are a gold cer­ti­fied A/B test­ing vet­er­an.

Answer­ing why a design took one direc­tion and not anoth­er informs the client, empow­er­ing them with that knowl­edge for the remain­der of the project. Over a few design reviews, the client gains a grow­ing sense of con­trol of their project and an increas­ing appre­ci­a­tion of the val­ue of UX design if the design can edu­cate along the way. Trust hap­pens. Then the client is trans­formed from stake­hold­er to part­ner, and that is a user expe­ri­ence worth build­ing.

The Barstool Reverie

The barstool even looks like an island. It stands alone, togeth­er with its’ sib­lings, in a row then around a bend like an arch­i­pel­ago. The barstool is a sta­tion­ary vehi­cle. Climb on up and find your­self slid­ing away from the morning’s sta­tus meet­ing and escap­ing the oncom­ing pres­sure of the evening busi­ness. You are safe­ly alone among your fel­low trav­el­ers. Atop a barstool, you sit unjudged; per­mit­ted to un-focus your con­cen­tra­tion, allowed to wan­der freely. Bonus: your favorite drink is a short sen­tence away.

What pos­si­ble pro­duc­tiv­i­ty could be reached from such a cliché seat of pro­cras­ti­na­tion?

Let’s be mind­ful of a few things; One, we’ll admit the con­tem­po­rary world of busi­ness and tech­nol­o­gy is as high-strung and intense as ever. Sec­ond, we’ll con­cede that those who work with dili­gence and grit are the like­li­est of us to reach their goals. Third, hap­pi­ness is not an out­come, it is a state of being.

Wait, what? I thought we were on a barstool. What does busi­ness, tech­nol­o­gy, hard work, and hap­pi­ness have to do with our padded beer post?

In a word, med­i­ta­tion. Per­haps the inter­net has made you aware of those hip arti­cles on the prac­tice and ben­e­fits of Mind­ful­ness? If not, mind­ful­ness is the men­tal state of being con­scious of the moment. It is a form of medi­a­tion. It shuts out before and after, focus­ing on now. The go-get­ter busi­ness per­son con­structs a day where Now is hard to find. Atten­tion is giv­en to learn­ing from the past, to prepar­ing for the future, to stay­ing up, on trends or at night.

Stop for a minute. Relax your eyes. Order that drink and sit unjudged. It’s ok to use your busi­ness weapon train­ing here too. Go ahead, be focused and inten­tion­al, just as that busi­ness and tech­nol­o­gy arti­cle instruct­ed. Be inten­tion­al in let­ting go. Sit and be nowhere, let your mind wan­der, you nev­er know where it will go. Think of noth­ing on pur­pose and fol­low whichev­er thread finds grip. Inspi­ra­tion in the next sip. That neck knot final­ly releas­es, sym­bol of your grit and dili­gence. What good is work­ing toward the wrong goal? The barstool is here to

help realign pri­or­i­ties, to bol­ster your to-dos with relaxed assur­ances, or to bite back against them with clar­i­ty like that water glass.

The last sip. Go ahead and pay up, the val­ue far exceeds the cost. Con­sid­er depart­ing your barstool, but before you do be mind­ful of your progress. Write that idea down before unseat­ing. Re-cat­a­log the to-dos with that water glass lens. Be free, return to your busi­ness and tech­nol­o­gy grind with more aware­ness, more hap­pi­ness. Thanks barstool. It was a good ride. Pick up your dili­gence and grit, found hang­ing like a jack­et by the door.