Process A to Process B

Recently, i went into some trouble. Not for some design that i have done but design someone else has done. Yet i'm responsible, (which is something, i would like to discuss more later).

A vital process did not get executed, but was not known until months passed. Process so important, once a min owe thing has gone in to proportions, needless to say putting me in great trouble. 

My CEO taught me and/or reminded me something, that i would like to keep in mind rest of my career. Processes are sequential which means one depends on another to finish to start-up. this is a continuous process which ends when either meeting the target or ended up in error and terminates. 

What should be happened in between two processes, where one is taking control from the previous one. One thing and one thing only, it should pass the ownership. previous owner should make sure it has passed to the next with confidence of completing successfully its objective and current owner should make sure that he received the control with no strings attached, another words no errors or issues been inherited.

Suppose there are errors in one process, rather progress with hiccups, inaccuracy and inefficiently, it would stop just limiting the situation to mere convenience rather than to a cut-throat blame game and data corrections. worse things could happen to a designer.

let me summarize you in simple graphical format.

Requirements 1-0

We rely on requirements have our designs. Designs are results of processed requirements. that it self shows the dependency our designs relies on requirements. 

so undoubtedly, requirement gathering is the most difficult aspect of software development. Every other stage in development cycle is made difficult by our actions. Specialty of requirement gathering is it contain elements of surprise or/and actions goes beyond your control.

No one is supposed to collect the all the requirements or in a perfect way and it is not human nature to achieve such good results.

But there is one thing that we all can follow on with respect to requirements. Irrespective of whether they turn up to your face before, during or after the cut off date, there could be only two statuses. 0 and 1. 1, you know about it or 0, you don't.

now not hard as it looks right, but it gives you the base line for next course of actions. how do you identify it is either 0 or 1, is just being thorough with the requirements you have collected like no one including the very people gave you the details, should be able doubt you.

biggest danger or risk, a designer would mount on is, developing a doubt about your own work. once let that come to you, everything else would be easily be fallen apart.

Thing for humans

human interface design is a hot topic going around.it makes sense we are making systems for humans.but considering different nature each human posseses,big question remain as how can we generalise all to single interface that to serve all.
now i think it lies on the experience and mainly it is domain specific. in more detail, the right interface for a system depends on the ability and likeliness of the members of the organisation to "mingle" with the system. that depends on the capability and desire the members and as an organisation drives on.
see it is not always easy to address things bases
d on generalised term, things needs some tweaking titching once in a while

Designing for internal & external

Recently, I was to undertake a project more like a mini one which involves dealing with your internal organisation structure and external parties as well.
Now, reason for this thing to be special, i must say, is i had to treat my internal correspondence to a level of external due to standards they are following. Argument over the standards, keep it aside for a while, but this exercise has taught me some good lessons in understanding the approach needed in advance.
You have to have a design in mind even you are deal with ones inside the organisation. You are portraying your self as the custodian thus requires you to be concrete on your design.
so when we approach for designing, it is required to remember the outlook you should be portraying to your internal organisation structure and to the outsiders.

Connectivity between IT and Business

What would system and interface design has to do anything with connectivity between the IT and business ? it has a lot to do with it. Interface and system design is for the business, developed by the IT. so it is all about the connectivity when deriving at the perfect design. it is a well understood reality in world of TI, where either you tell the customer to do or you do what customer asks. Both instances have worked in the IT industry, which makes both are good approaches provided the best strategy is adopted.

Following are some of the ideas, that one could employ in achieving the success of design implementation.

1. Strategy for both IT and business should be similar and shared. it is imperative that, when both the parties quest for the same goal, shared and similar resources, actions, methods etc etc are the keys success.

2. IT and Business should talk in same language, which means, both should understand that what they are deciding on, act on and implement on.

3. No two humans can achieve their heart desires at the same time. there is no change for the world of IT, where both the IT and Business must willingly, compromise and collaborate.

4.Alignment and understanding in execution of planning, structuring and implementing of the project as a whole is a must. This whole execution process is a collection of resources which supplies the skills, communication, negotiation etc.

Process behind Process -1

Designing the correct interface and system itself is a process. The quality and effectiveness of the process some what determines the quality of the outcome. There are many aspects and theories which enable one to equip to handle the matter, which i will not take in part to discuss since it does not support the purpose of this blog. Yet I would like to point out few points in high level to be considerate.

1. Team work with communication.

    Team work is almost nothing with proper communication among the members.

2. Visualization

    Effort should be followed by the imagination and understanding of the outcome. it helps to improve the 

    outcome and proper management of the outcome.

Collaboration, Execution and Success

Interface and system design and their importance depends on the involvement of user groups and the influence of the existing market and social conditions. That engulfs the real necessity of identifying the required conditions in order to develop and implement an interface and system design which will optimize the activities of the system as well as the users.

I consider two pre-conditions that would allow an interface or a system control to be successful.

1. There should be constant and effective interaction between, marketing, engineering, research, technology 

    and business. All the groups mentioned are stakeholders of any system, which is deployed to benefit their 

    processes.

2. Commitment and support of the leadership of the organization is required in order to make sure their 

    wishes are with the process otherwise much needed support in terms of finance and nod "got for it".

First and Foremost contd..

Imagine a process where a third party provides you the data, a function in the native system process those and display the details. As a matter of fact, user does not have a much of a saying to the three parts mentioned. So how are we going to establish the confidence ?

Since we have designed it, we dictate the users to accept the result as valid and trust worthy. As long as IT says and takes the responsibility and be in sight, users will wok on it. But they have not taken the responsibility and whole process will be a cat and mouse race.

Instead, we improve the visibility, users see what is been uploaded, and what are the output of the process. Any error in the will be pointed out by user, even though will be little embarrassing for the IT, yet users are tempted to get the ownership of the process and be leads.

Rather than, hiding the details we have opened them up, so that the system will be a users' and not of IT.

First and foremost

The first and foremost step when it comes to interface design, is the confidence building. it is the confidence that users' affection is decided upon. Systems are designed to execute a process where a user intended to do so. Connection with the system grows if the user has the confidence in the system, that as the end result, anticipated result is achieved.
Confidence is improved on two aspects.
1. Extended usage and time proven
2. Transparency

Clearly the first one takes time and current context does not give you that much of a flexibility. So we are left with the second option, transparency.
How we are going to improve the transparency ? Better way to answer and realize the question, is to understand why transparency matter when comes to building the user confidence. Now let us see that shall we ?

Begining ....!

I was not sure about anything, when i have started my career as a developer in 2005. After spending 5 years of my life, I have started to like, somethings about Software engineering. What caught my attention was system design and its applicability and capability to adopt and change a system which users are made to fall in love with.

Systems should be with users, not with developers. Since developers have to create systems for users, it is developers has to leap forward and design systems for users, so that systems will last long to serve.

This is an effort to share thoughts and ideas from my side, for better and improved system designing, more like human interface design.