Skip to main content

Posts

Showing posts with the label UX

UX or Ex-Users

It seems like yonks ago that I stumbled across Steve Krug's book Rocket Surgery Made Easy and loved it , so I eagerly took the chance to see him talk at the Cambridge Usability Group in a double-header with Andy Morris. In the first half, Andy talked about how Onshape try to engage and empower and delight and retain users while at the same time gathering data that the company can use in their design and support efforts. In the second half, Steve reprised some of the key points on usability testing from Rocket Surgery.

Testing Thinking, Anyone?

At Quality Jam London 2017 I was introduced to the term design thinking . It sounded interesting. I  looked it up when I got home,  spoke to Rog , our UX specialist at work, and read a couple of references that he provided. Jared Spool's Shh! Don’t Tell Them There’s No Magic In Design Thinking was particularly intriguing: For decades, I’ve needed to do what every seasoned design professional has found themselves doing: explaining why design is more than just making something pretty. When I’ve worked with other designers, they get it.  But once someone who isn’t a designer — someone who is a layperson — is introduced into the mix, I’ve found I need to convince them that design isn’t only about making the thing pretty. That’s it’s about solving problems. That’s it’s about end-to-end solutions.  ...  The phrase design thinking changed all that. To a layperson, it was completely new. While it was made up of words they thought they knew, the combination w...

Rodent Controls

So I wasn't intending to blog again about The Design of Everyday Things by Don Norman but last night I was reading the final few pages and got to a section titled Easy Looking is Not Necessarily Easy to Use. From that: How many controls does a device need? The fewer the controls the easier it looks to use and the easier it is to find the relevant controls. As the number of controls increases, specific controls can be tailored for specific functions. The device may look more and more complex but will be easier to use.   We studied this relationship in our laboratory ... We found that  to make something easy to use, match the number of controls to the number of functions and organize the panels according to function. To make something look like it is easy, minimize the number of controls. How can these conflicting requirements be met simultaneously? Hide the controls not being used at the moment. By using a panel on which only the relevant controls are visible, ...

Can You Afford Me?

I'm reading The Design of Everyday Things by Donald Norman on the recommendation of the Dev manager , and borrowed from our UX specialist . (I have great team mates.) There's much to like in this book, including a taxonomy of error types: at the top level this distinguishes slips from mistakes. Slips are unconscious and generally due to dedicating insufficient attention to a task that is well-known and practised. Mistakes are conscious and reflect factors such as bad decision-making, bias, or disregard of evidence. discussion of affordances: an affordance is the possibility of an action that something provides, and that is perceived by the user of that thing . An affordance of a chair is that you can stand on it. The chair affords (in some sense is for ) supporting, and standing on it utilises that support. focus on mappings: the idea that the layout and appearance of the functional elements significantly impacts on how a user relates them to their outcome. For examp...

The Rat Trap

Another of the capsule insights I took from The Shape of Actions by Harry Collins (see also Auto Did Act ) is the idea that a function of the value some technology gives us is the extent to which we are prepared to accommodate its behaviour. What does that mean? Imagine that you have a large set of data to process. You might pull it into Excel and start hacking away at its rows and columns, you might use a statistical package like R to program your analysis, you might use command line tools like grep, awk and sed to cut out slices of the data for narrower manual inspection. Each of these will have compromises, for instance: some tools have possibilities for interaction that other tools do not have (Excel has a GUI which grep does not) some tools are more specialised for particular applications (R has more depth in statistics than Excel) some tools are easier to plug into pipelines than others (Linux utilities can be chained together in a way that is apparently trickier in R ...

What Did You Expect?

On a whim, with hardly any forethought and with even less expectation that it'd turn up some gold, at the last Cambridge Lean Coffee I asked whether it was possible to quantify user experience and whether any of the testers there had tried. Some of the things you'd expect were suggested, including A/B testing, wireframes, and putting the thing in front of a handful of tame users. Of those only A/B testing quantifies in any meaningful, statistical sense (the other approaches described were essentially qualitative) but has a significant flaw in that possessing the data about user behaviour without understanding the intent behind it is only half the story. To the extent that I'd given it any consideration as I walked to the meeting that day, what I'd been wondering about was the possibility of rating a design before it gets in front of users. There are many toolkits that provide sets of components to be used in building a user interface and it might be reasonable...

Cambridge Lean Coffee

Yesterday's Cambridge Lean Coffee  was hosted by Chris George  at Cambridge Consultants . Here's a brief note on the topics that made it to discussion in the group I was in. Can you quantify usability? Do you try? different for specialist, small-scale products vs consumer, large-scale products? do you really want quantification?  Is Design Metrically Opposed? Rocket Surgery Made Easy suggestions included  a/b testing, putting design or prototype in front of users How to manage bug backlogs alongside sprints? very dependent on the context you're working in don't separate the bugs and other stories the tester should be trying to illuminate knowledge of the product ... including project risks (like two managers with different goals) to the product What makes you laugh when you're testing? the discovery of the unexpected thing that exposes assumptions were made ... examples included a configuration option which was only used in reporting the...

The User Inexperience

I think a lot about the user experience when I'm testing . Not only for conformance with the UX guide we refer to but also in less tangible, subjective, respects such as how the software will  feel  to different kinds of users. The UX guide can't help here. Although it has value and the potential to save time - for example, by reducing the number of discussions about capitalisation policy for dialog title bars  to merely single figures per release - at close to 900 pages it is not a shining example of usability itself and it doesn't try to answer the question  who's a user?  In particular, it has only a handful of mentions of new users outside of the section on first-timers which itself is largely about setting up the product rather than using it. Inexperienced users will at various points form a significant enough proportion of your userbase that they merit special attention and when that happens, you'll need to think about lack of experience with ...