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.