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 risk with lists like this one is it’s easy to fall into the trap of blaming others for what are our limitations. This violates our own advice:
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. All experts forget that what is basic to us isn’t basic to everyone else.
Which makes Christian Crumlish’s comment perhaps the most valuable:
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.
Many don’t realize that designers use the process of making as a way of thinking. My manager recently asked me, regarding a design being done under extreme time pressure, to “just tell me what the solution will be”. I said that in this case that was impossible, because I needed to draw the design in order to know if it works. He did not understand, “just tell me what you will do”. He was a computer scientist (and a brilliant one) who likely is used to imagining, theorizing, and planning a solution first, and then implementing it. I explained that for many designers, drawing/making is not just dictation of what appears in our minds, a la Mozart, but an interactive dialog between our minds and the forms we create, which evolve together in a dance until solutions are reached.
What’s curious is as a computer scientist, he knows very well there is a creative process in deciding what to build. Programming from scratch has definite parallels to the design methods UX designers use (define the problem, prototype, learn, iterate). This is even more so for computer scientists who do research, where prototyping and experimenting are an even larger part of their work.
Somehow he doesn’t see the connection, but it’s there. Computer Science as discipline formally ignores the creative process – they don’t have a language for it and don’t teach people how to think through it (as far as I know) – which is really a shame.
You see this in other disciplines, too. I frequently struggle helping my kids with math homework. Before I can help I have to re-learn all the intermediate steps that feel unnecessary to me. I’ve always grasped math intuitively. Show me a proof and I go from step A to step D and couldn’t explain the process in between.
This is great when I’m doing something for myself, or working toward a solution that can be proved. But it’s not so helpful when I want to teach someone else, or convince someone that my answer is right.
Absolutely true. All experts face this kind of problem.
I think intuition is at least often misunderstood. There is this quote “The only ‘intuitive’ interface is the nipple“ which is wrong. Perhaps there is no such thing as an intuitive interface, at least the mouse is not intuitive. I’d say touch interfaces can be quite intuitive. Anyway, most people confuse intuitive with „works like MS Windows“. And that can be a problem when a designer comes up with something which is more or less intuitive and people reject it because they think it’s not.
Thanks for explaining the difficult concepts in UX designing.
A very interesting topic discussed here!
Thanks to the author.
Most people don’t understand how user research with a small sample (eg, 5-15 people) is valid and useful. The desire for large samples and quantitative methods is great. And while that can also be useful, you really want both. It’s easy to say “We can’t make decisions based on just eight people,” or whatever. In some cases they are making decisions on no user data, but for some reason some data is more scary than no data.