Welcome to my blog

About Karl Smith

Karl Smith works globally with directors, stakeholders and customers of multi-national enterprises across all verticals and technology stacks whose focus is on new concepts and capabilities that drive customer engagement, interaction and retention.

He creates digital companies, strategies and services that drive customer centricity into the core of client companies, that in turn enable them to realise their ambitions to engage with and establish a consistent two-way communication and interaction with their customers.

These new companies and capabilities are underwritten with tailored blue sky work, digital strategy, management consulting and program planning fitting to tight timescales, strategically correct, fully featured, useable, governable, scalable, efficient, end to end business propositions, service designs, applications, integrations and software systems.

Karl Smith Practical Skills

He 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 Smith is a Founder and Director of UCD UK Conferences.

Karl has worked with several companies to define for launch or redefine their service offerings, business structures or digital presence including;

  • Avaloq AG – Setting up enterprise wide adoption of design thinking principals, master plan delivered in just two months.
  • Wipro Digital – Launch Wipro Digital, Design Thinking, Service Design, Creative Technology Services, User Experience Strategy, Creative Design Services, M&A Designit – 2014
  • Accenture – Launch of Enterprise User Experience, Digital Services Launch, M&A Fjord – 2012
  • Pearson Publishing – Digital Services Restructuring – 2011
  • Deutsche Bank – Self Service Paradigm Shift – 2011
  • RBS – Risk Management – 2010
  • The Oxford University Press – Mobile First Digital Strategy – 2009

Karl Smith has a wide experience in management consultancy and digital technology including business management, start-up, business strategy, digital strategy, advertising, customer experience, user experience, productisation, governance, change management, project management (waterfall & Agile), enterprise architecture and project definition, design, optimisation, delivery and digital marketing. He has been honoured by the British Computer Society for his eminence and significant contribution to the fields of UCD and User Experience with a Fellowship.

Tagged : / / / / / / / / / / / / /

#Strategic and #lean #thinking in private investment and asset portfolio participants part 2

There are several types of on boarding that relate to both business and investors structure and size, their specific purpose for investing and their local regulatory constraints.

The Main Participants

I will be focusing on four main participants in this post financial advisers (FA) and investors (I), either or both of these may be constituted by companies, funds or individuals and para planners (PP), local office administrators (external or internal) (AD), company back office administrators (AD). Other participants are traders, local regulation, international treaties, company regulation, regulatory reporting, trustees, product managers and the security services.

Financial Adviser

The role of the financial adviser is shaped by the organisation they work for both by its nature and its size. As a general rule, the smaller the firm, the more the adviser is likely to be involved in the process of client management. They will be managing their calendar, running segmentation reports, and getting to know the systems their firm uses. An adviser in a larger firm may spend more time on face-to-face client interaction and will delegate other tasks to administrators and Para-planners. They will be an avid consumer of research, but might have summaries prepared by para-planners. The adviser’s use of online tools and services will vary, but this is an attitudinal variable and is less correlated to the size of firm. They may view online tools as essential to helping perform well on behalf of their clients, in which case they will be a demanding and sometimes critical user. Alternatively they may be wary of disintermediation, seeing online servicing as a threat and something that could devalue the relationships they have carefully cultivated with their clients.

Financial Advisor High Level Processes by Karl Smith
Financial Advisor High Level Processes by Karl Smith

Para-planner

Para-planners are usually younger than advisers, and probably use online tools more frequently during the average working day. They will often carry out tasks for example, creating illustrations or portfolio models on the instructions of a financial adviser or as a way to show capability for the next step in their career. Although the Para-planner often carries out similar tasks to the administrator, their context of use differs. They may be an aspiring adviser herself, and their tasks are usually part of a larger, open-ended activity, such as research, where they help shape the approach. This means that although Para-planners often make use of process-heavy features, they are less process-driven than administrators. For Para-planners, attitudes to technology may be less behaviour-defining than for advisers: not at a sufficiently advanced career stage to make decisions on behalf of the firm, and will make use of the technologies available. Finally, they are likely to be heavily involved in the planning and aftermath of client review meetings, even if they do not attend them. They will play an essential role in meeting preparation and in executing any follow-up actions agreed with the client. In this sense they are a key resource for the adviser, and will therefore value any tools that help them work more rapidly and more effectively.

Para Planner High Level Processes by Karl Smith
Para Planner High Level Processes by Karl Smith

Investor

Of all the participants the investor is most subject to variation. The main reason for this is that, while other participants are shaped to a certain extent by their job roles and the responsibilities, constraints and priorities these involve, investors are strongly defined by attitudinal factors which vary from individual to individual. One key factor that defines how an investor interacts with the product company is their degree of financial mediation, with discretionary investors on one end of the spectrum and self-directed investors on the other. The differences between these extremes are so significant that, these will need to be defined as distinct participants later. Other factors that will strongly shape investor behaviour include risk tolerance, investment horizon, degree of financial engagement & sophistication, the amount of time devoted to financial matters, and the way online information is located and used (this last factor is important even if an investor is entirely discretionary). It is also important to remember that the investor participants as well as the product company’s business goals relating to them are heavily affected by the stage of their relationship with the product company and with their adviser.

Investor High Level Processes by Karl Smith
Investor High Level Processes by Karl Smith

Administrator

The roles carried out by administrators can vary significantly based on size of firm and the age or career ambitions of the administrator. Some administrators see the job as a transitional stage before attending university and receiving a financial qualification others might be called “career administrators” and might have been working in this role for many years. Some administrators especially career administrators may have become experts in the systems they use on a daily basis. In smaller and mid-sized firms, these administrators will probably be the company’s leading expert on these systems, and there are real-life examples of administrators who have created manuals for asset management systems which are used to train new staff. These experts can sometimes be most resistant to changes, even when the changes represent a tangible improvement, as they have invested so much time becoming familiar with the old system. Resistance to change is less pronounced among administrators who are younger, less experienced, or who do not intend to stay in the role in the longer term. Administrators are not key decision-makers in an organisation, but they are key users, if a system frustrates them and reduces their efficiency, their firm will suffer.

 

Related Posts

Author Links

Tagged : / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /

#Agile #User #stories is a #UX #method

User stories is another name for a Cognitive Walkthrough

I have been involved in Agile for a very long time, mainly because it uses methods from the human computer interaction scientific process (CHI/HCI).

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

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

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,

  1. think like a user
  2. describe what you can do
  3. build the system that enables a user to complete a task or aquire a feature

 

Author Links

Tagged : / / / / / / / / / / / / / / / / / / /

Save 35% ££ on banking change, requirements gathering should take no more than six months

Best practice, puting the missing part in a puzzle
Best practice, puting the missing part in a puzzle

Requirements gathering in Banking change programs are over detailed, over long and for the most part undeliverable.

There is and has been a huge requirement for change in British banking for several years as senior bankers have sought to lever the capabilities of technology and distributed workforces. This has in turn a great opportunity for IT consultancies to enforce their business models on the banks and make huge amounts of money without delivering anything. This has of course not gone unnoticed and forced many banks to increase their internal IT teams, but the problem remains, as the overall strategy is wrong.

The current strategy for business change requirements gathering is to fully understand the current problem with the assistance of subject matter experts (SME’s) and then defined the end state with the internal client. There are several major problems with this approach;

  • Fully understanding the problem is almost endless in Banking
  • Using SME assumes they really are experts which for the most part they are not
  • That the internal client can see the future of their business
  • That the same consultants will carry the project all the way through

The solution to this problem is a new strategy, in fact an Agile based one;

  • Defining 6 to 10 features of the new system at a high level
  • Involving the enterprise architects to see what has to be new, legacy or adapted
  • Launch the development team during the definition phase
  • Detail the features and get time costs from the designers and developers (not the PM or delivery manager)

Doing the above will change the relationship between requirements and delivery making requirements a service to the delivery of the project rather than an impossible set of promises made by people who will never have to keep them.

The 35% savings is probably low it’s just the 14 months and 35% of a budget wasted on an investment banking project that were eventually discarded. I’m considering a new concept in banking requirements gathering, value for money, is anyone interested?

You can contact me on karl@karl-smith.com

Tagged : / / / / / / / / / / / / / /

#User #Experience #UX #Process

Process thinking in User Experience (UX)

The first step in user experience needs to be the recognition that every problem is different and will require a separate solution. Because if they are not, then every business is the same which they are clearly not.

In effect there is no quick fix or single standard method but rather there is an armoury of methods each with associated risks, limitations and plus points. Anyone offering a standardise method without flexibility should be asked to leave as they about to cost you a fortune.

Karl Smith User Experience Research Testing 200711

Offering user experience services is a bit like dungeons and dragons in that you role your 12 sided dice and hope the business does not throw some trolls at you.

I have worked with very well known agencies who are unable to get their clients to understand the importance of user experience – research, testing and solutions as they focus on the solutions component without proper understanding that it is only one part of a three stage process. The reason that clients give for not paying for research and testing is the assumption that user experience people a such great experts that they can do their job in total isolation from the business and the end users.Maybe ‘Super User Experience Person’ does exist but I doubt it, most importantly users change over time, in what they want and mean by their actions.

Some process steps for user experience

This process list is based on personal experience and is open to reduction or extension based upon just how savvy the client is and how much they really want to be successful rather than just being seen to be doing something.

Understand the problem (concurrent with 2.)

  1. Do research
  2. Analyse research
  3. Get validation of what has been discovered by Target Users and Stakeholders

Define the audience (actors) this is the detail level the Target Users

  1. Create personas a tool used by the entire project team BA’s, PM’s and Developers to be acquainted with who will use the systemResearch persona types, activities, attitudes etc.
  2. Define critical tasks Research tasks ecosystem and review engagement strategy
  3. Define key pathways Main pathway
  4. Alternative pathways
  5. Failure pathways

Compose concepts

  1. Create buy-in with Stakeholders

Set the tone of voice

  1. Type of language
  2. Level of formality
  3. Use of jargon, brand identity or subject specific words
  4. Content style
  5. Meta standards
  6. Content object model
  7. SEO if web based

Wireframes

  1. Selection of type & method
  2. Wireframe Concepts
  3. User testing of Wireframe Concepts
  4. Wireframe sketches

Client sign off

Wireframe prototypes

  1. User testing of Wireframe prototypes

Client review

Wireframe & Visual design integration (prior to this point the use of high fidelity images are counter productive)

Functional specification & analytics specification

  1. Instruct development
  2. Usability Test plan
  3. Accessibility Test plan
  4. Functional & Content Test plan

Testing with participant screening document

  1. Review testing results
  2. Modify labels, interactions & structure in line with findings

Done, until …..

Check interactions based upon analytics and more user testing

Offer enhancements to clients

Some people will look at this list and think it takes years, depending on the project complexity it can take days or weeks for simple web or mobile applications and only months on complex software systems.

Tagged : / / / / / / / / / / / / / /

#UX #requirements #gathering methods #determine #value

Requirements gathering methods determine value

There are lots ways to elicit UCD requirements so I don’t intend on listing them all here, what I will note are some of the effective ways that I utilise. They can be described as structured, unstructured or a mixture of the two, but importantly the methods produce differing depth of requirements dependant not only on the method but on the skill of the facilitator and the characteristics of physical location used. In effect the method used is limited by the capability of the facilitator.

Research Structure

It is critical to determine if there is enough usable information around the project to be able to establish a valid research start point. Get the questions right and the answers follow, get the questions wrong and you’ll waste a fortune. If your unsure carry out a pilot study to find out what the questions are.

Methods

Observational / Reflective

Asking users to carry out their normal activities while being observed does take quite a bit of setting up so that the activity data is not skewed as a result of the observation. It is critical not to participate or lead the user. It is especially common when users are told the fine detail about the project; they will try to give you what they think you want. Often this is because they feel threatened by the process, the old notion of time and motion leading to them getting sacked is embedded in British culture. However this type of method is very useful in a pilot study to determine what type of activities should form the basis of questioning or workshop based co-creation.

Narrative

Narrative is about stories, like the narrator in a play, they see the whole thing being able to talk in the present, remind of the past, note the future or describe a similie that others can relate to even if they cannot yet relate to the main story.

Asking users to describe how they think something should work (Cognitive Walkthrough), what the differences might be for different user types, how it’s done now, is there anything in other technology or experience that they can relate it to. In this way a multi-path picture can be built up from each participant for each interactive pathway within the new system or technology.

Diagnostic

Diagnostic is about testing something this will often manifest through workshops with groups of people. By setting a group a task or co-creation ‘Design the front page of your new website’ spending ‘K10,000,000 that’s Karl’s currency’ on to meet your goals and noting the group dynamic, decision making and outputs, very rich information is revealed by participants.

Show and Tell

Show and tell is imperative to feed back to participants what has happened to the information they have provided. More it can be used to validate key concepts and project directions in a fairly light environment, where participants can be highly critical knowing that everyone else is in the same frame of reference for that meeting.

Some of the Problems

Although the whole process exists to elicit information suitable to influence the project, some participants will have pet requirements that if not given the correct level of sycophantic response they will seek to invalidate the entire project as it does not represent their vision of what the project is any more. This type of attitude is very common when working with low pay low (self) risk bureaucrats, as they can personally destroy projects then blame it on ‘expensive’ consultants.

Case Study 4

On a national census project that was due to be run online and offline a member of the bureaucratic project team insisted that their opinions were correct on the basis of having won an award for a website ten years earlier. The opinions were very dated to the point of being bad practice, incorrect and were a constant disabler to the project. This client refused to consider an open support system, marketing website (to prepare country) or full language landing pages to support the full ethnic background of the country in question. The day to day engagement was painful, but the UX for the several forms, question logic and user interactions were eventually signed off even though the client never signed off the personas based upon the requirements they gave.

Tagged : / / / / / / / / / / / / /

#UX #Requirements #gathering #preparation

People focused Requirements

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.

Screening Participants

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.

Selecting participants

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.

Tagged : / / / / / / / / /

#UX #Requirements gathering #structure #determines #success

Requirements gathering structure determines success

The Requirement Starting Point is Critical

It is an understood factor in travel that if the journey starts even half a degree wrong then the final destination will be considerably different from where the person intended to be, this is for many why there is a make do culture when working with technology requirements.

Requirement Types

Unfortunately bad requirements gathering can seriously derail a project before it really begins.

There are several types of requirements gathering research that are carried out as separate work streams.

1. Market requirements

Includes competitor analysis and proof of concept.

2. Business requirements

Includes business stakeholder perceptions and business KPI’s.

3. Technology requirements

often described as non functional requirements, including existing capabilities (hardware, software and skill base) and comparable technologies.

4. User Experience requirements

behaviour research, KPI’s, perception research and interpretation for the specific project domain.

Requirement Gathering

One of the key things to understand is that the structure and implementation of requirements gathering in each type is different even if some methods may appear the same, their interpretation and output are not. Additionally in HCD (human centered design) the method of interpretation and output are user centric rather than business centric, I find user stories a very helpful output method as it maintains user goals in a structured format that can be reused in the development process.

Case study 1

In a recent project the client requested assistance in setting up the requirements gathering process, they were intending on having groups of people from the same department together. One of the key things to understand in structuring research is the possible points at which the data can be skewed and therefore become less valid. It is human nature in a group for people to temper what is said if senior staff is present.

Instead of running the requirements gathering along department lines it was defined by UCD stakeholder roles;

  • Senior managers (strategic high level thinkers)
  • Managers (project capability thinkers)
  • Production (detailed problem solving thinkers)
  • External users (frustrated users with wide subject based experience)
  • External consultants (cutting edge thinkers with wide subject based experience) as a design panel

There was also screening documents for participant selection for each role in order to assist in defining effectual research methods. Participants were sent an overview prior to sessions so that they would understand what was going to happen at very general level. In parallel an external agency was commissioned to research market requirements in the same domain and in a comparable domain. A technology audit was also carried out to support the technology requirements component.

Case study 2

In another project where the client was intending the project to effect change in multiple countries and markets requirements gathering research was conducted in several countries. The United Kingdom was used as a baseline country with adaptations defined through in person and remote research for Eastern Europe, Western Europe, USA, South America and South East Asia.

Tagged : / / / / / / / / / / / / /

User centered design to ISO 13407

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.

Simple user centered design project lifecycle visualization
Simple user centered design project lifecycle visualization

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

Tagged : / / / / / / / / / /