Name: Sketching User Experiences
ISBN: 9780080552903

Sketching User Experiences

Sketching User Experiences approaches design and design thinking as something distinct that needs to be better understood-by both designers and the people with whom they need to work- in order to achieve success with new products and systems. So while the focus is on design, the approach is holistic. Hence, the book speaks to designers, usability specialists, the HCI community, product managers, and business executives. There is an emphasis on balancing the back-end concern with usability and engineering excellence (getting the design right) with an up-front investment in sketching and ideation (getting the right design). Overall, the objective is to build the notion of informed design: molding emerging technology into a form that serves our society and reflects its values. Grounded in both practice and scientific research, Bill Buxton's engaging work aims to spark the imagination while encouraging the use of new techniques, breathing new life into user experience design.

What Hacker News says

mablopouleOct 2026

Not OP, but the issue for me is that for the longest time doing software development meant translating potentially nebulous requirement into strict computer logic.

The process of creation is often a back-and forth between that fuzzy concept in your head (or an natural-language spec that is often ambiguous), and the (usually reduced) physical object / drawing / computer program you've created to materialize this idea. That imperfect projection of your initial idea then helps you refine what this idea implies, and what are the different tradeoff you could take [0].

That back-and-forth has to be made when writing the computer code, even if it's going to be compiled after, because code needs to be detailed enough to force you into expressing the desired behavior with clarity. Prompting Claude on the other hand usually means that you let the LLM resolve this ambiguity for you.

In some case the details don't matter, and it's a productivity gain, and in other case the devils are in the details, and you've let Claude make important technical decision for you, even though Claude doesn't know how much those decision match the needs of the project.

Personally I think of my role as a software developer as someone who know technical possibility (and technical limitations), and weight the different tradeoff it implies to propose code that solves a business problem. And that's the crux of the issue with only creating code by prompting Claude Code: it gradually robs me of my ability to understand the technical possibility and limitation of the system.

[0] This idea has largely been taken from the very good book "Sketching User Experiences: Getting the design right and the right design", about the processus of ideation / sketching.

thread

mathewsandersDec 2018

Every couple years I’ll go read Magic Inc by Bret Viktor (not a book, just online: http://worrydream.com/MagicInk/) and I always find it refreshing reminder to think about how we can design technology to help us rather than just create a CRUD interface.

‘Sketching User Experiences’ by Bill Buxton https://www.goodreads.com/book/show/980280.Sketching_User_Ex... and ‘Mental Models’ by Indi Young: https://rosenfeldmedia.com/books/mental-models/ we’re both very influential to me as a young designer thinking about process and I believe they are still both relevant.

thread

felipeeriasDec 2018

My three favourites are:

→ "Sketching User Experiences", Bill Buxton

→ "The Elements of Typographic Style", Robert Bringhurst

→ "Understanding Comics", Scott McCloud

There are lots of books on concrete design methodologies and particular aspects of the field, but they tend to become dated rather quickly. If they are tied to specific technologies, they become dated even faster.

Having said that, a clear and concise introduction to the modern design process is:

→ "Designing for Interaction", Dan Saffer

thread

patrics123Jun 2017

Hey there! Here is my perspective (Freelance Usability Engineer, Degree in Software-Engineering and Human-Computer-Interaction) on your situation...

Quick answer: Your hunch is right. If you actually NEED quantitative research with scientific findings in the end you would need a lot of data (> 1.000 evenly distributed participants, no bias, no research background, ideal target group) and a bullet-proof testing set up with control groups etc.

But, from reading what you intend to do - this is not actually what you need. My assumptions are as follows (tell me if I am wrong): - You don't need to publish anything "scientific" in the end - You don't have a unlimited budget or large enough expected $$ outcome to justify spending lot of money into making it "statistically correct" - You want to test/build/validate hypothesises quickly to come up with a viable product solution within reasonable effort and timeframe (Usual Entrepreneur / Intrapreneur limits)

Long answer: I love the idea of approaching "idea generation" from a analytical + user centered point of view. Too often the engineers or founders give birth to a new feature or something "we should try" without checking if there is any possibility the users need it too. Because? Most of entrepreneuers and engineers would rather DO and IMPLEMENT stuff they like instead of waiting and talking to users - only to find out "their idea" is not needed at all.

I have done several projects in different niches where we did extensive user observation (contextual inquiry in their real life working environments [1] ) and requirements engineering interviews. What people tell you != what they actually do and feel! Nowadays this might be called "idea extraction" but uses the same concept of asking about their work process, good, bad, annoying and time consuming tasks. Trying to talk and ask without suggesting anyting and paying attention to their answers...

User interviews should be structured and you should try to be neutral + ask the same questions over and over again. BUT you dont need 1000 people. Usually it is far more effective to talk to (or observe) 7-10 people about one specific topic because you will still catch 80% of their issues and there will be patterns you can recognize.

So my personal approach would be to "scientifically" form 3-5 hypothesises which can be validated or invalidated by analyzing data, observing users and asking specific questions. Do your homework before and after, check analytics, get more insights from your databases, pre-validate your ideas and come up with observation-scenarios and questions which will validate or invalidate your hypothesis. Usually a few will already drop dead. Now as you are suggesting you would like to validate by using a product or prototype of some sort? For early validation and testing I would recomment to read "Sketching user experiences" from Bill Buxton [2] - lot of low fidelity ideas to test a product before writing any code at all.

You can either use live users to test some hypothesises, use remote usability testing tools or invite 5-10 people into your office for conducting a actual user test. I would highly recommend to go step by step. Only do a in house ux test if you are actually convinced something will work and you still have hypothesises on real users behaviour. The effort is far to high for just trying out stuff on an idea-level.

I hope this added some insights to your current challenge? Patric

[0] http://uxstepbystep.com [1] http://www.usabilityfirst.com/usability-methods/contextual-t... [2] https://www.amazon.de/gp/product/0123740371

thread

overeaterOct 2016

Some of the reading list in the UI/UX course at Brown:

http://cs.brown.edu/courses/csci1300/

Particularly (free links with pdfs),

Don Norman - Design of Everyday Things https://archive.org/details/DesignOfEverydayThings

Bill Buxton - Input Manuscript http://www.billbuxton.com/inputManuscript.html

Alan Cooper - About Face http://feiramoderna.net/download/pos-positivo/COOPER-Alan/Ab...

Vignelli - The Vignelli Canon http://www.vignelli.com/canon.pdf

Bill Buxton - Sketching User Experiences http://bscw.wineme.fb5.uni-siegen.de/pub/bscw.cgi/d807887/Sk...