Forewords by Robert Powell and Patrick Neeman. Designing for Humans remains for me the most fantastic amalgamation of the complex to create the simple, useable and nascent components and artefacts that support human experiences. I’ll apologise in advance while I try to use simple English I often fail because someone came up with a word that covers off the complexity I’m trying to express. I use dictionary’s often when writing, not least because I’m dyslexic and can’t see letters, I was taught to read the gaps between them in primary school by a special teacher, so my perspective is often quite different from others.
Fundamental to my work in designing for human experience is my early experiences of human augmentation in supporting what the world describes as disability. When I was eight (1970’s) my father was involved in setting up a respite centre for the families disabled children. It was the first time I’d seen technologies that support people in doing what I take for granted and it changed my perspective on technology and what it means to be human.
“I’m not interested in Technology; I’m interested how Technology evolves our human experiences”
Looking back, it was clear from an early age that I accepted all people, recognised individuals and gained the realisation that everyone had strengths and limitations. Through my design training at school, college and then university I was able to frame questions about; what does it mean to be human? Ergonomics and Anthropometrics is what started me on questioning why technologies were not measurable against who uses them and their physical, emotional and intelligence limitations. If that’s offensive think about it, everyone has limitations they also have strengths, certainly I have benefited by having to work harder with reading and writing than others through being able to make connections others cannot see, I’m not special just different.
User Experience has become the solution focused end of User Centred Design, being based in normal practice on usability, accessibility and user research over time.
The Term User Experience/User Centred Design and Human Centered Design are interchangeable because the International Standard changed from being User Centred Design to Human Centered Design.
In my other posts it should be clear by now that I have been involved in what now called UX for some considerable time. I have previously mentioned how UX moved from the strategic and its equal status to enterprise architecture into software development and becoming visual design for a time. Well it’s on the move again, just as UX incorporated marketing components with repeatable science at its outset and seeded Agile with user stories and human context, so now it has moved into organisational and cultural transformation.
Organisational and Cultural Transformation
There are now in 2019 many people talking about organisational and cultural transformation and change however it is clear that what they mean is everyone below the C-suite needs to change. However organisational and cultural transformation is the whole organisation otherwise it is just a rebrand without actual change. More especially culture is born from action not just intent and this is what organisations who want to change are discovering. They want to take their staff on a transformation journey and to evolve their engagement not simply recasting them with new role titles and responsibilities. They also expect to evolve the transformation in flight gaining a true understanding of what already works well and folding it into the new culture. This kind of transformation takes a highly adaptive and pragmatic mindset in its leadership and enablement.
The historical focus of organisational design has been to establish one standard structure across a whole organisation. The value of this is to standardize command and control mechanisms which is supposed to simplify reporting and oversight. It forces all work through it regardless of its priority or type of work it is.
The old four types of organizational structures are;
Matrix Organizational Chart
Flat Organizational Chart
However the New Ways of Working in adoption of HCD, Agile, Lean and DevOps don’t utilize these structures. In fact instead of starting with organizational structures it focuses on work to define the structures needed to deliver it. This is very intensive consulting activity and often led by external consultants not vested in internal politics and previous alliances.
And this explains why most new organisational transformations will fail before they start because they are focused on hierarchies not getting work done efficiently with a culture that rewards and honours people who deliver.
The common structure of work is linear and directional often following the concepts of grouped specialisations handing work to each other having completed their activities. This creates a slow flow of work with bottlenecks around capacity. When unexpected work arrives and depending upon its priority it can destroys the whole flow of work and create ripples impacting the whole organisation. This behaviour with work is derived from industrial production techniques often related to the Ford production model of manufacturing.
In adoption of HCD, Agile, Lean and DevOps, work types are defined first and then the organisational structure is derived from the work types. The consultancy around the organisational design should be unique to each organisation in order to both facilitate taking porfilio work into viable and validated and measured delivery.
Psychology of Transformation
In large organisations there have been lots of transformations and people are used to dealing with them, adept at absorbing language and funds without actual transformation or the derivative cultural change. So as far as possible the psychology of transformation is defensive for the mainstream of organisations. Delivering long term cultural change therefore requires a top down adoption in order to establish an authoritative perspective of We Change rather than You Change.
In new ways of working YOU change is not the way to succeed it must be WE change together
Human Centred Organisational Design TOM
At this point I’d normally publish the exactly how to do it, but to be honest in the wrong hands it’s a stick of dynamite, so I won’t just hand it out. Below is the Portfolio Planning for Business Agility for an Organisation focused on a Work Type Taxonomy rather than hierarchies.
If you’d like like to find out how to do this from someone who’s done it in an organisation with 80,000 staff contact me.
Pervasive UX #pUX an evolutionary UX that enables (#ubiquitous) #Open #IoT #Ecosystems through Human Centered Design #HCD
This talk is about the need for UX to dig deeper into its core capabilities to facilitate Smart Living and true Ubiquity in the form of Open IoT Ecosystems.
Pervasive UX is contextual responds to eye movement, hand gestures and voice
While for many recent joiners to the UX profession Open IoT Ecosystems are a daunting proposition, to those with both understanding and experience of the evolution of UX they are an opportunity to return to core values and the eminence of our profession.
UX and CX are the same thing, UX created CX as there was a drift in the mainstream away from data science towards visual UI’s. User Centered Design (UCD) was renamed Human Centered Design (HCD) in 2010 and are the same thing, a framework not a method for a wide array of professional practitioners and clients.
In this talk, Karl Smith with briefly describe the evolution of UX and the core competencies required to facilitate the next human revolution through Pervasive UX.
Thank you to everyone who attended our (Karl Smith and Thom Heslop) talk at SXSW, it’s the start of a long road into a really complex and contextual problem. But being silent in the crowd as the King walks by with no clothes on is not an option, peoples lives, futures and prosperity is at risk, not to mention the risk of multi-trillion dollar lawsuits that can follow by knowingly distracting people who are engaged in critical tasks.
The IoT – Internet of Things (Ubiquity) is the next great opportunity for commerce to engage with business enterprises and customers. However, there is no unified approach to the mental load between physical interaction, mental interaction and digital interaction. This cognitive landscape is inhabited by associated experiences that gel human behaviour and machine interfaces through, touch, mouse and keyboard. The usage of sight, voice and thought create new complexities and risks which have until recently been the subject of defence technologies (battlefield and strategic), where clear outcomes and prescribed mental models exist.
The diversification of these touch points and multi-point human logic models clash and derail human thinking patterns.
We are looking for people and their knowledge to help create an Ubiquity Open Standard. We are doing this because no one else has noticed this fundamental error in thinking, the hoping that product based companies will work together in creating common standards that are driven by an understanding of human thinking capabilities, cognitive models, relational thinking and machine interactions is unlikely.
While product manufactures continue with supremacy attitude to other ecosystem products and services,
“the human voice and our needs and desires are subjugated to simply another component”
albeit the one that is constantly paying for everything without any input on how it works.
Some Foundations (the rest will go in a technical paper)
Distributed Cognition studies the ways that memories, facts, or knowledge is embedded in the objects, individuals, and tools in our environment. According to Zhang & Norman (1994), the distributed cognition approach has three key components: Embodiment of information that is embedded in representations of interaction Coordination of enaction among embodied agents. Ecological contributions to a cognitive ecosystem.
In Embodied Interaction Dourish -everyday human interaction is embodied; non-rationalising, intersubjective and bodily active. User, not designers, create and communicate meaning and manage coupling. Not just concerned with what people do, but also with what they mean by what they do and how that is meaningful to them. It reflects the sets of meanings that can be ascribed to objects and actions over those objects as part of a larger task or enterprise
Cognition the key to the mind, how people understand what they can do is by comparison a Diagnostic Methodology (goals, adaptations, conventions) with what they already know by accessing the Active Narrative patterns they have created in their own minds according to Smith (2005).
Cognition Groups create a communication paradigm, they carry intention, meaning, risks and benefits.
Some Cognition patterns are common, shopping basket etc.
Some Cognition Patterns are social by Family, Sports Team etc.
Some Cognition Patterns change without notice
Guided Interaction, existing websites offer guided interaction – simplified cognitive pattern encapsulating a plethora of interacting technology and data systems: Shopping Basket – This representation allows for distributed cognition > appropriation > cognitive pattern forming understand– once a user has used a shopping basket they will understand how to use them and generalize: transferable cognitive pattern
Some of the issues with the IoT
There is no standard of interactivity for humans in the IoT – not a problem if passive background machine-to-machine. A very big problem if actively interacting with humans, who are all different and can create their own meanings for example LOL.
How does a user form any cognitive patterns from an invisible system?
IoT combines known patterns as hidden machine-to-machine communications that can create mistrust and security fears
Detailed component view we have constructed around daily interactions is no longer valid
Some of our initial research
IoT Design Principals
What is device / service for?
Where will it be situated?
When will it be triggered?
What other devices will it be interacting with?
Where can it clash?
Security? – * Lack of security – Shodan
Design Principal: “Do No Harm”
IoT Design Risks
Context is critical
Situational interaction problems for consideration
The following barriers reduce our ability to understand the situation
Perception based on faulty information processing
Excessive motivation – over motivated to the exclusion of context
A possible solution
Avatar (can be visual, sound, texture, smell, taste or a combination) – smart use of Artificial intelligence (AI), where the users cognitive interface is patterned on their unique cognition pattern through a learning algorithm
This avatar should be directional and instructional like digital signage
This avatar should respond to the users behavioural interaction and should fall away gracefully as users behaviour becomes more ‘expert* In effect it should be a learning system – learns from the users rather than based on static rules
For example the AI that George Hotz has built into his self driving car while not the answer points to the kind of thinking required to find the answer, don’t tell the machine to watch and learn from a human and then carry out your task (from 3.33 to 5.04) “the point is to drive naturally like a human, not some engineer’s idea of safety“. For anyone who then thinks this is the final solution, please let us know why you think driving a car is like cooking dinner or navigating the street?
Karl Smith is a highly competent, personable, creative and motivated person with a keen insight and definition ability. He is a critical thinker and able to rapidly discover the essence of problems then define, communicate, create buy-in and deliver end to end digital and process solutions. He positively motivates those around him and is able to engender a great team dynamic by leading from the front. He has business experience since 1989 at comparable levels in fields including defence, industry, energy, pharmaceutical, biomedical, construction, fashion, finance, banking, FMCG, property, publishing, healthcare, travel, policing, crown office, local and central government. He has specialist banking experience with investment, private, commercial, business, trading, wealth management in Europe, USA, China, Australia, Japan and Russia.
Karl has worked with several companies to define for launch or redefine their service offerings, business structures or digital presence.
Certified member of the Scrum Alliance Certificant ID: 52664
I’m surprise no one else has blogged about the use of CHI/HCI processes in Agile before, but though I should say something as I keep getting told that it’s interesting how many CHI/HCI people have embraced Agile. In fact it’s the other way around
Agile has imply appropriated UX techniques that have new Agile names
The main one is User Stories; they are in fact a reuse of the Cognitive Walkthrough, but I’ll let you draw your own conclusion.
Cognitive Walkthrough is a method utilised to express how the system works from a user perspective it exposes potential usability failures and defines happy and unhappy pathways
The method starts with a task analysis that specifies the sequence of steps or actions required by a user to accomplish a specified task. The system response to each action is noted. The designers and developers of the software then walk through the steps as a group this enables an agreed view. They ask themselves a set of defined questions at each step to determine all the potential outcomes. Afterwards a report of potential issues is compiled and the project team has a clear focus on the various user pathways including happy paths, risky paths, error paths and failure paths.
User Stories are a quick method to determine the who, the what and the why of a business requirement and are produced in a narrative format as if a user was walking through their use of an interactive system
User stores are written at two levels Epic Stories that define groups of functionality (registration) and User Stories that define a single piece of functionality (sign in).
User stories are written by the product owner (an Agile tile for stakeholder or product manager) a user experience architect or a business project manager (not a scrum master) or the development team when they break down stories that are too large (these are then confirmed by the product owner).
The method starts with defining the Epic stories, then breaking these down into smaller stories that relate to an encapsulated (self standing) component. In design and development these stories can be parcelled to the various specialisations including user research (end user validation, How It Works), visual design, user experience design, back-end development (feature and service delivery), security and front end development. These stories will have their interlinks (to other components) stubbed out until those stories are built and can be integrated.
Agile + CHI/HCI = User Centred Requirements, Human Centered Design and Human Centered Development.
They are not exactly the same but the essential method is,
think like a user
describe what you can do
build the system that enables a user to complete a task or aquire a feature
There has been massive change management taking place across all sectors of British banking over the last three years. Much of this is driven by buy outs and mergers, some by efficiencies and a little more recently through questioning the nature and controls around risk management.
However simply changing the owner has caused major problems in these banks as their competitive advantage and therefore their value has been an amalgam of very different skilled people, internal processes and market penetration from the bank or group buying them. These internal processes have often evolved in a highly organic method through acquisition and proven delivery often driven by individual people. However once this people based relationship is broken and these processes are exposed to a wider audience they pose serious questions in relation to risk management, value and the continuance of revenue flow.
The standard process applied has been to pass these processes over at division level to change program managers, at department level to business analysts to define the scope of the current structure. After definition many of these process based activities are passed over to information technology to resolve. I remember being taught at University (Napier, Edinburgh) that technology should never be used as a substitute to sound business process; however this technology determinant does not seem to have been passed on to banking business people. While not the best starting point, people who work in technology do tend to ask the right questions, to define epic requirements, even when it’s unpopular with the business.
Information technology analysts take these epic requirements and define an A to Z system ‘what it does’. However to get the B to Y user requirements (or stories), a user centred design analyst, ux research and designer spends time with the users to define ‘how it works’. This may seem obvious to digital practitioners outside banking, but it’s a revelation to those inside banking and banking technology, that users who normally find ways around poor software are able to define the requirements that turn a useful application into a killer application.
This is not really the end, more a beginning, if other sectors can learn from banking, that users (not stakeholders, usually no longer active users) can determine the overall success of software. And that user centred design (UCD) can assure and amplify competitive advantage if underwritten by skilled practitioners, then the possibility of success is significantly raised in all software and change programs.
Capturing requirements is subject to other peoples availability, this remains one of the most painful parts of the process as few participants seem to understand just how important their experience is to the project. Often a participant can shape the final output without realising they have done so, I include a Show and Tell component to requirements research as it informs participants that the information provided is important, has been used and is affecting the whole project. Additionally Show and Tell is critical to validation and creating buy in. I will post more about Show and Tell later.
Creating a participant profile
There are several key questions that the facilitator needs to ask themselves when preparing to do research;
What do I need to know?
How will I cross relate requirements sessions?
Does this domain have it’s own rule system?
Does this domain have it’s own language and is it inclusive or exclusive?
The participant profile needs to represent the answers to the above questions, a good place to look for participants is senior managers (not directors) as they still have direct reports from the bleeding edge of business but have gained a level of strategic understanding both for their area and the ebb and flow of internal politics. Dependant upon the project type an understanding of the their knowledge base (within the business or organisation) is required as it determines the weight their views should carry. Other significant factors include; length of service (often describes personal drivers), education background and level, attitudes and behaviour (tend to be observational by selectors) and social / business importance.
There is a huge amount of internal politics involved in projects and often unsuitable participants are forced on projects, often as internal staff have failed to create buy in internally. I tend to work with a selection group of two to three internal people to help me understand the value each participant add to the project or the threats and risks associated with their internal agendas.
Case Study 3
I was involved with a offshore wealth management (HNW and UHNW) companies major project as a UX consultant for a new truly complex asset trading and policy construction system (a type of which I had completed before as an Enterprise Solutions Architect). I had requested but never received a profile of each participant as they had been pre-selected by the client. I had spent several days meeting people with valuable hands on experience and then I was put into an office with a Director of Sales who after 10 minutes showed an obvious controlling agenda stating “they work for me” when describing several staff members (who incidentally did not work for her). I completed the requirements gathering process and found that the Director of Sales requested other staff in the agency to work on the project. The agency involved had no specific experience in this type of system so had acquired my services specifically to work on this project. I understand they are now on to their third UX person on this project since I left, frankly the project is not standard UX and they are in deep trouble. On my side I was stunned but still think it’s one of the funniest experiences I have had working with people.
In short if your standard preparation methods have been circumvented by your clients it is a clear indication that there are problems now and will be problems on the project in the future.
In the United States there is strong governmental support that has led to about 11 pieces of disability legislation. The key legislation, the Americans with Disabilities Act (ADA, 1990) which applies to all walks of life was effected in 1992 during the George Bush (Snr) administration.
User centered design (UCD) is a project approach that puts the intended users (audience) of a product or piece of technology at the centre of its research, design and development. It does this by talking directly to the user at key points in the project to make sure the product or piece of technology will deliver upon their perceived requirements and align the client with their market.
The following elements operate in a cycle being repeated until the project’s objectives have been attained. This makes it critical that the participants in these methods accurately reflect the profile of actual consumers.
ISO 13407 outlines four essential activities in a user centered design project:
Requirements gathering – Understanding and specifying the context of use
Requirements specification – Specifying the user, organisational, technological and standards requirements
Design – Producing concepts, architectures, visual designs and prototypes
Evaluation – Carrying out user based assessment of the product or technology
User experience has in recent years become the greatest area of fraud and theft in business. Because the output documents appear simple huge numbers of people without any formal knowledge of what goes into them are having a go.
Be careful of Fakes
Avoid designers, look for Architects and Consultants, with an MSc and good client references (but not a portfolio) which can be viewed on LinkedIn.
The most common request for people involved in user experience is to produce wireframes (low fidelity pictures) a task that a child could do.
Wireframes should be the container document for standards, insights into target audience expectations, business KPI’s and brand values.
Ignorance in UX can be costly
The real problem is that recruiters and clients don’t know what they should be getting for their money.
A good indicator that someone is ignorant is a request for a portfolio. A portfolio is a set of images that express the capability of a designer involved in architecture, graphics, fashion design etc, but it is not relevant for UX. The reason it’s not relevant is that the complex ideas within wireframes need an expert to review and validate them against standards.
People who want to see a Portfolio are incompetent
If the interviewer does not know the standards, frankly they deserve to be fleeced, it’s like employing a plumber to represent your interests in court instead of a solicitor because they can make a good argument. The action of the argument is not important, even if there are lots of buzz words included because legal matters like usability matters are complex interrelated sets of rules and dependencies.
So unless an expert does the review the activity is pointless, a secondary but probably more damaging problem is ownership, rights and breach of contract.
Wireframes contain information on “How it Works” not “How it Looks”
How something works is the inventive element and belongs to the client. If clients are not protecting their Intellectual Property in UX, they really should be quite aggressive about it, but all contracts have a provision for this protection asking to see UX work from clients is a breach of contract and breach of IP.
Asking people to show a UX portfolio is asking people to breach their contracts.
If you or your team require training on interviewing UX people please contact me.