Design without touching the surface

I am prepar­ing two class­es at the moment. One is an intro­duc­tion to user expe­ri­ence design, the oth­er to user inter­face design. I did not come up with this divi­sion, it was part of the assign­ment. I thought it was odd at first. I wasn’t sure where one dis­ci­pline ends and the oth­er begins. I still am not sure. But I made a prag­mat­ic deci­sion to have the UX class focus on the high lev­el process of design­ing (soft­ware) prod­ucts, and the UI class focus on the visu­al aspects of a product’s inter­face. The UI class deals with a product’s sur­face, form, and to some extent also its behav­iour, but on a micro lev­el. Where­as the UX class focus­es on behav­iour on the macro lev­el. Sim­ply speaking—the UX class is about behav­iour across screens, the UI class is about behav­iour with­in screens.

The solu­tion is work­able. But I am still not entire­ly com­fort­able with it. I am not com­fort­able with the idea of being able to prac­tice UX with­out ‘touch­ing the sur­face’, so to speak. And it seems my two class­es are advo­cat­ing this. Also, I am pret­ty sure this is every­day real­i­ty for many UX prac­ti­tion­ers. Notice I say “prac­ti­tion­er”, because I am not sure ‘design­er’ is the right term in these cas­es. To be hon­est I do not think you can prac­tice design with­out doing sketch­ing and pro­to­typ­ing of some sort. (See Bill Buxton’s ‘Sketch­ing User Expe­ri­ences’ for an expand­ed argu­ment on why this is.) And when it comes to design­ing soft­ware prod­ucts this means touch­ing the sur­face, the form.

Again, the real­i­ty is, ‘UX design­er’ and ‘UI design­er’ are com­mon terms now. Cer­tain­ly here in Sin­ga­pore peo­ple know they need both to make good prod­ucts. Some prac­ti­tion­ers say they do both, oth­ers one or the oth­er. The lat­ter appears to be the most com­mon and expect­ed case. (By the way, in Sin­ga­pore no-one I’ve met talks about inter­ac­tion design.)

My con­cern is that by encour­ag­ing the prac­tice of doing UX design with­out touch­ing the sur­face of a prod­uct, we get shit­ty designs. In a process where UX and UI are seen as sep­a­rate things the risk is one comes before the oth­er. The UX design­er draws the wire­frames, the UI design­er gets to turn them into pret­ty pic­tures, with no back-and-forth between the two. An iter­a­tive process can mit­i­gate some of the dam­age such an arti­fi­cial divi­sion of labour pro­duces, but I think we still start out on the wrong foot. I think a bet­ter prac­tice might entail includ­ing visu­al con­sid­er­a­tions from the very begin­ning of the design process (as we are sketching).

Two things I came across as I was prepar­ing these class­es are some­how in sup­port of this idea. Both result­ed from a call I did for resources on user inter­face design. I asked for books about visu­al aspects, but I got a lot more.

  1. In ‘Mag­ic Ink’ Bret Vic­tor writes about how the design of infor­ma­tion soft­ware is huge­ly indebt­ed to graph­ic design and more specif­i­cal­ly infor­ma­tion design in the tra­di­tion of Tufte. (He also men­tions indus­tri­al design as an equal­ly big prog­en­i­tor of inter­ac­tion design, but for soft­ware that is main­ly about manip­u­la­tion, not infor­ma­tion.) The arti­cle is big, but the start of it is actu­al­ly a pret­ty good if unortho­dox gen­er­al intro­duc­tion to inter­ac­tion design. For soft­ware that is about learn­ing through look­ing at infor­ma­tion Vic­tor says inter­ac­tion should be a last resort. So that leaves us with a task that is 80% if not more visu­al design. Touch­ing the sur­face. Which makes me think you might as well get to it as quick­ly as pos­si­ble and start sketch­ing and pro­to­typ­ing aimed not just at struc­ture and behav­iour but also form. (Hat tip to Pieter Diepen­maat for this one.)

  2. In ‘Jump­ing to the End’ Matt Jones ram­bles enter­tain­ing­ly about design fic­tion. He argues for pay­ing atten­tion to details and that a lot of the design he prac­tices is about ‘sig­na­ture moments’ aka micro-inter­ac­tions. So yeah, again, I can’t imag­ine design­ing these effec­tive­ly with­out doing sketch­ing and pro­to­typ­ing of the sort that includes the visu­al. And in fact Matt men­tions this more or less at one point, when he talks about the fact that his team’s deliv­er­ables at Google are almost all visu­al. They are high fideli­ty mock­ups, ani­ma­tions, videos, and so on. These then become the start­ing points for fur­ther devel­op­ment. (Hat tip to Alexan­der Zeh for this one.)

In sum­ma­ry, I think dis­tin­guish­ing UX design from UI design is non­sense. Because you can­not prac­tice design with­out sketch­ing and pro­to­typ­ing. And you can­not sketch and pro­to­type a soft­ware prod­uct with­out touch­ing its sur­face. In stead of tak­ing visu­al design for grant­ed, or talk­ing about it like it is some innate tal­ent, some kind of mag­i­cal skill some peo­ple are born with and oth­ers aren’t, user expe­ri­ence prac­ti­tion­ers should con­sid­er being less enam­oured with acquir­ing more skills from busi­ness, mar­ket­ing and engi­neer­ing and in stead prac­tice at the skills that define the fields user expe­ri­ence design is indebt­ed to the most: graph­ic design and indus­tri­al design. In oth­er words, you can’t do user expe­ri­ence design with­out touch­ing the surface.

Published by

Kars Alfrink

Kars is a designer, researcher and educator focused on emerging technologies, social progress and the built environment.

5 thoughts on “Design without touching the surface”

  1. This is a return­ing debate. Agree on the con­clu­sion that you can­not think about design­ing an expe­ri­ence with­out think­ing about the inter­face itself. That does not mean of course that you can have a spe­cial­i­sa­tion in the detail­ing of the visu­al aspects of an inter­face and also on the oth­er end detail­ing the sys­tem­at­ic aspects of the design. Every­one is an UX design­er, some have bet­ter skills for detail­ing the visu­al aspects, oth­ers for think­ing on the func­tion­al working.

    The con­text of the prod­uct is of course rather defin­ing. A short-term cam­paign has dif­fer­ent chal­lenges than a dig­i­tal plat­form product. 

    You men­tioned you are a bit dis­tinct from prac­tic­ing this domain, but that should be very use­ful. I am very curi­ous how you could embed the approach from game design into the UX design. The sep­a­ra­tion of wire­frames and visu­al design should not be the prac­tice. An UX design­er that lim­its its think­ing to the wire­frame was nev­er a good prac­tice but is in the cur­rent con­text of sys­tem­at­ic dig­i­tal prod­ucts a no go. 

    So ide­al­ly UX and UI design­ers are both respon­si­ble for design­ing the expe­ri­ence on a fun­da­men­tal lev­el and take their respon­si­bil­i­ty to detail the UX and UI tasks and have to keep work­ing togeth­er. This goes also for the devel­op­er by the way. Espe­cial­ly as they are all part of the scrum team cre­at­ing the product.

  2. UX design is cer­tain­ly not a syn­onym of UI design. I agree that UX design is more high lev­el — more abstract, but UI design is not just the visu­al sur­face and cer­tain­ly not just turn­ing wire­frames in pret­ty pic­tures. Jesse James Gar­ret pub­lished his mod­el The Ele­ments of User Expe­ri­ence back in the year 2000 (http://www.jjg.net/elements/pdf/elements.pdf). The mod­el shows inter­face design as the sec­ond lay­er of a pro­duc­t’s design, build­ing on three, more abstract, lay­ers. This sec­ond lay­er is in turn the foun­da­tion for the visu­al design; pret­ty pic­ture some may say, but I see it as the lay­er to com­mu­ni­cate intent and meaning.

    Inter­face design is for one part visu­al (wire­fram­ing, putting rec­tan­gles in a log­i­cal and effec­tive lay-out), but also includes under­stand­able word­ing, micro­copy, use­ful defaults and sort orders, (avoid­ing) error mes­sages, sup­port for key­board, mouse, and touch input. All those details that lead to ‘ease of use’.

    User expe­ri­ence is much more than ‘ease of use’, ux adds use­ful­ness and desir­abil­i­ty to the equa­tion. UX is so com­pre­hen­sive that I don’t believe in one per­son hav­ing all the skills to design a great ux. I do believe in ux-teams, where spe­cial­ist — not only design­ers — work togeth­er. A tru­ly great ux starts with under­stand­ing ‘con­sumer’ needs and mar­ket oppor­tu­ni­ties, includes tech­ni­cal fea­si­bil­i­ty and con­tin­ues after sales with cus­tomer ser­vice. UX not only con­cerns the one prod­uct in devel­op­ment, but takes the ecosys­tem in which the prod­uct will oper­ate into account. 

    The broad­ness of ux, and the depth of detail in inter­face design jus­ti­fies two sep­a­rate classes.

  3. I agree with you, Kars, on that the dis­tinc­tion between UX design and UI design is unwork­able. Some thoughts on this.

    One prob­lem is, that ‘design’ as a label is often wrong­ful­ly under­stood as a noun (hence the sub­di­vi­sions), rather than a verb (which does not allow for sub­di­vi­sions). Design first and fore­most is a prob­lem-solv­ing approach, using pro­to­types of increas­ing fideli­ty to both under­stand the prob­lem and explore solu­tions at the same time. In this process, the inter­ac­tion between prob­lem, designer(s) and solu­tion is key, iter­at­ing as many times as need­ed to ful­ly under­stand the prob­lem and to arrive at the best fit­ting solution.

    The prob­lem you encounter springs, as I see it, from the way ‘UX’ and ‘UI’ are tied to fideli­ty lev­els in the process, thus putting deliv­er­ables cen­tral, instead of the iter­a­tive process.

    As a side­note: Adding to the noise is the lack of a sep­a­rate label for mere visu­al work in the Eng­lish vocab­u­lary. In Dutch and Ger­man there’s a clear dis­tinc­tion between the design I describe above (‘ontwer­pen’ or ‘Entwer­fen’) and the visu­al design (‘vor­mgeven’ or ‘Gestal­ten’). But here also, prob­lems arise, as the scope of Bauhaus or the Hochschule für Gestal­tung in Ulm would have been broad­er than mere visu­al design.

  4. Pingback: Wednesday is Link Day Still Breathing - online home of Chris Taylor - web developer, musician, geek

  5. Good old fash­ioned blog com­ments! This is awesome…

    Let’s see, where to begin. Okay, JJG’s mod­el is maybe a use­ful point of depar­ture. I would say I have the top two planes in mind when talk­ing about UI design, plus a part of the third plane. (Sur­face, Skele­ton and Struc­ture in the sim­pli­fied ver­sion.)

    And of course UX design cov­ers all of it. So yes the trou­ble is it is very com­pre­hen­sive and when prac­tices at a suf­fi­cient­ly large scale requires teams of spe­cial­ists (and gen­er­al­ists, I would add) work­ing togeth­er in a cross-func­tion­al manner.

    I am all about design as a prac­tice char­ac­terised by a par­tic­u­lar cog­ni­tive style. This is why I am such a huge fan of Bux­ton’s book in which he so elo­quent­ly shows sketch­ing to be a defin­ing aspect of any design prac­tice, includ­ing user expe­ri­ence design and by exten­sion also user inter­face design.

    Let me addd that I real­ly don’t like the term user expe­ri­ence design because expe­ri­ences can’t be designed direct­ly in my view—they emerge from a per­son­’s inter­ac­tion with a prod­uct (or ser­vice, or sys­tem, or what­ev­er). But I guess we are stuck with the label and might as well make the most of it.

    With regards to the time-hon­oured split between wire­frames and mock­ups and the lie we often tell our­selves that “wire­frames aren’t visu­al design” I’ll just say I think that is non­sense. You are mak­ing fun­da­men­tal choic­es that find their way into the inter­face so you are prac­tic­ing inter­face design and visu­al design because you’re deal­ing with stuff peo­ple will look at. If you’re going to do this, you might as well acquire a mod­icum of under­stand­ing of visu­al design or more pre­cise­ly graph­ic design (as Vic­tor argues in the paper I link to in the orig­i­nal post).

    Of course there are “non-visu­al” deci­sions a UI design­er or a UX design­er needs to make while sketch­ing and pro­to­typ­ing and mak­ing wire­frames. As Vic­tor points out a lot of those choic­es ben­e­fit from knowl­edge from the field of indus­tri­al design and by exten­sion inter­ac­tion design.

    All of which brings me back to my orig­i­nal point. How can you prac­tice UX with­out also deal­ing with UI? I don’t think you can. In the case of soft­ware prod­ucts, what is the user expe­ri­enc­ing if not the inter­face? I think you do your­self a dis­ser­vice if you do not strive to be able to “jump to the end” as Jones calls it in the talk I link to in the orig­i­nal post. Assum­ing a process which relies on sketch­ing (as per Bux­ton) there is inter­face design hap­pen­ing from the very begin­ning of a design process. 

    I am only con­cerned with all of this because I am wor­ried organ­i­sa­tions make bad deci­sions about how to build UX teams if they think “user expe­ri­ence” and “user inter­face” are two sep­a­rate con­cerns. (I would pre­fer to call them design teams by the way but what­ev­er.) This leads to such bull­shit as the ketchup bot­tle meme which has been doing the rounds on LinkedIn and is being used by many well-mean­ing but mis­in­formed indi­vid­u­als to argue for the fact that UI is “how it looks” and UX is “how it works”.

    I real­ly hate all these labels. They are not ground­ed in real­i­ty and are more pre­scrip­tive than they are descrip­tive. But I am not inter­est­ed in redefin­ing them. That’s a fools errand. I just want to try and get to some kind of use­ful place by start­ing from their cur­rent usage and rea­son­ing to new usage which might actu­al­ly reflect actu­al best practices.

Comments are closed.