Want designers who code? Something’s got to give.

Posted on by
2

It’s not a new subject, but it’s certainly far from resolved, or even understood well.  For a long time, I remained indifferent to all the chatter on the topic.  However, as I started to be responsible for hiring and building UX teams, it became important to resolve this at least in my head, and share where I am coming from in more than 140 characters.

I have learnt to code as part of my computer science education during college years, I am not intimated by it, I just chose not to continue with it.  Here’s why:

I have been involved in more than a dozen projects with similar challenges, but, I think a couple will help see my point -

In my first job as a business analyst on a CRM and BI implementation for Citibank in Europe, I spent more time running SQL queries than really understanding what the business wanted.  CRM tools are highly strategic investments for any organization.  I think most of my team members would tell you I did a great job as a business analyst, but, I know I could have been a lot more innovative and valuable to Citibank if I had a better understanding what CRM meant for them, and how they expected it to transform their business.

On my first web design project at Cognizant where I had to come up with a knowledge management portal, I spent more time doing an HTML prototype than understanding the impact of what I was doing on my users.  Knowledge management systems can be fairly complex in their information architecture – particularly if you are designing for a company with 50,000 users distributed across the globe who expect the search experience to match those on Internet search engines!  If I had done something as simple as card sorting, or spent any time at all understanding the user’s mental model, I am sure the information architecture for my site would have been a better experience – to design and to use.

These were not projects where I was doing 40-hr weeks; they were 60-hr weeks on an average.  Subsequently, I was fortunate enough to work for some people who were passionately committed to user experience – who encouraged me to spend more time understanding the user and the context, performing task analysis on complex functionality, facilitating collaborative design sessions, “an hour a day” on site usage analytics, formal and guerilla usability testing.  I spent significant time in gaining experience using methods and tools to help with experience strategy, user research, information architecture, interaction design and usability analysis, and I know I am far from done.  Thanks to my association and learning from folks from companies at Adaptive Path, Coopers and IDEO (they help me justify my Bay Area mortgage!), and other individual consultants who have made significant contributions to this field – like Jeff Patton, David Hussman, Marc McNeill, Anders Ramsay, Louis Rosenfeld – I have grown into a designer who is much more aware of how my designs influence my user.  When I say I create empathic designs, I also mean that anything else is a compromise.

It’s only when I poured myself into such methods and tools, I realized the positive impact of those on the quality of the interactions I designed.  On the other hand however, my HTML/CSS skills were turning rusty, and I started to see that my designs were no more limited by my design skills, but by my coding skills.  I started to get better results pairing with UI developers who were really good at what they did, and helped me stay in touch with newer technologies for web and mobile application development.

What I’ve learnt from my experience is that something’s got to give, and it’s more often design, not code that gets compromised – When someone’s doing design and development, higher chance that they would spend more time coding than engaging in activities to understand the users, and validate their designs.  I would really like to know how many designers who code are able to get the time in even running usability tests, or analyzing site usage analytics to validate their designs.  There’s a higher chance that a designer who focuses on just design has a system in place to constantly refine the interactions based on qualitative and quantitative feedback.  I am basing this inference out of my interactions with friends in the field; it would be interesting to do a formal survey on this.

Some have made a good case for designers to code based on what Silicon Valley start-ups are asking for in their job descriptions.  I get why sometimes working backwards from job descriptions can help someone who is starting off in their career, but, if job descriptions were a way to go, then agile and lean development would not be where they are today.  Settling for lower quality of experiences because an employer wants to get two for the price of one is not where I want to go.

Being a believer and practitioner of empathic design, I look to build a team of designers that is committed to understanding the user and the context of usage, ideate through a variety of designs rather than quickly prototype in code, facilitate collaborative design with people from varied backgrounds, take the effort to get feedback on the product from real users, find innovative ways of creating a faster feedback loop.  Whether they come with coding skills or not is immaterial to me, I would rather that they have the right attitude in collaborating with developers.

 

 

If chairs were designed like enterprise software…

Posted on by
1

I have spent a significant amount of time with users of enterprise systems at large companies who I’ve seen weep at their desks because of what they’ve had to navigate through in order to do their jobs. Customer service reps who had to use at least six different applications in order to complete one customer request.  Call center agents who would be so scared about the system’s dependability that they would print every single screen they enter data into,  just in case they get stuck at a point where they just have to shut down, and lose all the data when the customer hangs up.

I remember when I first moved into our new office building at a company I worked for, the “ergonomics” folks came to check on the comfort of my chair thrice in the first two days.  Agreed, a bad chair can hurt me, but, if companies really cared about the comfort of their employees at work, shouldn’t they also be taking care of the usability of software tools that employees use to do their jobs?  Do users actually have to complain about software design torture and claim disability before any effort is taken to make internal software tools less painful to use? (Note – I did not say easier to use, right now, I think they would settle for just less painful)

I was in a discussion with Jeff Patton and Alan Cooper recently when I shared my thoughts with them, Alan Cooper then sent me this picture and said if we had allowed our chairs to be like our software at work, may be this is how it would look.  I could not resist writing a blog just to be able to use the picture!  While I agree it’s a harsh comparsion, it depicts two things relevant – the person using it is compelled to be sitting on it and although it looks like a chair to sit on, it could be used for torture.  The flaw in this depiction is that while here the torture is intentional, internal users are often provided with software that just happen to make them miserable.

 

Need for UI standards to handle errors and exceptions

Posted on by
1

No matter how well we design the customer experience, no matter how well the developers code the design, one thing is certain – things will go wrong.  And when they do, we will leave our users frustrated even when we provide them with an otherwise well designed system or product.

Proactively designing the user experience for errors and exceptions is a need and an opportunity.  As in our personal relationships where we form strong bonds during crisis times, how a computer handles a potentially frustrating moment for the user is an opportunity for us to show the user that we care.

When twitter came up with the “fail whale” error message image illustrating several red birds using a net to hoist a whale from the ocean captioned “Too many tweets! Please wait a moment and try again”, it created the failwhale fan club.

I fear that we are getting too used to designing for the “normal path” and are often impatient with developers and testers who design their code/script for exceptions.  This seems more common in an agile development environment which is all about “just enough”.  But, a lack of early focus on handling errors and exceptions might result in losing credibility with our users.  I would rather tell my user very early in my interaction with them that “I am not perfect, but, I know when something could be frustrating to you and I will make every attempt to help when that happens.”

There are two aspects to handling errors and exceptions – (1) Anticipating what could go wrong and proactively designing to avoid the situation and (2) When something goes wrong, designing responses with empathy

I know that some companies and agencies have come up with their own standards for handling errors and exceptions.  I hope some of us from the UX community can help lead an effort to establish some guiding principles and some specific practices for handling errors and exceptions on a larger scale, so we can help the users with something consistent and predictable, in an area that is quite frustrating when not handled right.

User-centered design is to quality what Agile is to efficiency

Posted on by
Reply

An often asked question on projects is  ”Can we afford to apply UCD (user-centered design) practices on this project?  We are agile and we really don’t have all that time?”  I am often lost when trying to respond, not because I don’t know, but, because I don’t know where to start.  To me, being user-centric is the same as being quality conscious.  Can we make quality an optional element of a project?  So, this question to me is like someone asking if we could afford to apply quality standards to a project…

Peter Drucker is quoted as saying “Quality in a product or service is not what the supplier puts in.  It is what the customer gets out and is willing to pay.  A product is not quality because it is hard to make and costs a lot of money, as manufacturers typically believe.  That is incompetence.  Customers pay only for what is of use to them and gives them value.  Nothing else constitutes quality”

Thank you, Peter Drucker!

Practitioners of agile, who have had a laser beam like focus on giving the customer value for money by continuously improving the efficiency of development are somehow missing the inefficiency and lack of “quality” when it comes to user experience.  It seems somehow that it’s ok to leave user experience standards out of our measurement of quality.  We try to overcome that by giving the user the “opportunity” to provide feedback.  But, the feedback that is provided by the user is in smaller portions of functionality, rarely if ever gives us an understanding of what the user experiences with the product till the very end when it may be too late.

Producing software iteratively does have tremendous benefits.  Getting feedback and refining the software as we go has tremendous benefits.  But, expecting the user to experience the entire product iteratively is not only close to impossible, but quite unfair.

User-centered design facilitates an understanding of the user in the context within which they use the software.  It makes us empathetic to the user and facilitates building software, testing it and deploying with the user and the context in mind.  All the practices suggested in UCD are meant to achieve exactly that – understand the user within the relevant context, communicate that understanding to everybody involved in delivering the solution and use that understanding in performing any activity in software development.  We might chose to apply or not apply some of the tools and practices within that discipline depending on the type of solution we are building, but, I doubt if we can obtain a good understanding of the users’ experience with the software by exposing them to it in bits and pieces.

I don’t believe iterative development can really substitute for the discipline applied in UCD, but, I believe it is a great a way to refine our understanding of the user.  We do need to make sure the software development team understands the user and the context and builds software with that understanding, in order to make iterative development meaningful to the customer.  Agile’s success with gaining efficiency in software development will see it’s true value when it can ensure quality of the software developed, and I don’t mean zero-defect code, I mean (borrowing from Drucker):

- A product the customer pays for

- A product that is of use to the customer

- A product that gives the customer value

The power of UCD in an agile environment has the potential to deliver what Peter Drucker calls quality.  Our willingness to live with one without the other might become a huge opportunity lost.

Challenges with user experience in enterprise software

Posted on by
Reply

I have tried to address the issue of “taking internal users for granted” as a technology issue, but, I am realizing that it is actually a human issue.  Providing people with software tools that does not take their self esteem away is a human thing to do. Addressing this seems like a huge losing battle, user centered design in corporate IT sometimes seems like fitting a square peg into a round hole.  How did we get here?

  • The most obvious – users don’t control the money. the users seem to have little influence on the decision to buy.  While it is highly important for IT solutions to align with business strategy, we often seem to miss the point that businesses cannot achieve any value when the software makes the users hate their job.
  • The move to making IT a profit-center – In hindsight, this was probably one of the myopic decisions taken for corporate IT.  IT departments oftentimes forget that they work for a company, they land up working for their “business clients”.  That makes the relationship no different from a client-vendor relationship – full of contract negotiations, processes for creating safe zones, lack of collaboration and trust.   It has taken away any incentives to be collaborative or take risks towards providing better solutions that keep the user in mind.
  • The assumption that “there will be blame” and “there should be blame” - The first lessons I received when I started to manage projects were (1) Keep ALL your emails, you will need them some day (2) Highlight all risks in red in your weekly status reports so the business cannot say they were not aware (3) Make sure you have documentation for all scope changes, create a change request process that is robust.  And very little about how I could create a relationship of collaboration and trust between two departments in the company.  There is this pervasive assumption of “there will be blame” and hence an encouragement towards any ”process” that will  help avoid blame.   On the same token, people who pay for the software are often working on the premise that “there should be blame”, very few IT projects get delivered without the business looking forward to the opportunity to beat up on their own colleagues in IT.  In this massive blame game, who has the time to care about how they are making the users feel.  All our energy is drained out just by finding blame and avoiding blame.
  • Unreasonable resistance to change by the users.  Agreed, this is a highly subjective conclusion.  But, most of us in IT know that every single software implementation has an element of noise that comes from a large population of the users complaining about any change to their software tools.  By doing this, they’ve cried wolf to a point that business stakeholders or IT managers have trained themselves to ignore disgruntled users.
  • Offshoring being an end it itself.  I have worked for large software service organizations and have sold offshoring services, so, it might appear strange that I say this.  My problem is not with offshoring itself, but the attempt at transferring work to an offshore location with little attempt at transferring an understanding of the user.  When IT is co-located with the users, there is some chance that the development team develops with the user in mind or has the opportunity to obtain feedback informally.  When projects are offshore, the quality of deliverables are assessed by functionality, not usability. In this situation, empathy is a scope creep!

More than 50% of software being built is for internal use.  But most of the effort towards creating better user experience is put into consumer facing software.  The forces of economics are at play, understood.  But, can we afford to create a bad work environment for our own colleagues?  We have to realize that a bad software tool makes an unhappy employee.  If this employee happens to be the customer service agent,  we are now transferring the impact of this to the agent’s interaction with the customer.  Phrases like “empowerment of front-end employees” and “Customer Relationship Management” have no meaning if our front-end employees are disgruntled…

Using Innovation Games® to help decide what to build

Posted on by
1

If you don’t know much about Innovation Games®, I highly recommend you read the book and/or take the class.  But, here is an extract from the preface to the book – “Innovation Games are fun ways to collaborate with your customers to better understand their needs.  You can use them to discover new business opportunities, drive strategy and product road map decisions, improve the effectiveness of sales and service organizations, fine-tune marketing messages, and create more intimate, durable relationships with your customers”.

From amongst the many games that Luke offers, I have a specific set of games that I propose we “play” as part of new software development in corporate IT environments – to help us decide what build.  I believe that these games will enable a high level of collaboration between business and IT, and will help huge strides towards designing software applications with a user-centered design.   It’s great that many of these games are now available online for virtual collaboration as well.

  • Play “Remember the Future” with the stakeholders at the beginning of the project and whenever there are significant changes to business plans – “Remember the future” helps in understanding your customers’ definition of success by seeing how they shape their future – The reason why I highly recommend this game to be played with stakeholders investing in software solutions is because some of the projects undertaken by large corporations tend to extend over months/years, and often chase the moving target of business plans.  The question phrased here is not “what should the system do”, instead it is “What will the system have done?”   (Notice the difference!) This helps the stakeholders think in terms of business drivers over a longer time-frame, which can then help align the software application with the business strategy of the company not just today, but through the life of the software.  It is very powerful in helping the IT department partner with the business by jointly visualizing the road-map. For example, if the business is planning to launch their operations in a new geography and your software needs to support that, there is high chance you will talk about that while playing the game than discover it down the line.  Play the game again when there is a change in the business strategy and your software needs to re-align with it.
  • Play “Spider Web” with users – This game makes customers work individually or in small teams to create vivid pictures of how your products and services fit into their world – Oftentimes, as developers of a new application, we miss an understanding of how it fits into the user’s world.  We normally do an excellent job of understanding how the myriad of IT systems interface with each other.  IT architects like to hang these charts up for everybody to appreciate the complexity of a large corporate IT environment.  But, seldom do we understand the myriad of software systems we put our users through – and then we add one more.  A great example of this is how we introduce new CRM applications into the sales and service function.  The user is probably using five different applications already to access information about the company’s five different product offerings.  Now, you introduce CRM as the silver-bullet solution – is it really going to be make life easier for them or is it going to challenge them in navigating through one more – you will find out when you play Spider Web – you will develop the empathy for the user that is a pre-requisite to building good software.
  • Play “Show and Tell” with whoever will play!  By this time you should have a group of stakeholders and users you will be talking to on a regular basis through the life of the project – they will be your regular attendees for any review sessions like the sprint review and for close collaboration during release planning.  The goal of this game is to identify the most important artifacts that will be produced by your product or application.  You will be asking your customer to bring examples of artifacts created or modified by your product.  For example, if you are developing a system for Business Intelligence, your users/stakeholders will bring reports, mock-ups of dashboards that they will get from your system and will share them with other users and stakeholders.  It may even be a sales representative showing you an invoice of a sale he closed using your system.  This gives you a powerful way to not only understand your user, but, also to understand your deliverables.  This is also powerful because you ask the user to bring what she wants to bring, you don’t make them go through your own mock-ups and documentations that they don’t really care about!  This may not take away the need to do your own analysis later, but, has a much higher chance of engaging users who are often intimidated and disengaged from the software development process.
  • Play “20/20 Vision” at every iteration planning – This game helps understand customer priorities –  enables customers / stakeholders negotiate the relative important of such things as product features, market requirements, and product benefits.   This game may first need to be played amongst product owners to narrow down on a set of features and functions before involving others in the company.  But, if there are conflicting priorities amongst various stakeholders, it can be a great tool for all of them to collaborate on deciding what needs to be built.

As powerful as these games are for enabling collaboration and helping decide what to build, we have to keep in mind that designs should be informed, but not solely determined by the data collected.  If the data collected from these games are by themselves used as a substitute to traditional requirements analysis workshops, it would be an opportunity lost in creating an environment of collaboration and trust.  Use the outcome of the games to better understand your customers and have fun while doing it!  I like how they say “A seriously fun way to do serious work – seriously!”

As always, would love to hear your thoughts, please post your comment here or write to me at anu@goagilepm.com

The challenge of deciding what to build needs a holistic solution

Posted on by
3

On one of my projects where we built a large software application on an agile scrum framework, we were a team of six product owners, and 20 developers.  It was a highly competent group and I could not have asked for a better team to lead on an agile scrum based delivery.  The problem though was each one of us looked at the project from one lens:

-          The designers wanted to make sure this was the “coolest” application in the company, his reputation was associated with it!

-          Three of the product owners were excellent business analysts who would chase down every bit of information they could get with regards to a user story and write detailed acceptance criteria so that the test cases were close to perfect

-          One of the product owners was responsible for ensuring that we had all the functionality for processing business rules and were integrating with other interfacing systems effectively – for him, all that mattered was whether we were processing all the rules correctly and we had every data element validated while doing a transaction in our system

-          As the product manager, I was responsible for release planning and tracking progress to plan to report to stakeholders, so, I had to ensure that the development team had a good pipeline of work, whether we had the acceptance criteria detailed for the upcoming sprints so that the product owner team did not become the bottleneck for the developers

-          The development team often negotiated for sprints dedicated to technical debt and/or refactoring

-          My boss, the most agile minded person I have ever worked with had to ensure we were all collaborating with each other and the project was surviving the intense political drama that was very much part of any project in the company (I never envied his job!)

We did a lot of things right.  Each one of us was trained with excellent tools to do our job.  For me, use-cases were a great way to keep the big picture in mind and user story mapping was a powerful tool for release planning.  The other product owners drew from other set of skills and strengths to do their jobs well.  We structured ourselves in a way that gave each of us decision making in our own areas of work while also having reporting relationships to ensure alignment and visibility into the project.  We had divided the development team into four teams and assigned one product owner for each team.  We ran effort of managing the backlog of what to build parallel to the development track and ensured we were ahead by a few sprints all the time.  I was crazy enough to ensure that happened!

We had some pretty frustrating problems though:

-          Every time one of us added a story to the backlog that potentially impacted dates or scope of delivery, we were never quite sure if this was something we missed because we did not take the effort to understand the customer at the outset or whether we discovered something from the last iteration that gave us a better understanding of what to build

-          If had to re-prioritize the backlog based on feedback from a sprint review, my boss was left to think about who he needed to meet for lunch to damage control for what we decided not to build to make our dates

-          Every time an interfacing application or program was getting impacted, we were in a quandary – none of our prioritization techniques helped anymore, we were chasing a moving target that not only moved, but often changed directions

-          Although we tried to stay ahead of the development team, every time we encountered a significant change in functionality, our user interface design had to be revisited for its usability – our developers hated it!

-          Whenever the development team had to re-factor or clear technical debt, the issue of deciding what to build took an entirely new meaning with far reaching consequences that the product owners could not even fathom (I am sure that has never happened to any of you!)

For those in a corporate IT environment, does this seem familiar?!  I remember one of the agile coaches calling the product owner a superman, a superman was what we needed to keep this going – the only reason we survived was the incredible commitment of every one of us to the project and to our work.  No forum on agile product management, no training on business process management, no discussion on how to make UX work with agile was helping.  We did have a project manager helping us manage the many moving parts, but, when it came to “deciding what to build”, the product owner team was on its own!

Right now, there is still a lot of focus on helping organizations transition from waterfall to agile.  I am optimistic that soon, the dust will settle on agile adoption and it will become the norm for software development.   But, when that happens, the very principles of agile will become the challenges to deal with – how do you not lock down scope at the very beginning of the project and still retain your sanity for the rest of the project.  How do you not design everything upfront and still not lose velocity in development.  What is “just enough design”, what does “just enough analysis” feel like?  What makes waterfall easy is that it does not leave any of these questions to subjective answers – you are done with requirements when everybody “signs-off”, you are done with design with it can be traced back to the “signed-off requirements” – simple solution – yes, we know it does not guarantee good products, but, it did not ask for me to hire a team of supermen in my product owner team.  It’s not often, but, sometimes, I do put my sanity over my product!

A holistic approach to deciding what to build means we move beyond principles and best practices to scalable and repeatable solutions.  To look at the problem from the lens of just UX or engineering or product management or project management is IMHO making it appear that the problem is going away when it might be getting worse.

Agile adoption needs more attention on deciding what to build

Posted on by
6

“Deciding what to build” involves a number of activities that take place during software design and development starting from understanding your customer, her needs and defining solutions that not only satisfy the stakeholder, but also create a good user experience. Software systems are the most used tools in organizations today, and they can make a difference between a happy employee and a disgruntled worker. A bad user experience hurts not just the user, but, the business – I would not make software user experience any less important than having a good chair in my office or a good cafeteria in my building – things that may seem small, but, can make a difference towards retaining good employees.

Agile is the best thing that happened to software development in a long time. I now wonder why we would ever do anything as linear and risky as waterfall. But, that acknowledged, I have a humble request to the agile community to take a good look at what we have done (or not) to solve the chronic problem in software development – quality of requirements. While agile has managed to reduce the pain of responding to and managing changing requirements, none of the methodologies under agile seem to have helped us come up with a better understanding of the customer’s needs and hence products that meet their needs? The Agile Manifesto itself encourages collaboration, but, we have not done a good job of leveraging collaboration for better product design. Being iterative has helped take the risk out of insufficient requirements analysis and product design, but, iterative development cannot be done with the intention of making up for lack of understanding of the customer and poor quality of design!

I believe that what’s causing this is the general tolerance to the lack of a user-centered-design approach – vis-à-vis our tolerance to inefficiency in software delivery. There is of course a balance that we need to strike between better product design and time-to-market – but, we need to remind ourselves that the time we choose to market should not become an opportunity lost!

Hence my attempt to bring together the community of product mangers, user interaction designer and engineers to blend user-centered-design and agile methodologies to create successful products. There have been several solutions proposed – mostly tactical and procedural – but, I think this needs a fundamental change to how we think about product design and how we bring all the disciplines together. We need to come together and design products with the customer in mind – whatever that might take!

Overcoming UX Exclusivity

Posted on by
6

Even early in my career as a business analyst, before I received any formal training in user experience design, I was deeply passionate about user experience and considered it part of my job.  I spent significant time shadowing users while understanding their needs, and in modeling all the information I gathered into something that could help developers understand what the usability of software meant for the customer.   Information Architecture came naturally to me and the prototypes I created often generated some great opportunities for collaboration between users and developers.  As I started to understand UX more as a formal discipline, I was excited about its potential to further help me understand the customer.  But, as I started working with UX professionals more and more, I found many of them to be stylishly aloof and demanding an exclusive jurisdiction over user experience design.  I did not let this affect me because I was just excited about the possibilities of what I could do when I had designers work with me.

What I was missing though was the impact of this culture of exclusivity on the development teams and the IT organization as a whole.  I’ve often seen proxy wars being fought over user interface design that I suspect was more a resistance towards this socially restricted patronage of UX skills.  When I first read books like “The inmates are running the asylum”, I was so excited, it made me feel like I was part of a movement that would change the world!  I admire Alan Cooper for what he has done for user experience but, I do feel that he could have taken a less intransigent approach than he did in the book.  Even if we argued that the compelling argument he makes about the development community’s apathy to user experience was necessary and relevant to create the movement that it did at the time, it’s time to stop towing that line.

Jeff Patton, who has been an inspiration to me once told me this in the context of UX roles: “Named roles are a mechanism for defining a process.  I believe all discussion that focuses on named roles as a starting point, as opposed to skills, start with a traditional process in mind.  If we can bust down to the skills it takes to build a software product, then build back up to process that allows lots of people who collectively have the skills to work together, then we have something.  I don’t know what an ideal process would look like.  But, I do spend lots of time trying to tear down assumptions about roles and responsibilities (characteristics of process), and move focus to skills.”

If more of us can focus on making user experience second nature to software development teams rather than force it as a role or a process, I am optimistic that the “UX + Agile challenge” would become a no-brainer to solve.