Home‎ > ‎

Service design

Service Design

Architecture begins where engineering ends

1.       Business Requirements. Answer why clients (customers or business units) need a new product or an enhancement over the existing one.

2.       User Requirements. Answer what user needs/goals (use cases) the product should meet

3.       Functional Requirements. Answer what functionality the product should have in order to meet user requirements.

4.       Non-functional requirements and business rules. Answer how the product should work in terms of non-functional requirements and business rules. Non-functional requirements are quality attributes of a product, such as usability, performance, privacy, and security. Business rules are mainly conditions, constraints, and formulas that determine how requirements will be handled by the user.

Service Startup::Design Thinking gets Lean, Tenny Pinheiro

“Design is not just what it looks like and feels like. Design is how it works.” — Steve Jobs

The ability to involve users early, as co-designers, in the development process is essential, as it increases the likelihood of generating valuable results.

According to the interesting perspective of former MIT professor Edgar Schein, the underlying model for the corporate culture is composed by three main drivers: Assumptions, values and artifacts.

Assumptions - Deeply embedded, taken-for-granted behaviors that are usually unconscious but constitute the essence of the culture.

Values - Organization's stated values and rules of behavior. It is how the members represent the organization both to themselves and to others. This is often expressed in official philosophies and public statements of identity.

Artifacts - Include any tangible, overt or verbally identifiable elements in an organization. Architecture, furniture, dress code, and office jokes are good examples of organizational artifacts. In order to impact the overall behavior of an organization, there is the need to design for each one of these drivers.

Eise’s five drives:

1.      There is only service. Products are service avatars.

2.      All value is created over use, not ownership.

3.      Innovation is a perceived value and, as such, cannot be imposed by the provider.

4.      A service-oriented thinking is naturally more sustainable and human-centered.

5.      To be of good service is directly connected to the pursuit of happiness and purpose in life. That can be found in most creeds and religions around the globe.

The experience prototyping approach is not the same as the MVP test bait approach. That is because it comes early in the project, opening the space to turn users into co-designers. Early experience prototypes can be used in a project with three main goals:

1.      Set the context for users to participate in idea generation and co-development.

2.      A service enactment, or role-play, to explain or learn from a complex concept.

3.      A test to validate specific service interactions, or the entire service journey.

The idea that you need to take care of viability first and then run tests to determine whether or not the proposal has value to the customer is wasteful. It is smarter to reverse this approach and anticipate what is valuable to people prior, and then go from there to refine the findings into viable models.

[Service first]

1.      Get a deeper knowledge about the way this person lives, works and relates to others.

2.      Now, think about things that would be of good service to this person and that you can afford to buy.

3.      Try and see if he/she likes it. If not, learn something and go back to step one.

In the 1960s, Edward de Bono stated in his book Lateral Thinking that in order to trigger creativity, it is more useful to separate the moments when the team is generating concepts from the moments of the refinement and evaluation of those concepts. By approaching idea generation in this way, people have the freedom to imagine and create while still pursuing grounded and realistic outcomes. This separation of creative “moods” is well represented by the Double Diamond diagram.

The Double Diamond is divided into 4 stages. The first, Discover (<), proposes a deep contextual dive in the challenge scenario. It is at this stage that designers use ethnographic techniques to figure out how people live, work, and relate within the context being studied. Then we have the Define stage (>), in which the team refines and narrows the insights gathered, trying to see patterns and reach conclusions from the collected data. Next, the team moves on to the Develop (<) stage, where ideas and prototypes are generated. At the next stage, Deliver (>), the team focuses on additional refinements and adjustments, crafting more mature prototypes. The main objective here is to evolve the ideas into possible solutions and document them in a way they can be crystallized.

When service design enters the Lean Startup, bringing its outside-in perspective, the scientific perspective characterized by the MVP evolves to accommodate new lenses and intentions. The implied emphasis on technology and internal resources (Viable) evolves to a human-centric orientation (Valuable), and its Product inclination shifts to the more adequate Service logic.

Minimum (inheritance: Agile) There’s no need to propose another mindset for startups than one that is laser-focused on the minimum offer. So in that sense, Lean Startup nailed it. This is the perfect mindset for operating with low resources.

Viable to Valuable. (inheritance: Design) A viable service that serves no one is simply another huge form of waste. The change in the V represents the capacity of design to deeply connect to users’ needs and desires, empowering the team to propose valuable solutions. It’s been established already that it is more efficient to have the team focused on value creation instead of having viability as the guiding mission of the project. Viability definitely still comes into play, but only later on. Considerations of viability will help the team refine its generated concepts and find ways to bring real solutions to life.

Product to Service (inheritance: Service-dominant logic)

 

Software design description[1]

·         Data design, structures within the software

·         Architecture design, information flow characteristics

·         Interface design, internal and external program interfaces

·         Procedural design, structured programming concepts

·         IEEE 1016 viewpoints

o   Context

o   Composition

o   Logical

o   Dependency

o   Information

o   Patterns use

o   Interface

o   Structure

o   Interaction

o   State dynamics

o   Algorithm

o   Resource

·         IEEE Working Group P1016, IEEE Standard for Information Technology—Software Systems Design Descriptions[2]. Baseline:

o   Standard Dictionary of Electrical and Electronics Terms (IEEE Std 100); Glossary of Software Engineering Terminology (IEEE Std 610,12-1990)

o   Recommended Practice for Software Requirements Specifications (IEEE Std 830-1998); Standard for Software Verification and Validation (Std 1012-1998); supplement (Std 1012a-1998)

o   Recommended Practice for Software Design (Std 1016-1998)

o   Standard for Functional Modeling Language—Syntax and Semantics for IDEF0 (Std 1320.1-1998)’ Standard Conceptual Modeling Language—Syntax and Semantics (Std 1320.2-1998)

o   Recommended Practice for Architectural Description of Software-Intensive Systems (Std 1471-2000)

o   Industry Implementation of ISO/IEC 12207:1996 Software life cycle processes; ISO/IEC 12207:1995 Software life cycle processes—Life cycle data; ISO/IEC 12207:1995 Software life cycle processes—implementation

o   Guide to Software Engineering Body of Knowledge, May 2001

o   UML Object Management Group (OMG) formal/01-09-67

o   Z Consensus Working Draft 2.7

o   Information Technology—Programming languages, their environments and system software interfaces—Vienna Development Method-Specification Language—Part 1

o   Specification for information systems products using Structured Systems Analysis and Design Method, version 4.

Specifications[3]

ISO adopted

1.       Business Process Model and Notation (BPMN), ISO 19510:2013. http://www.omg.org/spec/BPMN/index.htm

2.       Unified Modeling Language, v2.4.1, Part 1: Infrastructure: 19505-1:2012, Part 2: Superstructure: 19505-2:2012. http://www.omg.org/spec/UML/

IT Portfolio Management Facility (ITPMF)

Systems Modeling Language (SysML)

 

Unified Modeling Language (UML)

Provide system architects, software engineers and software developers with tools for analysis, design, and implementation of software based systems.

Level 0: A single language unit for modelling class-based structures common to most object-oriented languages; entry-level modelling capability.


Goals of specification techniques;

·         Correctness

·         Precision

·         Conciseness

·         Consistency

·         Understandability


Design Idea

Objective: To check and filter ‘Design Ideas’ against organisation needs

Scope: Any design idea presented to Management for consideration

Who and When: Anyone delegated to examine ideas

Process: Service ides is first checked against an Idea Checklist and organisations current range, skills and equipment capabilities.

Idea checklist:

·         New idea replaces current service

·         Complements existing service

·         Idea requires new processes

·         Idea requires training

·         Idea requires new documentation

·         Idea will meet new standards/regulations

·         Idea from known supplier or customer

·         Idea requires test marketing

·         Cost can be estimated for prototype

·         Produce a Product Flow and Activities Diagram to give a clear picture of what needs to be completed

Project Proposal:

·         Service description

·         Estimated delivery time: 6 months

·         Estimated work and parts cost

·         Estimated personnel costs

·         Estimated customer interest and list of potential customers

‘Design is not a result, it is a process’

Marc Hassenzahl’s Model of User Experience

Progressive Design

1.       Cultivate your designers, developers and managers at all levels

2.       Manage the prototyping process, on insight, exploration, relation and resolution

3.       Eliminate assumptions by researching, studying and analysing all aspects, all channels, all markets. Don’t assume you know, know. If assuming, failure is more likely than succeeding.

4.       Minimise misinterpretation from minimal viable production sprints. Simple customer interactions require simple system architecture.

5.       Appoint a Head of Design. Expertise must span perception, balancing poetry, engineering, architecture, and artistry. Bring business, concept, production and customer logic to the executive table, incorporating lean manufacturing, insightful vision and rigorous design processes. Rely only on the process and result from your explorations, from frameworks.

6.       Perceive your design intent. Communicate your story, infuse your message, and deliver the vision.

7.       Challenge your design intent. Design limitations must be known. Knowledge is key to challenge your design.

8.        Achieve your design intent. Search for hidden meaning.

9.       Manage your design intent, to lead your product rules and principles through lean and agile development, defining your inputs and outputs.

 

Strategy

Poet

Operations

Engineer

Tactics

Architect

Creation

Artist

Investment

Poet

Business

Analysis

Customer

Segment

Value

Proposition

Story

Prototype

 

Insight

Exploration

Foundation

Engineer

Viable

Potential

Market

Requirement

Minimal

Framework

Technical

Prototype

Reach

Architect

Behavioural

Studies

Customer Expectations

Channel

Synergy

Product Prototype

 

Relation

Resolution

Believe

Artist

Emotional

Needs

Design

Language

Brand

Loyalty

Service

Prototype

 

Stakeholders

·         Service designers/technical product managers

·         IT professionals

·         Network designers

·         Product managers/business managers involved in defining and managing a service from a business perspective

·         Program/project managers

·         System integrators

·         Process re-engineering professionals

·         Operational managers

·         Service managers

·         Operational environment users

Designing for services, tasks

1.       Capturing a complete set of customer, business and service requirements. Take a holistic view of the service

2.       Designing and using suitable (telecom network) technologies

3.       Designing and using suitable IT systems to manage those technologies

4.       Designing the Business Support Systems, Operational Support Systems (OSS) and operational processes for customer and service management functions

Product managers are marketers, not engineers or designers.

Service description

·         What?

·         Drivers

·         Features

·         Customer/end-user experience

·         Service levels needed to be supported

Action research cycle (Susman and Evered’s, 1978)



[2] http://www.iso-architecture.org/ieee-p1016/base-docs.html/

[3] http://www.omg.org/spec/

Comments