Design & Small and Medium Enterprises

I've spent the last 5 years of my career meeting end users, customers in Small and Medium Enterprises (SME) - trying to understand their work practices, challenges, pain points and opportunities on how to make (some) things in their working life simpler with IT enabled (software) solutions

The SME segment is extremely diverse compared to other segments. This raises more 'design challenges' while designing for the peculiarities of SMEs.

• It is very hard to make any clear 'assumptions' to generalize and form a picture of a 'typical' SME company. There are lots of "ifs" and "buts" involved.
• There is a BIG difference between the smaller sized companies versus the medium sized companies under the broad SME category.
• There needs to be further 'sub-classifications' to be able to have a slightly better focus and understanding - to be able to make some high level presumptions and assumptions
• From a 'user group' perspective the diversity spans:
• Organizational Structures & user roles: What the company does; the reach of the company has a direct implication on how the 'end users' in the company work - is it a very distributed set up versus people doing multiple tasks; which function works under which department; who has decision making authority and who doesnt etc.
• User demographics; mental models and expectations:
• There are SME started by some young, 'new age' entreprenuers and
• seeks contemporary, heavily IT enabled solutions
• is extremely demanding with aspects like ease of use; mobility; aesthetics; networking and interoperability etc.
• their benchmarks and mental models are 'consumer software products'
• extremely well versed with all things on the internet; new technological trends etc
• young workforce
• ambitious - wanting to increase their company's reach as much as possible
• early adopters of solutions from contemporary companies
• there are established SME in business since the 'pre-IT boom' era.
• established brand in their respective domain
• established customer base
• working with older systems, battling integration/ interoperability issues, lesser 'digitization', work a lot with paper
• has an relatively older workforce
• their mental models are 'desktop' based software
• new age technology would be too disruptive - however harbors the desire to eventually make the shift to more contemporary solutions. would resort to 'trusted' partners in helping them to do so.
• A large number of SME tend to be extremely 'local' - from the language they are comfortable with to the processes and regulations they follow. An overly 'standardized' solution with a whole lot of options to 'customize' is likely to not do so well. Its easier for them to make an invesment building an 'in-house' software that does exactly what they want (it feels a lot more 'personal'); rather than the effort of  making a BIG software work for them (perceived to be 'alien'/ not designed keeping them in mind).

Irrespective of the type of SME, I observe this segment to be a very 'demanding' and 'unforgiving' one.

• Is in the in the 'middle' and aspires to be big. Hence needs the scalability and flexibility to be able to adapt to changing markets and their own evolution.
• Is highly cost conscious hence is uncompromising on 'value' - price, features, all encompassing quality, do not want to pay for things they do not need, want solutions fast, do not want to invest in huge extensive trainings. 
• While they desire to leverage higher IT enabled services and solutions, they tend to have smaller IT departments. Hence the IT services need to be 'hasslefree'  
• Since there are plenty of solution providers in the field, they are often not starved for options. There is a lot of competition among small solution providers who give very good solutions to focussed business functions.

Given the diversity in SME I have experienced, perhaps the above points also do not do justice to it. I am still learning and gaining insight into this segment of the market - insights that have implications on how a solution needs to be defined, developed and sold in this segment.

So what sort of 'design implications' would these have?

• In my perspective, the solutions need to be more 'specific' than we think.
• Pushing concepts like 'social networking' and 'web services' to an SME that works with legacy systems, has a high level of paper based processes, an older workforce would be very inefficient.
• Pushing collaboration tools to an SME that is extremely local, works out of one location, small departments, would be an overkill. It would be a lot easier, cost effective and efficient for them to talk with their colleagues directly.
• If the approach is to build a 'standard' software for the segment, perhaps the pricing options need to be far more detailed that we think. Almost at a 'feature' level - somewhat like choosing to have a cup holder and automatic climate control while ordering a car :)  - or provide some 'package' options (again like car dealers do) The user really picks and pays for JUST what they want to use but be able to upgrade as and when they need to.
• Providing flexibility to users without overwhelming them
• On an emotional level, I feel the software solution needs to give the impression of being 'hand-crafted' for them instead of demanding them to make changes in their organization to fit the software.

whoever said, "only C users need dashboards" was wrong!!

(C user = casul user - someone who is typically in the senior management cadre and personally uses software applications occassionly. most often has an assistant doing the tasks for them).

I am no 'C' user.
I am a regular employee within a user experience team, in the role of defining user interface concepts for a product. The requirements of these could come from different functional areas; result of some customer complaints; technical enhancements; user needs etc. However each of this source is stored in a DIFFERENT location and format. NONE of them talk to each other.

I am desperate to have a dashboard. At the least something like an iGoogle that allows me to PULL information from these different sources to ONE page. As a 'designer' it would be extremely helpful for me to see all of these information placed together - to infer from them; SYNTHESISE them and come up with a rounded/holistic design proposal.

> enabling design thinking demands having 'infrastructure' in place to work efficiently...and spend quality time doing 'core' tasks.

humm! so do UX definitions get a update??

I came across Daniel Kahneman's talk in TED2010 about The riddle of experience vs. memory.
An extremely insightful talk indeed. It all makes so much sense.

I also chanced upon a write up about this talk in Frog designmind: 
It is intriguing to think about the implications of Kahneman’s model for policy-making, business, and also design, especially with regards to product and service experiences. If designers followed Kahneman’s theory, they would design user experiences not only for the Experiencing Self but also for the Remembering Self, which puts experiences into perspective by inferring and deferring. You could also say: the Experiencing Self values usability; the Remembering Self attaches itself to a brand. Users are usually happy when the Remembering Self finds out that its anticipated memories (brand promise) match the Experience Self (user experience). Great brands connect the Remembering Self with the Experiencing Self to make consumers happy, inspire behavior change, and make the world a better place – not a simple feat.

I cant agree more to this. So many of us have made an almost invisible behavioral change from emailing, sending egreetings, snail mail to actively using twitter, facebook and other such products. I 'remember' the joy I had when I found so many of my batchmates from school on Facebook and I could connect with them again. So many of us vouch for Apple products because it perhaps does JUST THIS (connecting the remembering self with the experiencing self) really well.

Is this PERHAPS a reason why participants of a usability test give ratings in the SUS 'satisfaction' that contradicts their emotions while they did their tasks ?

Wonder why these factors never influenced the design process more...

typical lifecycle of a design team...

• First nobody knows who you are - what you do in the company. Owing to the nature of our job, no matter how much effort we make to gel, the UX team tends to stand apart in an otherwise engineering/dev oriented environment. So we become the ‘exotic’ team 
• Next, we need to ‘sensitize’ people about UX – what does it stand for, why is it important, the process etc. We conduct multiple info sessions, trainings etc to make people aware.
• So now more people know us to be the ‘exotic’ team – still not too sure why we exist.
• Then our managers scrounge around to get projects where we can work with just about anyone to make in-roads. Justify our existence, start the ball rolling…
• Next, some of us work on integrating the ‘User Centered Design’ process with the Software Development Lifecyle’
• We start working with some project teams, trying to adhere to the new process, during this, few project team members experience something new – they have not asked the questions we do; they don’t have answers to our questions; we are slowing them down…we are bringing in new dimensions…we are confusing them…they are losing focus
• Now, we become a ‘process bottleneck’
• Meanwhile, some bright project team members identify a unique skill we possess that none others do – the ability to make things look pretty. Because we happened to learn the concepts of alignment, gestalts law etc.
• Now we become ‘exotic menials’ (as described in Designful Company)
• We realize that in the bid to expand our reach, we need to work on things that do not deserve us. Things that go against basic principles of design.
• We continue on our quest to build relationships, increase visibility of our team, our competencies…selling our soul more and more…painting screens…making tons of prototypes, specifications that nobody reads/ recommendations nobody notices.
• By now we are frustrated…we start blaming our management…we realize that ‘design’ cannot work unless it comes top down.
• We still continue…we fight our battles to get access to end users…we show them our UI prototypes, gather their feedback…struggle our way to incorporate the findings…we celebrate…we just did ‘user centered design’ – we saw how our user looks like
• The management applauds on our achievements of being ‘user centered’ in the way we work.
• ‘Retail quality user experience’ is what we should strive for…yay!
• We continue to get end user reactions to our prototypes and believing we are doing user centered design.
• But we continue to look at the horizon and see the likes of Apple, and wonder, wow…”if only, I could work for them.” – Reflecting a sense of dissatisfaction with what we do and how the products we put our sweat and blood into turned out.

Most 'ground up' and 'grassroots' UX teams, across companies, geographies come this far, following a somewhat similar path - from the day they hire their first 'exotic menial' to the time they are caught in the rut at the 'production' level.

According to me, this stage is a crucial one in terms of 'management' of a design/UX team. It is at this stage that:

• the team begins to loose its original members that loyally made the journey so far. they begin considering other options:
• newer jobs
• newer roles within the company
• self employment
• higher education
• sabbaticals
• the lack of anything to look forward to, result in these original team members get into the 'status quo' mode - loose the passion they once had and are reduced to appreciating their job for the salary and other perks.
• meanwhile there are possibly new starry eyed recruits. being new, they have somethings to look forward to, are learning...but are not in the system long enough to identify and bring about improvements. besides, they do not find any role models/ leaders that inspire them to do so. The system killed the passion within its leaders.

 So, why do I consider this so crucial?  

•  'Because, at this juncture, we stop questioning status quo. In the light of continous improvement and innovation, this is a disaster.'
• I believe, this is the make or break situation for a UX like team in a largely engineering set up. Not increasing our value proposition will eventually lead to redundancy.
• The 'attrition' within the team is shunned of to be a normal phenomenon - lack of reflection on why erstwhile loyal members choose to leave. When core issues are not fixed, the cycle repeats itself. 

Thoughts:
Some of my key learning over the years are:

• 'Design leadership' in a non-conducive environment, needs a lot of guts, imagination and curiosity.
• While we focus on building relationships and establishing ourselves, an important parallel task is to keep a dialog, discussion and design literacy process running for the management cadre.

While we concentrate on building relationships, at a juncture like this, I believe it is worthwhile to get involved in some 'constructive confrontation' with 'management' in order to:

• Share the power of our 'imagination' that can be translated to concrete proposals for leveraging the team for increased value. Unless being led by the likes of Steve Jobs, often senior management members do not know how best to leverage a design team. We need to demand this. We need to set some aspirational, inspirational goals.
• Better align ourselves with organizational priorities

Having a good understanding of these, will help us identify opportunities of maximum impact and value.
 
Ultimately, As Tim Brown, CEO of IDEO, has said, “Success is all about impact. Designers get turned off if their ideas don’t make it out into the world.” An elegant and thoughtful design solution is only a success if it has real resonance and value to human beings.

Being an 'grassroots innovator'

The BUZZZZ word of this decade (other than 'green' everything)
What does it take to be an 'innovator' in a large corporation?
Speaking from first hand experience, here's what I think it takes:

• Loads of self motivation
• HATE/DETEST some things in such an uncompromising manner that you are forced to think of a solution for it - (need is one of the basis of innovation)
• Have tons of ideas
• Do informal discussions to get a gut feeling of the feasibility of your ideas
• Maintain a good network/ maintain a good relationship with people who have a good network
• Don't be demoralized when you realize half of your ideas already exist - in different flavors.
• Don't be demoralized if the local patent office fails to see the potential in it
• Collaborate collaborate collaborate
• Collaborate with anyone who is as excited about your ideas as you
• Collaborate with anyone who has the skills to make a proof of concept with you
• Try to strike a balance between being innovative but not in an extremely disruptive way. The more disruptive the approach, the more it will be hard to sell it/ get acceptance
• Let the proof of concept get as many eyeballs as possible
• The more the people associate your's and the team's name to the idea; proof of concept, the better
• Once the proof of concept gets attention of senior management perpare yourself (mentally) to withdraw...
• NOW THE JOB OF THE INNOVATOR BEGINS TO SLOW DOWN AND EVENTUALLY END!!
• Your idea, proof of concept is now ready to become 'bigger' - plenty of more people will get associated with it. Some of who would like their names to be associated to it...more than the innovator's.
• For a 'grassroot' innovator, reaching this stage too is 'gratifying' 

Irrespective of who's name gets on that last ppt. - you can smile and tell yourself. 'hey, i thought of it first' :)
Its TIME to move on to the NEXT IDEA...