DesOps : the Next Wave in Design (Part 5) The Definition & the 3 Dimensions

DesOps is about defining a culture of design through improved work practices and communication among the design teams with the inter-cum-intra project/product teams and stakeholders and aiding these practices with the help of technology to bring communications among the involved tools and the arching eco-systems.

In recent times many have attempted to define the DesOps in easier words to the community. But many of those attempts never went beyond the explorations beyond the efforts put to define a Design System. In many cases in many UX communities and teams, the definitions of DesOps is limited within the scope of Design System, which in turn essentially is a meta-product i.e. a product that enables other products. Then what is the scope of DesOps?

In my view, DesOps is not only about tools or technology employed which is generally referred to the discourses about binging automation and improved process re-engineering in the engineering sense. Rather DesOps is about defining a culture of design through improved work practices and communication among the design teams with the inter-cum-intra project/product teams and stakeholders and aiding these practices with the help of technology to bring communications among the involved tools and the arching eco-systems.

So DesOps is rather a combination of —

Designing of Design Culture and Communications + Work practices EcoSystem of Tools & Technologies 

In the Designing of Design Culture basically the design process is involved to come up with a solution that takes into account the existing gaps and areas of improvement which is needed for a specific organisation where communities or a teams involved in product life cycles, (in case of Software industry, it’s more influenced from the Software Development Life Cycle ) to improve productivity, remove wastage (in terms of effort, delivery timeline, man-power etc. ) and in many cases establish a lean process and methodologies. As DesOpsis associated with these aspects, and especially the Lean Process and methodologies, it intern impacts the culture and how the team collaborate, work and communicate.

DesOps, in other words, empowers the philosophies of the Lean UX and Fail-Fast models of start-up organisations in a better way. So the process that involves the work-culture, team – communication, product feedback loops etc. are re-designed as a part of DesOpsimplementation and this is referred as Work practices.

To aid the above two, in DesOps implementation, the focus is more on automation involving certain workflow engineering to support the re-design process (referred in the paragraph above). Basically, this 3rd aspect is more about the translation of the about two aspects with the help of technologies and building and putting in places the tools to define the required eco-system that brings seamless delivery track and complement it with DevOps through continuous and integrated delivery approach with the arching feedback loop. The use of automation in this aspect improves efficiency and scales the whole process across the whole product delivery cycle and reduces wastage.

So here is a crude way to group the different dimensions of DesOps, which come into play while modelling DesOps solution for a target organisation or team. Let’s not take them literally as many of these dimensions have overlaps among them, for example, the way we work might involve components from the cultural shift dimension.

desops.png

1. Culture 

i. Principles & Practices

ii. Cultural Shift towards Lean Philosophies

iii. The way the team works (Mostly Design team but not excluding the intra-team work-culture)

2. Process

i. Work-flows

ii. Feedback- loop

3. Eco-System

i. Technologies

ii. Tools

iii. Design Systems

iv. Automation architectures and approaches

Stay tuned and be part of the DesOps journey with me.

(c) 2018, Samir Dash. All rights reserved.

Advertisements

DesOps : the Next Wave in Design (Part 3) The Maturity of Design Systems

To understand where a DesignSystem  of an organisation stands in context of implementing a DesOps, first step is to evaluate the existing DesignSystem that is in place and contributes to the organisation’s design process. (We will explore the process aspect in details, in later articles in this series.) To evaluate any DesignSystems  in a broadway we can easily form a metrics that takes care of the following two perspectives on the system.

Designer System Types

Typically the Design Systems can be broadly categorised into 3 types, namely: StaticDynamic and Generative :

Static: Most of the attributes and elements that make this system is mostly static in nature. For example in a Static type Design System, the style guide may be pre-defined print ready reference, defining basic color standards and typography etc. The user has to read through and manually refer it to decide those related attributes in his work. This kind of System mainly prescribes guidelines, rules, principles which does not automatically change or created in a dynamic way either in the stages of creation or implementation by the developers etc. Typical organisational style guides, or UI pattern documentations where the system describes how and where to use the patterns with some sample code to refer are falling under this kind of categories.

Dynamic: This kind of DesignSystem  have the content as well as the principles of implementations are designed and developed in a way that can be directly used in the code. The creation and implementation of the content are dynamic and mostly geared towards the actual elements that can directly be used in the code. This kind of DesignSystem  is more than a reference system for the developer, rather as a part of the actual build of the actual products developed as a part of it. Most easily noticeable traits of this kind of DesignSystem  is that some special purpose frameworks, code libraries are part of it, which integrate into the actual builds of the products.

Generative: Generative DesignSystem  are the ones, which generate the actual build ready outputs that can directly go into the build of the product. For example, instead of a static style guide, a generative DesignSystem  can have the tool that will generate dev-ready HTML, CSS and Java Script based output from the designer/developer inputs. The output of such system, take care of the context for which the design outputs is needed. Let’s say if the developer needs to build a cross platform hybrid app, hen such system can generate the code that will take care of the scenarios for the interaction and behaviour for all target device resolutions, screen density as well as the behaviour for native wrappers as well as in-browser functionalities and restrictions. We will again journey into the details of the Generative Design Systems shortly.

Designer System Maturity 

The other angle to look at the Design Systems is to scale the maturity to measure how much the system has evolved. One of most important aspect of any Design System is to understand the maturity of it, as this helps to understand where it is in the overall DesOpsroadmap. Irrespective of the varied and complex categorisation of the same, we can still name the maturity as Low , Medium and High to get a quick and easy comprehension. And when we try to map the maturity, it takes care of the categorisation aspect.

Low Maturity: When the Design System has a low maturity, it mostly depends on the static attributes that we discussed above. The creation and maintenance of different attributes are mostly the result of manual effort and the most interesting point about this is that the designer and developers have the cognitive load to refer and comprehend and take decisions on what to use and not use in specific context of their work or product. It is also important, there may be some attributes which might have dynamic attributes , but most of them are out of the transition that the design system is having due to its evolution,

Medium Maturity: In the Design Systems  with medium maturity, the most elements and attributes are mainly dynamic in nature. These systems mostly depend on the frameworks, libraries etc. There may be some overlaps in static and well as generative attributes.

High Maturity: Similarly in Higher maturity, apart from the fact that it mostly contains generative attributes, it involves the aspects of automation, computer-vision and may deploy artificial intelligence (AI) to provide continuous pipelines that aspires to remove the human intervention form the process blocks. On ground reality it might require the human intervention to feed in the creative juices or decision power that impacts critical human needs or contexts.

When we map these 2 perspectives horizontally and vertically, we get the the right insight into the DesignSystem’s position in the graph that allows us to clearly understand where the gaps are for the DesignSystem to evolve on which dimensions.

Note that the metrics that govern the success of a DesOps implementation is almost synonymous to this metrics we explored about Design Systems. The factors that adds to this metric on Design Systems,  includes aspect where we measure how impactful the Design System is in touching the different design process lifecycle blocks where each role like an Information Architect or an Interaction Designer , Visual Designer or even the Developer are attached to, in the delivery track. This aspect is more figuratively termed as a Living Design System. 

The Living Design System

The scaling of design is a classic issue. Moreover in recent times the explosive growth of technology across different devices, platforms and ecosystems, it became an ever-growing monster that every designer faces sooner or later. Native (Windows, Android, iOS, Linux etc. ) Web (HTML, HTML5, CSS, CSS3, JavaScript and frameworks etc. ) Along with the combination – the Hybrid – make the scaling of the design language an unending challenge.

The Salesforce design team tried to solve the challenges of applying similar designs across cross-platform product families by introducing a dynamically configurable design asset system which viewed the individual entities of any design system as design tokens.

Technically it was a single JSON file that was the “Single Source of Truth” that contained a set of name-value pairs that defined the properties and their relationships under different categories like text colours, backgrounds, border sizes, font sizes, etc. This JSON was consumed by the framework (i.e. The Lightning Designing System link: https://www.lightningdesignsystem.com/downloads/) developed and templatized for different target platforms, devices, Operating Systems etc. The Lightning Designing System framework generated different formatted outputs for CSS via common CSS preprocessors like Sass, Less and Stylus. Also there was an output in XML format that is supported in Android and JSON for iOS specific development. The Salesforce Design Tokens open-sourced at https://github.com/salesforce-ux/design-system.

The second interesting aspect of this was the use of GitHub to host the design system. Unlike the design system of traditional organisation, where the design system was hosted as downloadable form (even in the cases where the version control like Git is used) these have to be either translated into desired formats for the target platform or hosted especially along with the code. But here the design tokens representing the styles definition and the properties, as hosted on GitHub, were directly integrated into the build process contributing to the Continuous Integration and Development approach of development. In this sense, it was more as a Living System acting a single source of truth, from which the required branch is pulled and be made as a part of the build.

Many other pattern library and/design systems like RedHat’s PatternFlyhttp://www.patternfly.org is also available in similar approach at GitHub (i.e. at https://github.com/patternfly )as that of this second aspect we discussed now. But the idea of making the style guide being available as a SingleSource of truth in combination of this second aspect is what makes the case of the Salesforce design system unique among similar attempts for an approach to deliver a consistent design across different platforms.

(c) 2018, Samir Dash. All rights reserved.

Rediscovering Accessibility for Future Tech!

This is a rediscovery of "Accessibility" in the world of touch-screens and other natural interfaces. With new technology innovation the lines between accessibility technology and Technology for Mass are getting blurred. What used to be a special need is becoming a general need for mass use.Situational Disabilities Use-cases are defining the new age devices, wearable & smart interfaces. High time we need to rediscover on "accessibility" what we think we have already discovered!

This is a rediscovery of “Accessibility” in the world of touch-screens and other natural interfaces. With new technology innovation the lines between accessibility technology and Technology for Mass are getting blurred. What used to be a special need is becoming a general need for mass use.Situational Disabilities Use-cases are defining the new age devices, wearable & smart interfaces.

High time we need to rediscover on “accessibility” what we think we have already discovered!

UX Simplified: Models & Methodologies: Digital Edition [Kindle Edition] ISBN: 978-1-3115-9110-4

My  recent title is available on Kindle for download. This book covers basic models and methodologies that are revolved around User Experience (UX). The discussed topics include User Experience, Information Architecture, User Interface, Usability models, User Centered Design (UCD), User Centered Software Design (UCSD), different Software Lifecycles (SDLC) and how usability models fit into SDLC models.

The details of the book are as follows:

UX Simplified: Models & Methodologies: Digital Edition
by Samir Dash
ISBN: 978-1-3115-9110-4
ASIN: B00LPQ22O0

Kindle Price (US$):$1.87
Kindle Price (INR):Rs. 119.00 includes free international wireless delivery via Amazon Whispernet

http://www.amazon.com/dp/B00LPQ22O0/ref=r_soa_w_d

 

 

UX Simplified: Models & Methodologies: Digital Edition [Kindle Edition] ISBN: 978-1-3115-9110-4
UX Simplified: Models & Methodologies: Digital Edition [Kindle Edition] ISBN: 978-1-3115-9110-4
Major topics included in this book are :

• Why “UX: Simplified”?
o The Diverse Disciplines: The ABCs of UX
o User Experience(UX)
o Information Architecture(IA)
o Interaction Design (IxD)
o User Interface Design (UI)
• Usability and Mental Models: Foundations of UX
o What is Usability?
o System Models
o What is a “Mental Model” exactly?
o Most-likely Mental Model
o Conceptual Model
o Challenges in Usability Measurement and Metrics
o A List of Factors for Generic and Consolidated Usability Model
o Heuristics:Measuring Usability
• Engineering and Design Processes: Usability and User Centric Approach
o Usability Engineering
o User-Centered Systems Design (UCSD)
o Usability Design
o User-Centered Design (UCD)
o Don’t get Confused: UCD vs UCSD
o UCD Models and Process
• Software Development Life Cycle (SDLC): Where and How User Experience Models fit in?
o Software Development Life Cycle (SDLC)
o Waterfall model
o Spiral model
o Iterative Development Model
o Agile development
o Challenges in UX Integration to Different SDLC Models
o Usability Designing Process
o How Usability Design Process Fits in Different Phases of SDLC?
o How UX Fits in Different Models of SDLC?
o Challenges with Agile model of SDLC to implement UX
o Lean UX and Agile Model
• Agile in Usability Design:Without Reference to SDLC
o Usability Designing Process
• Lean UX: Another Agile UX?
o The Beauty of Lean UX: Everything is familiar
o Foundation Stones of Lean UX:
o Lean Startup method: The concept of “Build-Measure-Learn”
o Minimum Viable Product (MVP) – Prototyping at it’s best in Lean Startup Method
o Principles of Lean UX

  • File Size: 1435 KB
  • Print Length: 86 pages
  • Simultaneous Device Usage: Unlimited
  • Sold by: Amazon Digital Services, Inc.
  • Language: English
  • ASIN: B00LPQ22O0

 

Challenges in UX integration with different SDLC models

There are several challenges in integrating UX design and related activities into a typical agile software development life cycle process. The most common problem is typically “ finding a balance between up-front interaction design and integrating interaction design with iterative coding with the aim of delivering working software instead of early design concepts”. This happens mostly because typical pure SDLC approaches primarily aim at “efficient coding tactics together with project management and team organization instead of usability engineering”.As Agile is more “a way of thinking about creating software products’ rather than being a specific process or methodology hints at the challenges of UX integration into it as  integrating user research and UX design with agile, is itself an “agile antipattern”.The very idea of SDLC being a process for developing software , traditionally never kept the “user” into a focus, or event kept any scope for methedologies that try to bring any component that is not considered as native ingredient of the process of creating a software product. The focus was always the “cost, scope, and schedule” that drive any traditional SDLC models including Agile. And sure enough this typically gives rise to the challenges for UX integration into any SDLC as project managers never try to upset the balance of these three by reducing costs, tightening deadlines, and adding features in the specification.

However even though there are many challenges in integrating UX design with agile practices, some researchers see “agile software development practices” as enablers for bringing UX design closer to software engineering and enhancing interaction between these two disciplines.

In Current State of Agile User-Centered Design: A Survey. HCI and Usability for e-Inclusion. Lecture Notes in Computer Science, (by Hussain, Z., Slany, W., and Holzinger, 2009), a survey of the integration of usability and UCD practices with agile methods reported that “the majority of the respondents found that usability and user-centered design practices had brought added value through improvements in the usability and quality of the end product. Development teams often report that they are better able to respond to the needs of the customer with agile methods, and their measured or perceived productivity has been reported to be better than development teams using traditional methods”.

 

Agile development

This is perhaps today’s the most widely used SDLC model. It uses iterative development as a basis ,but uses people-centric viewpoint through user feedbacks rather than planning as the primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

 

 Fig. 1

 

There are many variations of agile processes “:

  1. Agile Data (AD)
  2. Agile Microsoft Solutions Framework (MSF)
  3. Agile Modeling (AM)
  4. Agile Unified Process (AUP)
  5. Dynamic System Development Method (DSDM)
  6. Extreme Programming (XP)
  7. Feature Driven Development (FDD)
  8. Scrum
  9. Usage-Centered Design (UCD)

 

 

Challenges with Agile model of SDLC to implement UX

There are several challenges in implementing UX in Agile model effectively and these challenges include:

  • Different approaches. Usability methodologies are centered on the user and holistic view of the user needs whereas agile methodologies take a broader view and focus on the stakeholder. Agile methods primarily focus on delivering working software early. 
  • Different goals: Software engineers focus on the technical design, implementation the system where as UX practitioners focus on “developing systems so end-users can use them effectively”.
  • Organizational challenges: The agile methodologies focus on strategy where teams are self-organizing whereas UX focuses on a centralized UX groups within some organizations so that the needed practices, tools, and standards can be provided.
  • UX practitioners struggle to be heard: Many UX practitioners often complain that the results of their work are not considered in the design decisions and even if it is heard, there seems to be focus more on engineering decisions over the usability decisions.

Usability Designing Process

While exploring through available scopes in different SDLC models, we can notice a set of common activities which can be combined together to form a generic Usability Designing Process. Basically there are four phases of the whole set of activities which can be tagged separately as follows:

 

1. Plan: This phase involves the following major activities:

  • i. Developing a Plan
  • ii. Assembling a project team
  • iii. Kicking of the project

2. Analyze: This can have the following activities:

  • i. Evaluation of scope
  • ii. Evaluation of existing product (if enhancements are planned)
  • iii. User Research
  • iv. Task Analysis
  • v. Persona Development
  • vi. Scenarios evaluation and prescription
  • vii. Define measurable goals

3. Design: This is phase where some out puts related to the actual product are generated:

  • i. Product/ Site requirement analysis
  • ii. Conducting a content inventory
  • iii. Performing card sorting
  • iv. Information Architecture (IA) formation
  • v. Writing for web
  • vi. Parallel design
  • vii. Wire framing and prototyping
  • viii. Usability Consultations to programming team

4. Test and refinement: This is a phase that can be applied to multiple phases of SDLC as it is mostly about usability testing :

  • i. Usability Testing
  • ii. Heuristic Evaluations
  • iii. Implementation and retest

 

Note that the above phases are not the phases we discussed regarding different SDLC processes. Rather these are the phases that can paired with different phases of SDLC processes depending on the SDLC model used. Typically Usability Designing Process is led by the “usability designer” with the team of field study specialists, user research specialists, usability evaluation specialists, prototype developers, interface designers and graphic designers along with other specialists from related disciplines that varies from project to project.

 

How Usability Design Process Fits in Different Phases of SDLC?

The different blocks of usability design process can be mapped to different process blocks of any SDLC model. The following diagram shows a generic model for typical process blocks for the typical iterative SDLC model.

 

 Fig: 2

 One thing to keep in mind is that process is not a complete product development process as it does not out put the final product at the end of the process cycle. Rather Usability process supplements to any software development life cycle at various stages.

Plan or Ideationand Requirement Analysis Phase: In this phase while the technical feasibility is being evaluated, UCD contributors can assist product management by conducting user research with people in the target market to evaluate target user goals, tasks, and workflow. Requirement analysis phase is also aided by the UCD experts in careful review of the gathered data and preparing metrics that can be used in the development phase.

Design Phase: UCD contributors who are skilled at interaction design, visual design, and information design create mockups or prototypes of portions of the system, and contributors who are trained in usability evaluation assess the designs by subjecting them to usability testing.

Build or Development Phase: UCD contributors are usually called upon in a consultative or interpretive role, meeting with the developers responsible for actual implementation of the product, and providing guidance for underspecified areas of the product. In this phase the UCD contributor’s role is to remain the consistent user advocate throughout the project. When negotiations must happen during design and development of a feature, the UCD contributor reminds the team of the design persona (the “design target”, or user group at which the feature is aimed), helps the product manager identify and weigh the risks of leaving off certain areas of functionality, etc.

Integration and Testing/ Verification Phase:UCD experts help in benchmarking usability tests popularly known as “summative evaluations” that evaluates performance of the system /product developed on several grounds. The metrics of this test is typically based on the “error rate for users as they use the system”, the “time it takes to attain proficiency performing a task”, and the “time it takes to perform a task once proficiency has been attained”.

 

 

(c)2013-14, Samir Dash

Why ‘UX’ is must for software industry?

In software industry , just like any other manufacturing industry the final production of final output step of the whole process of software development is critical as well as expensive. So it became necessary for the different stake holders of the process and the final output to figure out the exact “what” and “how” aspect. To cater these needs new specialties such as “interaction design”, “information architecture” emerge. These new disciplines became the part of software development life cycle gradually after 90s and put an impact on production design process in software industry.

Software industry is itself in a speedy evolving process. So the methodologies used in production design also gradually evolved to match the changing needs of the time. For example the competition in the software product market gave rise to the trend of publishing quick and iterative versions to the market and gradually improvement of the product based on the feedback of the users on the versions available in the market. The agile methodology in the software production process helped changing the process related goals for the developers and designers involved. In the designers process concepts like “Lean UX” has emerged to meet the need of the competitive timelines and “quick to production” demands through agile process.

This is high time we need to see how the “ever evolving” change in production design process can be handled by the designers, developers and information architects through bare minimum effort and learning curve. Understanding of UX is after all is a ‘must’ for those who want a quick fix solution for the changes that happen in the production process and find answers on how to map different UX and IXD concepts to their “ever changing needs” in software production.

(c) 2013-14 , Samir Dash

Don’t get Confused: UCD vs UCSD

In my last posts I discussed about Usability Design and User-Centered Design (UCD) and User-Centered Systems Design (UCSD). But many confuse between these two.  So in the following I am trying to differentiate these two:

UCD vs UCSD

UCD is differs from the UCSD in the following areas:

  1. Goal: The goal of UCSD is more on the process than the user so as to make the final product/system more usable. UCD rather focuses more on “users” of the product and not the design process. More focus is spent on understanding the user and their need.
  2. Process vs. Techniques Set: UCSD is about system development where as UCD is mostly a set of tecniques and process sets to be used with in UCSD 
  3. Perception: The DNA of UCSD is about changing the mindset of the professionals in the development process so that the designing aspect of usability can be put into practice freely and with higher priority. The UCD process is not about the changing perception about the priority of the design in the whole process.
  4. Broadness: UCSD covers the whole process that includes the areas which are even not part of “designing” whereas UCD can be seen as a subset of UCSD focusing of the “design process sets”.

UCD Models and Process

There 3 different models that support UCD in varying degrees and follow the ISO standard Human-Centred Design for interactive systems:

  1. Cooperative Design: This involves designers and users on an equal footing.
  2. Participatory Design (PD): Inspired by Cooperative Design, focusing on the participation of users
  3. Contextual Design:  “Customer-Centered Design” in the actual context, including some ideas from Participatory Design.

All these UCD models involve more or less a set of activities grouped into the following steps  mentioned below:

  1. Planning: in this stage the UCD process is planned and if needed customized. It involves  understanding the business needs and setting up the goals and objectives of the UX activities.  Also forming  the right team for the UX needs and if needed hiring specialties fall into this step.
  2. User data collection and analysis: This step involves data collection through different applicable methodologies such as user interviews, developing personas, conducting scenarios , user-cases and user stories analysis, setting up measurable goals.
  3. Designing and Prototyping : This involves activities like card sorting, conducting IA, wire framing and developing prototyping.
  4. Content writing: this  involves content refinement and writing for web and similar activities.
  5. Usability testing: This involves is a set of activities  of conducting tests and heuristic evaluations and reporting to allow refinement to the product. However Usability Testing can have its set of steps involving similar activities such as planning , Team forming, testing , review and data analysis and reporting.

All these are similar to most of the steps that fall under Usability Design as UCD can be seen as a subset of process with in Usability Design.

So many processes: What is where?

After going through multi relation models in all these processes and sub process discussed in this post and the previously discussed posts,  it might be little confusing to visual all the overlapping and dependable process sets. So here is a simple representation diagram that roughly shows the overlapping relations:

processes-relation