UX Design: The most difficult concepts to explain (list)

Last week I asked on twitter which concepts were hardest for UX designers to explain to their teams. As promised here are the responses with some commentary.

The big risk in looking at lists like this is it’s easy to fall into the trap of blaming other for what are our limitations. This violates our own advice:

Designer hypocrisy: to preach

It’s true that some people we work with should have learned these by now, but it’s wise to err on the side of improving how we teach rather than blaming the students.

Which makes Christian Crumlish’s comment perhaps the most valuable:

I prefer learning and understanding my coworkers’ and bosses’ concepts over explaining mine. My concepts are working materials that will show up in my framing and discussion and ideally speak for themselves. They don’t need to learn my jargon unless they ask to.

The list of difficult concepts

These were the three most common responses:

You are not the user (#). The difference between UI & UX. It’s not just what it looks like… it’s how it works too. Perception is often that UX is just a lick of paint (#).

Here is the rest of the list (I trimmed duplicates):

Some of the most important UX research that’s conducted has nothing to do with deciding where to put a button (#).Designers learn through the act of making (#).Doing research up front will not slow you down, but will save you time (#).That vision work and deep thinking through longer term complexity takes time and that time trades off against filling the timeline with reactive/nearterm work (#).For me, it’s that there’s a difference between knowing the space and knowing how users experience the space(#).That we can’t make the currently being worked on feature the most discoverable. No matter what you’re currently working on, it has to be in the context of the overall journey(#).Not everything is a visual deliverable(#).Looks good ≠ is good (#)That I am not the source of ideas. That I can’t work in a vacuum and produce user experiences. That UX is not a single input at the start of a pipeline of work, or a checkbox on a project list (UX is a process, not a deliverable)(#).That we dont have all the answers. Our job is to help uncover the answers (#).Design coherence. A solution is not simply a collection of features or functions, it is the way they fit together in a sensible, useful way. Adding or removing an element may be easy to do gracefully, or very hard, depending on the overall design (#).That a single change often has cascading consequences — that parts are (or should be) always related to the whole (#).UX vs. UX Theater (#).If you aren’t designing the right thing, you can’t design the thing right (#).You must define functionality before implementation. And probably draw a map in between (#).Pretty and efficient aren’t mutually exclusive, but pretty ≠ efficient (#).In the case of software especially, we have to consider not only how it feels to do a task once, but how it feels to do that same task ten times a day, every day (#).The “user experience” is not owned by a company, but by people. It’s actually people trying to live, tackling their problems or striving for their aspirations. Their experience is bigger than any single touchpoint or brand (#).The complexity has to live somewhere. You can’t make something powerful and infinitely flexible for power users ALSO be intuitive and simple for beginners (#). That a feature is not a user goal (#).That I usually should not (and often can not) provide off-the-cuff design advice without understanding the context of a product/feature/service (#).Reminding people that we have to avoid shipping the org chart (#).The user experience doesn’t start and end at the confines of a screen (#).Defining the problem and the outcomes is key – the same design can be done 10 different ways but each of those 10 options are solving for different problems and lead to different outcomes (#).Reframing. The thing they think they want turns-out not to be the best opportunity, but once they have that thing in their mind, it’s impossible to convince them it won’t work (even if something else will work better) (#)That UX is not just doing what customers want but that it is the process of understanding what customers need and combining with the business goals to deliver best experience (#).Research is (MUCH) more than usability testing (#).The easier it looks, the more work it took to get there (#).Metric tradeoffs: why sometimes it’s worth it to take a short term hit in a key metric in exchange for an overall experience improvement that harder to quantify (#).The fact that designers and everyone who intervenes in perception have an ethic responsibility to those humans first, not to the business. As designers we have a responsibility to be congruent & empathic and to hold the people we design for in unconditional, positive regard.(#). Even the best UX design can’t fix messed up organizational structure or people problems (#).The difference between strategic work (decision-making) and tactical work (hands-on crafting), and how designers must be good at both (#).That UX debt (the many small decisions that lead to inconsistencies and bad behaviors) will cause major negative consequences both for internal teams and customers down the road. It’s worth it to put in more effort to avoid it even if it takes more time (#).The fact that ‘It depends’. Context has a huge influence on what could be the best solution to a problem, but my experience has been that often people expect the UX designer to have answers based on abstract rules instead. Yes: there are best practices, but still … it depends (#).Progressive Disclosure – a design should only be as complex as they are ready for at the time (#)

Have one that isn’t listed? Or a great way to explain one of these? Leave a comment.

 •  0 comments  •  flag
Share on Twitter
Published on February 09, 2021 16:30
No comments have been added yet.