UI/UX Workshop for Startups at SJCIT, Chickballapur, 1st April 2019

Topic: UI/UX Workshop for Startups
Date: 1st April 2019
Venue: SJC Institute of Technology, Chikkaballapur , [P.B.No. 20, B.B.Road, Chickballapur – 562 101]
https://goo.gl/maps/K4gv331xVDQ2 

About the Event: 
UI/UX workshop is organized with an objective to provide students with understanding the value of user experience in product design and to have hands-on exposure to the Product Development process.

I-RICH (Incubation – Research, Innovation and Creativity Hub), New Age Incubation Network promoted by SJC Institute of Technology, Chikkaballapur supported by Department of Innovation and Technology, Govt. of Karnataka and Technology Business Incubator supported by Ministry of MSME, Govt. of India.

 

UPDATES

 

 

 

 

View slides used:
https://www.slideshare.net/MobileWish/session-uxnui-scjit1011apr2019desopsio

 

It was a wonderful experience to be at SJCIT, Chikbalpur and be among the great minds of students who have been selected for their startup ideas. Also, the blessings of the guruji Sri Sri Sri Dr. Nirmalanandanatha Maha Swamiji and the Head of the Department, the professors, and the guides helped in making the workshop a successful one. Also, I would like to thank Nayaz Ahmed,  Head of JUincubator whose help made this event a reality.

Photographs from the workshop: 

     

 

 

 

 

Talk at DesignOps Global Conference 2019 , Manchester, England, 30-31st May 2019

Topic: [TBD – On  DesOps /DesignOps ]
Date: 30/31 May 2019
Venue:  Manchester, England

Super excited to be part of DesignOps Global Conference (www.designops-conference.com) to share ideas with some great minds on hashtagdesignops hashtagdesops hashtagdesign and the future of hashtagdesign from the lens of hashtagopenorg culture and hashtagdesignthinking being applied as the way of life to improve and optimize the operations in the organizations to deliver the “wow” experience, through best utilizing the hashtagprocess and hashtagecosystems and hashtagtechnology in context. Thanks, Peter Fossick. Looking forward to a series of engaging sessions for every hashtagdesigner / hashtagleader.

 

About the Conference:

The DesignOps Global Conference is for design leaders, developers, practitioners, product managers, service innovators and business leaders that are defining the way we design and develop new products and services. Join us Manchester for the DesignOps Global Conference 2019 Agile and Beyond – New Frontiers in Design
30 + 31 May, 2019

The themes for this year’s DesignOps Global Conference are:

  • DAY 1
    • Theme 1: DesignOps and the impact of design
    • Theme 2: Collaborating at speed and scale
  • DAY 2
    • Theme 3: Developing new cultures – developing new organisations
    • Theme 4: DesignOps in the era of AI and cognitive computing

More details of the event and to get the pass visit https://designops-conference.com/

 

 

 

 

 

 

 

 

Talk at RH UI/UX Community of Practice: DesOps 101-Overview

DesOps 101: Overview

 Community Calls 

The talk will focus on overview  DesOps.

Three key takeaways:

  1. Background and overview of DesOps.
  2. The high-level overview of the different dimensions of Design operations
  3. DesOps from Service Design point of view
  4. Samples/Examples
  5. Cultural dimension and Open Org aspect.

Date & Time: 12:AM – 1 PM  on 10 Nov 2018 (IST)
Venue:  Virtual Community call over BlueJeans.

 

 

 

Slides

 

 

 

 

 

 

 

 

[Workshop Deck] PART-1: Applying DesOps in Your Enterprise

[This is the first part of the half-day workshop titled “Applying DesOps in Your Enterprise” I conducted at the “UX India Conference 2018” on 4th October, 2018, Bengaluru. This part focused on ‘Process’ aspect of DesOps, and tried to address the challenges of bringing the designers to the same page to that of diversified subject-matter experts (SMEs) during the ideation phase of an Design Thinking workshop, by collaborating on “Petal Process Diagram”(PPD) . PPD is a mind-mapping kind of activity with the focus to involve all the entities involved in and around a touch-point in a feedback-loop, and helps everyone in the room to be on the same page on the potential possibilities, feasibilities involving “props” and “process” components.

You can explore more at http://desops.io/2018/10/03/workshop-at-ux-india-international-conference-2018-applying-desops-in-your-enterprise/ ]

Continue to the next part of the workshop, in the next post.

Meanwhile, you can explore more here:

https://youtu.be/J5Igx25pj5A

(c) Samir Dash, 2018. All rights reserved. This content including the images are licensed under a Creative Commons Attribution 4.0 International license

 

 

[Slides] DevConf 2018, Bengaluru : DesOps – Prepare Today for Future of Design (2018)

DesignOps is an approach to design inspired by the culture of DevOps. In this session, we will be touching upon the practical approaches on how to prepare for the next wave in design that compliments DevOps in the concepts of the cultural shift, collaboration, and automation. We will also see how to bringing the full circle of design in the context of software development lifecycle.

Topic: DesignOps – the Prepare Today for Future of Design!
Date & Time: 2:15PM – 2:45PM on 5 August 2018
Venue: Christ University – Bengaluru, India

Event: DevConf.in 2018 is the second free annual community conference sponsored by Red Hat for Developers, System admins, DevOps engineers, Testers, Documentation writers and other contributors to open source technologies. It is a platform for the local FOSS community participants to come together and engage in the knowledge sharing through technical talks, workshops, panel discussions, hackathons and such activities.

More info at: http://desops.io/2018/07/04/talk-at-devconf18-designops-prepare-today-for-future-of-design/

Team’s Vicious Circle and Avoiding the Organization Turning into a Pack of Zombies

On the theoretical level, the interaction can be modelled based on various entities like tasks(i.e. activities users perform to reach their goals), dialogues (i.e. interaction between user with users and machines and vice versa ), rules or instructions (i.e collection of behavioural instructions ) and states (i.e. conditions present in the system ) etc. Broadly, the interactions in the team/organization involving communications and sharing among members or more specifically among the roles, though is part of the Process dimension, constitutes the components that are part of the core of Cultural dimension of DesOps.

Basically, this is all about getting answers to two questions that a typical Product Manager or a CEO of the startup has in mind :

  • Do I have the right team?
  • How do my team can be effective in communicating and collaborating at different spheres with different types of entities involved?

In the previous article, I was primarily referring to two levels of the interaction were human-to-machine and machine-to-human and how minimization of the touch-points where the translation of value happens. This is primarily about “consciously and proactively considering the exchanges between people and organizations in the enterprise, and supporting these interactions with automation and tools” (Guenther, Millan Intersection, 2013 ). Solving the challenge to minimize such touch-points are relatively easy, as it involves some aspect of technology and toolchains associated. However, the level which is about human-to-human interaction is the most complex to deal with as it does not have any technology involved in it. In the last article, we slightly touched upon the full-stack roles, that handled some aspects of it. This aspect is more about involving knowledge, skill and expertise attributes of humans involved, and some aspect of it is also involved with human-to-machine & machine-to-human levels, which are partially solved by the redesigning the process involving the technologies. However, the human-to-human interaction is more complex, because it involves the attributes of human emotions, attributes and bias and cognitive fixedness that are counter-productive for any organization heading for disruptive innovation.

Broadly these attributes are part of forming a right set of team, with the right mindset. This is broadly about what kind of team members you should be looking for and also about to implement a set of practices and rules which would help grow each team members towards the self-awareness about there cultural fitment as well as motivate and guide them to grow themselves to overcome their fixed mindsets if any.

Fixed mindsets are the roadblocks to innovation in any organization. The fixedness is part of the human attribute that acts as the vitamin for a pre-defined process oriented no-brainer’s job to bring effectiveness, but at the same time acts as cancer for innovation. Typically, the key types of fixedness that hinder having effective human-to-human interactions in DesOps organization are as follows:

Cognitive Bias: The Cognitive Bias is typically defined as a mistake in reasoning, evaluating, remembering, or another cognitive process, often occurring as a result of holding onto one’s preferences and beliefs regardless of contrary information. The cognitive bias is a kind of fixed mindset that sometimes also manifest itself as a tendency for people to evaluate ambiguous information in a way beneficial to their interests apart from the aspect (popularly known as Confirmation Bias) that induces the tendency to search for or interpret information in a way that confirms his/her preconceptions. This leads to the premature closing down of options in a creative process, as the person affected by this only seeks out the evidence from the information he has that was pertinent to his argument, and remains blind eye purposefully to any other information.

HiPPO effect or Authority Bias: HiPPO (highest paid person’s opinion) is one of the popular terms in the organization-productivity domain. Basically, this is more about having authority biases and the team’s tendency to attribute greater accuracy to someone how holds a higher position in the organization. Beware of the HiPPO (highest paid person’s opinion) in the room as it means that the team has fallen foul of the law of the HiPPO — When a HiPPO is in play, the organization is most likely not relying on data to inform decision-making, rather the HiPPO (highest paid person’s opinion) tends to win out. In large corporate environments, it’s easy to experience it first hand. Usually, when a group of people are trying to make a difficult decision, for which there are lots of opinions, the person in the room who is further up the hierarchy (and therefore typically paid more) expresses what they think and tries to hijack the spirited discussions to steer towards forming an opinion among the team to follow what he thinks and labels it as the team’s decision.

HiPPO effect is the biggest roadblock in interaction aspect of DesOps. If you remember in previous articles of this series I had mentioned how one of the key philosophies of DesOps is to advocate and put a data-driven decision making into practice. HiPPO Effect actually is cancerous to DesOps culture. All the efforts to implement the right process and toolchains as a part of having an effective DesOps in the organization can fail, even only this cancer is still there as a part of the work culture.

Authority Bias is in similar lines with the HiPPO effect, but this may not necessarily about the person who is higher in the organizational hierarchy or paid more, rather it is about the person, who is “seen as experts” or even as an authority in the organization or even in the team. We have an inbuilt tendency to believe those who we perceive as “experts” and usually have a deep-seated duty to authority, and tend to comply when requested by an authority figure.

For example, in typical design or UX team meetings, it is the most difficult situations for young members who are just fresh out of colleges and had to present certain aspects of their solution that are in opposite directions to what the leader of the design team thinks or beliefs. In many cases, these ideas are brushed aside by the authoritarian leader or manager sighting even some frivolous reasons e.g. “it has to improve”, “immature and not practical”, “you need to understand our design process first”, “can’t use that to discuss with stakeholders as it is half-baked design” and so on. And in such cases, most of the “faithful” designers to the leader, echo the leader’s decision and even some start advocacy to explain the logical reasons behind the leader’s reasons. Some may be “yes-men” to the leader consciously, however, some do so as they perceive the leader as the “authority” or “expert” and this allows the authority bias to be successful in killing new ideas and fresh thinkings. In many cases, the member does not realize that they have already fallen prey to such bias.

One of the most famous psychology experiments of all time, known as the Milgram experiment, provides a terrifying example of that a very high proportion of people would fully obey the instructions. Read about this 1961 experiment here: https://en.wikipedia.org/wiki/Milgram_experiment ) and here is a video of that experiment:

 

The Bandwagon Effect is typically a psychological phenomenon in which people do something primarily because other people are doing it, regardless of their own beliefs, which they may ignore or override.

The Herd Mentality The Heard mentality and mob mentality, also lesser known as gang mentality, describes how people can be influenced by their peers to adopt certain behaviours on a largely emotional, rather than rational, basis. Basically, when the Bandwagon effect is blended with the catalysts of emotions, it takes shape of the herd mentality. This is the most negative extreme of the Bandwagon effect.

Also, the Cognitive Bias is more induced by the Herd Mentality as the persons involved turn blind eye to the factual information which can be used for making data-driven decisions. Rather, the persons depend on the emotional ripples for taking decisions and develops a strong Cognitive Bias, thereby contributing to form the Vicious Circle in the team.

(Download the PDF of above at http://desops.io/2018/05/13/infographic-the-vicious-circle-in-teams/ )

The Vicious Circle, refer to complex chains of events that reinforce themselves through a feedback loop, and it is interesting as feedback loop acts as the essential spine for any DesOps organization. The fixedness attributes in persons involved in the team essentially turn the feedback loop into the Vicious Circle that gradually cuts-off the supply of oxygen to the innovation in the organization.

In many cases, HiPPO effect or Authority Bias makes the team meetings ineffective and counter-productive. The members either fall prey to these bias, or they try to avoid conflict in the team and keep themselves safe in the organization by remaining silent (mostly by seeing the large mob of the zombies of these bias in the team. In such situation when some spirited members typically lower in the organizational ladder counter the argument of the upper ladder persons or the leader, the conflict arises, which is in most of the case becomes counter-productive for the team and the organization and becomes suicidal for the those at the lower ladders. Else, the typically the long silence follows in the team meetings when the leader explains his/her idea or viewpoint to a problem (in a tone of judgment in many cases). In both the cases, when it becomes a regular trend that when a leader of the team’s or the ideas or viewpoints from the those who are placed on the upper ladder are praised or unanimously advocated without a few valid questions and some set of team members regularly remain silence, this is a very symptom of the cancer. In another scenario, if the young minds in the team who used to have questions earlier when they had newly joined the team, have no more show any interest in questioning or ask the obvious questions where most probably they do not really need an answer or seems to know the outcome of the questions they asked, that is another alarm for the cancer.

If the team does not have a diverse-voice or the team members mostly ask questions which do not really going to impact those who asked those, and fall in the graph in questioning opinion of the leader in a productive way or some members in the team remaining silent who used to be more creative in the past (and for a long time their opinions were brushed aside and never mattered ) then the team or the organization has already become a totalitarian state and is in a serious condition that requires the fix of the culture.

This is important to remember here, that the foundation of DesOps is based on interaction and collaboration that is productive and supports innovation from grass-roots. In the trueDesOps organization, the ideas flow from bottom to top, like the seed of ideas germinate and grow as plant and gradually through continuous nourishment from the surrounding culture which turns it into a big tree with the fruits of innovation. All the process improvements, toolchain support and the technologies act as the catalyst to support such a culture. Going DesOps is about adapting to change, being flexible, adopt disruptive innovation in a measurable and informed approach. For such eco-system to be successful, it is essential to ensure the work-culture is supportive and provides motivation to the actual people who are part of it.

So where is the way out? One of the fundamental tasks of DesOps, as a Service Designapproach, is to prepare the work culture of the product team for more positive interaction in context to hum-to-human communication and collaboration so as to prepare them for the process changes that might follow up along with the aid of automation and new technologies supporting radically new toolchains. And in such cases, to avoid the team falls prey to fixed mindsets, mostly three steps can be taken:

  1. Choosing the right people with more open personal traits at the time of hiring. During the hiring process, there are many popular psychological tools and methodologies can be employed to avoid personal traits with higher index in the person, which is less willingness to take the risk, or avoid the person too much structured-perosn who is more prone towards process-oriented obedience. The new age innovation in organizations needs the product team with the people with more open and inquisitive mindset — those who have lot of questions in them with passion than the structured minds who always define the box as the red line for him as well as his team members, to play within.
  2. Always keep an eye on symptoms of Vicious circle getting formed within the team or organization. Mostly it starts with the persons who are at the top of the ladders. And the most commonly it starts with HiPPO effect. Evaluate internally if there is any change in the behaviour of the team during meetings — try to find answers to question like “Has the spirit of some members have changed?”, “Is there fewer questions in meetings and especially fewer questions to the people at a higher hierarchy? “, “Has the agreements to the top leaders’ views have increased without much discussions over last few meetings?” “Has some set of members are regularly putting up silence since a period whenever the leader of the team or people on the higher ladder is throwing the ideas?” “Has there been an increase in rejection of ideas from the grassroots ?” — These will help in forming the timely suspicion to avoid the Vicious Circle. Note, that these may seem like addon work, but this timely diagnosis is worth it, as it helps to ensure that the organization is not got cancer at its’s brain and heart.
  3. Another key aspect is to bust fixed mindset is to enable un-learning. The systematic un-learning is a key to fixedness that is more functional or structural in nature. Unlearning helps in fostering a sense of willingness that helps in opening up minds. Especially this is effective as well as critical to have the managers and the members of the top hierarchy, to develop a sense of willingness to unlearn and learn something new. Unlearning helps to put team members out of their comfort zones so that they are more willing to pursue the unfamiliar and fosters curiosity.

We will be exploring these in details in forthcoming articles of the series. Be in touch, and do not forget to share this post.

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

[Originally published on May 14, 2018 at https://www.linkedin.com/pulse/desops-next-wave-design-part-12-teams-vicious-circle-avoiding-dash/]

 

Infographic: The Vicious Circle in Teams

Download the PDF version here: https://www.slideshare.net/MobileWish/infographic-the-vicious-circle-in-teams-desops

Read related article here: https://www.linkedin.com/pulse/desops-next-wave-design-part-12-teams-vicious-circle-avoiding-dash/

©2018,”Infographic: The Vicious Circle in Teams” by Samir Dash.
Creative Commons Attribution-Share Alike 4.0 International License

Translating Value at Different Stages of Design with Minimal Waste

In 1967 Ronald Barthe published Elements of Semiology, which stands as a temporal marker of post-structuralism, where he gave rise to the idea of “Meta Language”, which in fact “beyond language” or “Second-order language” which is used to describe, explain or interpret a “First order language”. Each order of language implicitly relies on a metalanguage by which it is explained. And it is obvious that the translations between the first order and the second order never loss-less and the true meaning of the first order language is lost or deteriorates when it is represented in “Second-order language”. Design process involving multiple intersections of information communication and sharing through translation of the value (e.g. vision, idea), loses its original meaning while being translated through different tools into various forms of expressions. Also, the different roles (e.g. Product stakeholder or product manager, information architect, interaction designer, visual designer, prototyper and developer etc. ) contribute to the infinite regression of “meaning” of the value.

That’s why one of the key factors that working with developers in terms of the realization of the design has always been a big pain and non-stop iterations, and this turning in favour of the term Full-stack Designer that shares the same spirits as that of the term Full-stack Developer.

(Download PDF from http://desops.io/2018/05/10/infographic-the-full-stack-roles-in-desops/ )

Typically the phrase “full-stack” (or full-stack developer) refers to someone who is someone comfortable and could single-handedly tackle every layer of software development. Typically DevOps engineers and full-stack developers share the same philosophical traits — they strive for greater agility and flexibility and hint at a trend towards greater generalization in the skillset of technical professionals. In case of the full-stack designer, he grows into a cross-disciplinary professional who can handle across Interaction Design, Visual Design as well as UI Development or prototyping. This helps to reduce the gaps between the outputs from these different and the effort that goes into the translation of concept flowing from one stage to another, where there are many roles assigned to more than one persons are involved (And remember that one of the key principles of DesOps is to remove waste by applying practices like Lean models).

So if we see that one of the major focus of DesOps in this aspect involving the work-culture is to reduce the gaps between the roles and wastage thereby. The translation from one role and discipline to another makes the meaning second-hand interpretation and such process is never loss-less. Something or the other gets lost in translation, as we progress towards the realization of the value or the product.

So by implementing Lean methodologies and by striving towards having minimally sized team members with as diversified expertized to help to minimize the intersections or touch points among disciplines and roles where the translation happens. In short less need to translate the value, the less information gets lost and less is the waste in terms of value, effort, cost and time.

Going “full-stack” is one approach to avoid the waste that happens in the process that Barthe has termed as indefinite regression or Aporia . This is mostly from the roles perspective. The other approach is through process or work practices redesign to reduce the number of intersections where the translation happens. In the context of DesOps, this is significant, as it involves the interactions at various levels between the primary two entities i.e. human (i.e.people or user ) and machine, namely — from human-to-human, human-to-machine, machine-to-human and machine-to-machine.

So one of the key factors involved while implementing the DesOps in the organization is to look for process re-design to “minimize the touch points of interaction” through the principle that advocates to minimize the gaps between the roles.

Sometime back, I was evaluating some of the design systems and tools available to study the pain-points while transitioning the design concept from one tool to another and moving from one role to the other. I got in touch with many of my friends who were designers by profession in different enterprises and were at different levels of comforts with existing design and wireframing toolsets, starting from Adobe Suite to the Sketch based eco-systems. Based on the discussions, the interesting thing that I found was many of the tools being used at different organizations, are selected based on the pricing and what the team is comfortable working with, rather than with a focus to have a seamless workflow. In many cases, the cost played a bigger role and due to licence cost, some had switched from most popular design tools to the cheaper replacements. However, the biggest struggle that was there was never solved i.e. the iterations in the design process remained challenging despite the change in tools. Every change in design aspect that was iterated was facing the overshoot of the effort, time and cost. The transitions of value from one set of tool to the other e.g. the quick wireframe created in Powerpoint during the stakeholder workshops were being translated into Photoshop was actually about relooking at the layout due to the constraint that popped up while working with the specific widgets in a specific resolution that never went well the wireframe concept. In one organization, the team replaced the Powerpoint with Sketch and tried to use that to complete the process, which turned into a nightmare as the sessions ended with the people struggling with the tool.

In search of a tool that can minimize the translations of values, I was toying with an idea of Ditto, a simplified version of the tool that can look familiar to the different roles involved in the process and at the same time it will align with a process that is about having the same source files at any of the stages of the process and can align with any design system with easy configuration mechanism.

(Figure : The common pain-points in typical Design-process  )

 

(Figure : Typical Design process based on various touch-points where translation happens )

Ditto is a conceptual vision of a design tool that uses UI pattern Library (which is configurable ) and understands the relationships among the components of the design system configured to create and maintain its own objects that can be rendered on a super simple easy-to-follow and familiar looking interface with drag and drop kind interactions enabling the users of different role to focus on their goal rather than figuring out how to use the tool. Conceptually Ditto was capable of taking any type of inputs and exporting different types of outputs on demand e.g. the wireframes, visual comps and ready to deploy UI coded with HTML/ CSS/JS.

(Figure : The conceptual solution, Ditto is based on a “Single-Source” based process )

(Figure : The conceptual solution, Ditto  is based on a “Seamless Workflow” based process )

 

Watch a video demo that elaborates the concept in context to these use-cases —

The benefit of such a tool would be to reduce the critical – dependency on any particular role in the team in order to carry out with the project. For example, assuming a startup is only having a visionary guy with a developer, he can go into the tool to drag-drop few shapes and objects in a traditional Powerpoint / Keynote kind of interface which he is familiar with and export that as a barebone interactive code/prototype that can be tested. He can continuously test and get feedback, based on which he can tweak the same source and iterate. His developer friend can use the same source to export the code in a click to use in the production. And interestingly if he makes any change, that would be updated back to the same source. Later if a visual designer’s help is taken to customize the look and feel, it would allow updating the same source that’s running in the production where the necessary changes to the code will be managed by Ditto in the background. And despite the fact that the visual designer modified the source, (which affects the internal code) he is doing that in a Photoshop kind of environment familiar to him.

If we look at this “Single Source Based Design Eco-System“, any role can enter and come out with a production-ready code, be it a product owner or CEO of the startup, or an interaction designer, visual designer or a UI developer.

The benefits of such a tool are many:

  • Seamless work-flow for Design – Developer collaboration
  • Saving on license cost as no longer it is required to use multiple design tools
  • Single source makes it maintainable.
  • The omini-change process ensures that any changes happening at any stage of design stage will automatically take effect on other stage deliverables. (i.e. assuming at if UI html code is tweaked, it will also reflect in wireframe and visual design stages without any extra manual work!)
  • Zero learning-curve
  • Single user – Single Tool: makes it easy for any of the roles can login and generate implementation ready UI output.
  • Significantly reduces Cosmetic / UI compliance issues
  • Significantly reduces the time to implementation of the design concepts
  • Boon for Agile projects where the changes are common.

Some of the components of the conceptual design tool Ditto, you might have noticed are already available in some of the design tools. For example, similar in Sketch, you can create a custom pattern library theme and use drag and drop to add them while you are designing. But, its more about customizing themes based on existing ones and exporting shapes specific CSS at the end, which is at a very lower level of maturity from a design system standpoint. Similarly, exporting existing design to HTML feature from Adobe’s Creative Cloud Extract in some sense does not take account into how certain design systems of high maturity can be fit into it so that the output can have functional interactions as a part of business flow for the UI.

But certainly, Bootstrap Studio is much closer to the concept of Ditto. It can be improved around the areas configurations and there is a need to move away from the traditional Application type UI and interaction layer so that it can align to one of the core attributes i.e. to make each user role feel familiar with the interface or rather making it easy to follow. The UI widget based WordPress-page builder tools like Elementor are closer in this regard. While talking about Eco-Systems the tools and technologies, I will write about what are the tool-chains that we can combine for different levels of DesOps implementation looking at the maturity levels of Design Systems in play in the organizations.

Well, the thoughts presented above is a practical example of conceptualizing a value communication using improvements in processes and using technology to applying regression to the touch points where the translation happens, and thereby reducing waste and avoiding loss of meaning of value throughout the design process. We will explore the aspect of communication aspect of human-to-human, that is an important part of DesOps culture. Stay tuned.

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

(This article is originally published at on May 12, 2018 at  https://www.linkedin.com/pulse/desops-next-wave-design-part-11-translating-value-different-dash/ )

The Evolution of Technology in the Context of Software Development & Design Process: Take-away from the First PatternFly Conference

[This post was originally published on Red Hat Developers, the community to learn, code, and share faster. To read the original post, click here.]

Last Sunday, I returned home, India, after attending a series of collaborative sessions in Raleigh, NC, with many designers and developers across Red Hat and the open-source community, at the UX Summit and the PatternFly Conference. The whole experience was inspiring, informative and at the same time thought provoking with many takeaways, out of which the most interesting for me was that cumulatively all the inspiring talks from the speakers of the conference were implicitly hinting towards a clue. How our attempt to solve the existing technical solutions also impact the existing work process and thereby demand a rethink on the process blocks we use.

Being part of the Red Hat UX Design team, it is always an exploration and giving value to the core principle of “being open” to the “Design” — this is something similar to how the “openness” is seen as the integral value of the “Development”.

“We approach user experience design in the same way we develop our products. It’s all about being open.”

– Jim Whitehurst, CEO & President, Red Hat

So, what’s so special about the design being open? Is it something different from how we design in a traditional enterprise organization? It’s natural to have such questions when we face the open paradigm of the design challenges — I had similar questions. One thing to note here is that designing for open-source has its own challenges that require a re-look at the existing design processes and frameworks especially in the software development scenarios that have been evolving over last two decades. With the focus to bring the user-centric focus to the existing sets of Software Development Life Cycle (SDLC) — these were mostly about advocating Human Factors in the perspective through which we have been used to see SDLC.

But as day-by-day major enterprises are going open-source to bring more and more collaboration with the community to develop the software, the open-source movement itself is getting mature by gradual evolution through different seasonings in the context of the growth of technology and the changing market needs that are driving shaping the SDLCs. For example with the rise of startups in last few years, the adoption of MVP-driven Lean Development models instead of traditional SDLCs has increased indicating the evolving dynamics of adoption of such processes.

In the traditional enterprise, the design process is more or less influenced by standard UX approaches that have evolved over the last couple of decades. Taking into account the SDLC defined towards the end goal of the organization in context to the user experience related benchmarks. Many take different components/tools and methodologies from the Design Thinking and other similar HCI process models, and align them into the SDLC, be it agile, waterfall or hybrid, and try to achieve the user-centered software development (UCSD) from an engineering point of view.

There are sects of organizations, who take into account the user needs related benchmark and make the existing SDLC components to align to that — be it through User-Centered Design (UCD) approach blended with a part of Iterative, Agile or Lean SDLC models or simply following a ready made Lean UX model. While everyone is attempting to solve the UX equation to come up with the best possible framework that works great in advocating user needs, the question is still unsolved — what UX approach works best in a diversified collaborative open-source culture?

In the very first PatternFly conference held on 8th of this month, in his keynote, Michael Tiemann, VP of Open-source Affairs at Red Hat, referred to continuous evolution in the software development domain in context to design. His expressed views, which resonated more with the belief that the sustainable design solution can evolve from an organic design process, where reusability can play an important role.

(Michael Tiemann, Vice President of Open Source Affairs at Red Hat, delivering the keynote at the very first PatternFly Conference at Red Hat Annex, Raleigh on 8th June 2017)

The PatternFly community project supported by Red Hat is an attempt in such a direction that promotes “design commonality and improved user experience”. Dana’s blog post, Are “Web Components” in the future for PatternFly?, is an interesting read in this context from a technical angle where he addresses the thoughts on building a UI framework when there are so many choices and so many strong feelings about the different choices? While every organization is still trying to find the solutions for challenges related to UI development for a better experience such as – how to structure and organize CSS code for reusability in the ever-growing complex world of UI framework choices like Bootstrap, Angular & React etc. It’s also important not to forget that with each adoption of UI framework the impact on how we implement experiences to our products is also evolving, thereby making an impact to the process blocks that run the design, and development testing phases of SDLC.

This leads us to the hypothesis that with the evolution of newer technology adoptions, we are bringing the change catalysts to our development process, which can influence how we conceptualize and deliver the best experience for any product we are building. Along with it, as SDLCs are now getting re-shaped due to needs like, “faster time to market” and to bring out more sustainable solutions for the business needs, so is the associated stages of “Design”, “Development” and “Testing”. These are also getting more mature through the focus on Continuous Integration (CI) and Continuous Delivery (CD); thereby bringing a sea of change to the way software was planned, designed, developed, and tested traditionally. To this model when we add the “Open” aspect that demands the need to improve the process dynamics in order to ensure the end-to-end software delivery is sustainable in coming times. Red Hat’s recent open initiative to announce OpenShift.io is an attempt that tries to address all these aspects, at least it is a “start” where we start re-thinking openly about the solution that we thought we already have.

Openshift.io as an end-to-end development platform tries to address multiple areas or the process blocks like Planning, Analysis, and Creation, that tries to answer one question – what is the best way to deliver a software product in the most effective, seamless and consistent way in a diversified work-culture with value and best experience possible. It would be interesting to see how this platform evolves in coming times with the support and collaborative effort from the open source community to address these process related change catalysts that are getting their way into the work practices due to an ever growing complexity of technology change.

In the forthcoming posts, I will be exploring this context with respect to existing UX models and methodologies try to reflect thoughts on “UX in the Open “. Stay tuned.

(c) 2017,  Samir Dash. All rights reserved

Lean Methodologies & Hypothesis-Driven Design (HDD)

The second life-line as pointed out in the dimension of ‘Culture’ is “Cultural Shift towards Lean Philosophies” (Refer the part 5 of the current series here https://www.linkedin.com/pulse/desops-next-wave-design-part-5-definition-3-dimensions-samir-dash/ ). In this part of the series, we will be deep diving for the same.

Typically any lean methodologies are based two basic goals:

  1. Helping the organization understanding customer value
  2. Using the key processes of the organization to continuously increase it and work towards delivering a perfect value to the customer through a perfect value creation process with zero waste.

In the context of Design and User Experience(UX), in the seminal book Lean UX by Jeff Gothelf, provides some lean methodologies break the stalemate between the speed of Agile and the need for design in product development lifecycle” [Jeff Gothelf and Josh Seidenjeff, The Lean UX]. If we observe closely, the basic foundations of Lean UX prescribed are common to the core Lean philosophies, namely:

  1. Remove Wastage from Design Process — Moving away from heavy documentation to a process that creates artefacts which can be directly used in the design and development lifecycle itself.
  2. Cross-functional Collaboration — All the stakeholders from any parts of the product lifecycle including the designer, developers, quality experts, analysts, marketers and end-users all collaborate in a transparent and productive way.
  3. Experimentation Based Iterative Execution — So fundamentally it alludes to the UCD core principles, that assumes that the designer (or the team) learns from the execution of the prototypes in an iterative cycle that starts early in the product lifecycle, from which the learning is used as an input to improve the product along the way. If you notice this is the very basis of what we talked about the continuous and integrated feedback loop.

The use of Agile and Design Thinking practices can be seen alluding to the philosophies above. However, regarding the third philosophy — to ensure that the designer has the right approach to conduct the experimentation so that the feedback can be used in a productive way to take informative decision making along the way across the design process requires some non-ambiguous methodologies that can help the designer making some assumption and validate that through experimentation. This is the basis of one of the core foundations of Lean UX and related lean methodologies, which is popularly known as Hypothesis-Driven Design (HDD). As any design that we produce is based on certain assumption and HDD provides the non-ambiguous approach to the same, that follows the third philosophy i.e. Experimentation Based Iterative Execution.

“Declaring assumptions is the first step, in Lean UX process” [Jeff Gothelf and Josh Seidenjeff, The Lean UX] . This statement reflects how the assumptions or the hypothesis is the core the Lean UX principles. Basically, the four steps in the Lean UX approach is the same blocks that appear while in HDD, and can be mapped to the following blocks:

  1. Making Assumption / Formation of Hypothesis
  2. Build a Prototype / Minimum Viable Product (MVP)
  3. Execute / Run the Prototype
  4. Get Feedback / Observation

Now step 4 is the feedback loop that connects to step 1 making a cycle, thereby using the feedback from current iteration as the input to form the assumption for the next iteration.

Interestingly this means the HDD process always depends on outcomes rather than traditional outputs of any traditional process. The outcomes are kind of hints from the segment that can give direction to the design along the way and help in getting incremental validation of the vision by acting as “evidence” or the and more precisely they are the factors that help in “course correction” for the design. As the outcomes of the assumption act as pieces of evidence, it helps in making data-driven decisions.

You may ask, does that mean the design is reduced to quantitative factors which will act as evidence to support some of the designs? Now, here is the interesting aspect that helps to understand the approach — the feedback or the evidence can be either quantitative or qualitative in nature. And to avoid the risk of being limited to measurement-driven design, the qualitative perspective is provided equal footing in HDD approach. This makes a fit case for DesOps that can help in converging the technology with this philosophy to form required service design solution powered by machine learning, artificial intelligence and automation. The aspect of the actual implementation using technology is what we will be exploring in coming articles of this series, mostly while discussing the third dimension i.e. technology.

The very first step in HDD, i.e. “Making Assumption / Formation of Hypothesis” involves articulation of the assumption or the hypothesis. And this is the most important aspect of HDD, as the other steps depend on this. Typical hypothesis statement can be framed as per the following simplest form —

I think doing [this] will result in [that ].

There multiple variations to this that many professionals use in their area for HDD based research and design /development activities. Some add the factors such as the segment or the persona or the end user of the product, something like the following —

For [user / him/her ] I think doing [this] will result in [that ].

If you see the above keeps segment in a context that helps it keep focused on to specific persona, which thereby can lead to the user-centred design process. This is essentially labelled by many as a design hypothesis.

Some use additional factors of forming negation of the hypothesis by adding an attribute like whether this hypothesis is believed by him as true or false. To formulate a null hypothesis and thereby move on to define an alternate hypothesis (which is essentially a negation to the null hypothesis one craves to validate, but due to nature and structure or any metrics associated with that, it may not practically be possible to achieve that. So in such kind of cases the implicitly the state of belief is presented as another factor to take part in the validation process —

Because I think [this] is true, I think doing [this] will result in [that ].

I believe that any hypothesis statement can be cultivated from the bare-bones model of cause and effect being rendered as a formalized statement of “if …. then” or “when … then” kind of format. At least this gives a more practical approach to build a real-world HDD based system which is technically feasible and is the essence of any DesOps system.

The next important aspect in this regard is how to ensure that we are considering the qualitative aspect of the evidence, as discussed above. If we look at irrespective of the fact that there is a crowd of applications out there which claims to support the business through a data-informed approached, they are primarily a set of some variation between the extremes like A/B testing tools and data-driven analytics and data modelling based prediction systems. But if we notice with care at the core of HDD we found that the essence of HDD lies in making sense of the data and treat it as evidence so as to inject it to a UCD based process to fuel design or business decisions. Though coming up with a real-world HDD system would require similar tools and technologies of data-driven systems, but they will be supporting components to HDD based system. In this regard, the real HDD based full fledged system is literally non-existent as of today, while I am writing this article. In regards to DesOps, this makes a lot of difference, as most of the HDD frameworks out there are not 100% autonomous. Most of the implementation of HDD is mostly based on the work practices and methodologies, which is implemented depending on the need and feasibility. However, these are good enough when we use these, in context to the tools we gain from UCD, Lean models and the Design Thinking principles. But, it is interesting that the philosophies of DesOps, take it to the next level, making it autonomous and integrated with the over-arching feedback loop we have been referring many times.

To be continued… Keep tuned in.

 

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