Good UI delivers visibility, feedback, control.

Golden Krishna's thoughts on 'NO UI' prompted a response by his colleague at Cooper Design, Stefan Klocek, who argued back that good UI can be, should be, is desirable. Design should not be about removing UI, but that good UI is instead about those three big things that Don Norman focuses on: visibility, feedback, control. Klocek's article is available from The Cooper Journal (link)

The best interface is no interface

Who doesn’t want Twitter inside the refrigerator? 

I'm sorry, Twitter in my refrigerator, why?

“Upgrade your life” with a better refrigerator door from Samsung and check Tweets when getting some water from the fridge?? 

 How do you make a better hotel lobby? Slap an interface in it. A giant touchscreen with news and weather is exactly what’s missing from my hotel stay?!?? Golden Krishna argues that our love for the digital interface has gotten out-of-control. With more than a touch of irony...

"Creative minds in technology should focus on solving problems. Not just make interfaces."

From The Cooper Journal (link)

What customers really want?

How do you decide what product feature to develop next, how to enter new markets, address more customers, how to disrupt and innovate with your product?

• Innovation is hard.
• Innovation is not simply a matter of inventing new stuff.
• But yes, innovation is all about the introduction of the new.
• Introduction implies dialogue, talking with and listening to.
• Innovation holds out the promise of growth and transformation, both of which are difficult to predict based on historical data.

What customers really want is something for a "job to be done". Think of this in terms of what the customer comes into your shop to buy.  Think of it as your customer having 'a goal in mind' and your product or service is simply an 'in order to...' But sometimes the product you deliver is like an infrastructure or background against which the customer does something.

SnapChat is a bit like this (as are email, FaceBook etc). The service offers some way that lets the customer do something; send a message, post a photo, annotate or draw on a photo, share the picture with friends.

Think of your product and features in this way. No one buys a phone for the pleasure of owning a phone, they own it in order to call and receive calls. At a very basic level your product or service is simply an 'in order to..', it is necessary equipment for the 'job to be done.' This basic level of utility merely gives your product permission to be considered for use. 

http://blogs.hbr.org/2014/05/generating-data-on-what-customers-really-want/
also
(http://www.ie.edu/business-school/faculty-research/faculty/juan-pablo-vazquez?_adptlocale=en_US)

Juan Pablo Vazquez Sampere offers the following diagnostic in order to address this problem, of finding out what customers really want.

1. List what you think are the 10 key characteristics of your product offering (e.g. speed, easy to use, ergonomic, cheaper than rivals, etc.)
2. Then interview 10 users and 10 non-users of your product, but importantly ask them questions that seek to understand their "job to be done" and "in order to's'.

For users start by asking:

"
a) Where are you when you are using this feature?
b) When you use this feature, what are you really trying to do? (accomplish, achieve...)
c) If this feature were not available, what would you be using instead?
You can ask the second two questions without reference to your product.
(Sampere, 2014)"

Likewise as non-users the second two questions without reference to product, they don't use it anyway but they still attempt to achieve "in order to's" or complete "jobs to be done". Vazquez's steps 3, 4 5 & 6 are methodological: 3 - Transcribe the recordings, 4 - code the transcripts, 5 - group codes, 6 - interpret the data (in this article Vazquez recommends quantitative analysis of the coded data). Alternatively I recommend the application of grounded theory to code and interpret this kind of interview based quasi-ethnographic qualitative data. Basically Vazquez has provided a light-weight sketch of an interpretive investigation, how to research the subjective aspects of product use.
The same questions are employed for product design, in particular for discovery and evaluation. These activities may go by different names; requirements engineering, feature design, and testing. They may be embedded within the various documents of a product project plan or design specification. They are however of such fundamental importance to good product design that we really should bring them to the front.
Don Norman's design framework in the Design of Everyday Things (1988) highlights the need for designers to focus on these 'jobs to be done' or 'in order tos'. These are equivalent to the question we ask users; 'what is the goal'? Norman elaborates further on two 'gulfs' between users' intention and what happens in the world. Designs must necessarily overcome these gulfs in order for the user to succeed in their intention. The designed object is the link between a user's goal and the world they are situated in. Execution refers to a designed object's capability to satisfy the user's goal. Evaluation refers to how a designed object responds or signifies state, essentially how feedback is presented to the user. 

Seven questions are posed for designer and user:

"
The goal question:
1. Forming the goal (Q: What do I want to accomplish?)
The gulf of execution involves 'discovery'. Users ask:
2. Forming the intention (Q: What are my alternatives?)
3. Specifying the action (Q: What can I do now?)
4. Executing the action (Q: How do I do it?)
The gulf of evaluation involves feedback. Users ask:
5. Perceiving the state of the world (Q: What happened?)
6. Interpreting the state of the world (Q: What does it mean?)
7. Evaluating the outcome (Q: Is this OK? Have I accomplished my goal?)
"
(p48 DOET and in Instructor Notes on Udacity)

"Good designers empathise with the people that they're designing for" Don Norman. The key concepts that designers employ (according to Norman) are the following:

• Affordances
• Signifiers
• Conceptual model
• System image
• Discoverability 
• Feedback

The best designs disappear from mind

There is a view that good design should disappear from view, should not direct itself to mind, should be invisible. Good designs, designed things, tools and things that get used, should not impose themselves on their users. Or rather, our interaction with the designed object should be so natural and seamless that we do not need be present-aware that we are using the tool in attaining our goal. Use-in-work (and enjoyment-in-use?) with a well designed tool, product or service should, in a sense, occur beneath direct perception, acting as a natural extension of our physical and sensory engagement as we are engrossed in the activity or goal we are directed towards.

The article in Wired (link) reminded me of these design principles, and it introduced me to Dieter Rams' less but better (weniger, aber besser) and his other "ten principles of good design". It set me thinking about how these principles apply to software design...

Another topology of research methods for design

Another depiction of the spectrum of possible research methods, a way of classifying them, a way of understanding their application and use. (link to the Interaction Design Foundation article)

From the article on UX Research Communication – Report Writing

Exercise: Requirements Design Trade-off

This exercise has been adapted from Alexander’s ‘Notes on the Synthesis of Form’ (Alexander, 1964); the simple design problem from section 1 ‘the need for rationality.’ Alexander’s classic design tetrad characterises trade-offs between the major product requirements: simplicity, performance, features, economy.

Objective
Organise, model and explore the interrelationship between different requirements.
Requirements/Design Preparation
1. In groups of 2 or 3 categorise the following non-functional requirements for an imaginary high tech product.
Statement of non-functional requirements

1. A simpler product (system, service, device) will be easier to manufacture and operate.
2. A simple product with fewer features is going to be less costly to maintain.
3. A simple product is easier to construct as it has fewer features.
4. Greater system performance or power is achieved by including more (advanced) features.
5. A highly optimised product is difficult to improve, change, fix or maintain without degrading its performance.
6. A simpler product does not deliver as many features or options as a more complex product.
7. A simple product using fewer specialised parts will not perform to as high a level as one using specialised optimised parts and sub-systems.
8. Adding more features makes the product more difficult to maintain.

2. Consider following product requirements categories: Simplicity, Performance, Feature Set, Build/Operate Economy.

3a. Map these non-functional product requirements to the following categories: Simplicity, Performance, Features,  Economy (+ or - for complement or conflict). 

3b. (Online version) Use a Jamboard to draw the trade-off diagram (link). Each group draw numbered arrows with plus or minus indicators (+/-) to complete the diagram, illustrating the relationships between the requirements listed. 

Discussion:

• Do requirements influence design decisions?
• Is a unique solution possible satisfying all requirements?
• Do requirements specify design?
• Is it possible to overcome contradictory requirements?
• Would more detail enable us to overcome contradiction?
• Will computer modelling of requirements enable conflicts to be resolved?
• Does the design of the product limit which requirements can be delivered?
• Is there always a trade-off between requirements and design?

Reference:
Alexander, C. (1964) Notes on the Synthesis of Form, Cambridge, Massachusetts, Harvard University Press.

---

A Collage of Outputs from the Requirements Exercise