Macadamian Blog

Why Design-Thinking hasn’t caught on in software

One of my colleagues, Francis Beaudet, just wrote a great article for our Critical Path newsletter called Why is Design Thinking Failing to Penetrate Software Companies? I love his point about how software teams think "Waterfall" when they hear "design up front" and run away screaming.

I'll add another reason why UX and usability isn't catching on at all software companies (or why some are simply paying it lip service) - with most enterprise software, the Buyer is not the User. Large enterprise systems are sold at a C-level or to the IT department, and often the people that have to actually use it, and whose productivity is supposed to go up tenfold for using it, aren't consulted.

On the other hand, in e-commerce, and to some degree SaaS, usability and user experience design is taken very seriously, because even small improvements in usability result in more conversions and more purchases. Salesforce.com is a good example - compared to traditional monolithic CRM systems, Salesforce.com is infinitely more usable. Why? Because it's sales-people who are buying it, not IT, and if Salesforce.com was difficult to use, they wouldn't buy it.

I once visited a large enterprise software company, and they asked me - how do you work? When I explained how we approach a project - observing users, rapid prototyping, testing and validating with users, and so on, their reply was, "that's nice, but we don't have that luxury here. We just hire good designers and make our best guesses".

Enterprise software companies could take a few lessons from .coms and SaaS companies, before their lunch is completely eaten.

Who wags who?

It's an old joke to ask if the dog wags the tail, or the tail wags the dog. The saying fits in many contexts outside of media, including the age old battle between testing and engineering, or the usability of the application, and the technical design of the application. Do the user experience (UX) folks design without regards to the technical feasibility of their work, or does the engineering team dictate design by imposing technical constraints?

Jumping in the way back machine, five or six years ago I was working on a large web application, it was Macadamian's first project where the engineering team implemented the output of an interaction designer. When asked, I told the designer to go ahead, don't let technology limit your designs. Sure enough, we ended up creating an impressive web application (see left) with all the bells and whistles of a rich internet application, all back in 2003. I also lived at work for weeks implementing all that cool stuff. I wish I had read this article back then!

At Macadamian, we have had a world class user experience group in-house for the past few years. Learning to work with this new UX group was not an easy task for a primarily engineering and quality assurance company. It took more then a couple of months to work out the process for collaboration between UX and engineering. Everything Tim has discussed we have also learned, the hard way.

Being that I come from the engineering side of Macadamian, and that most of the costs of the project are on the engineering side of the project, the point that jumped out at me the most was the suggestion to listen to the concerns of the developers.

The first few combined projects between the engineering and UX group resulted in significant schedule delays and cost overruns on the engineering side due to really good, really cutting edge, and extremely difficult to implement designs coming out the UX group. When the estimates were created, the estimator put time in to basically add some form fields, text, and maybe a graphic or two. Pretty naive.

Unfortunately (or fortunately depending on your perspective), the customer saw these designs, loved them, and then expected to get them for the same price as that form with 23 checkboxes and 97 form fields. The complexity and innovation required on the UX side was not expected on the fixed-bid engineering side.

To solve this problem, a simple (and in hindsight, obvious) process improvement was made. The developers had a chance to look over the designs prior to the customer seeing them. This allowed any potential design decisions that would adversely impact the schedule and cost to be caught, and fully discussed prior to the designs being approved by the customer. It wasn't that engineering had a veto over the design, it was allowing the usability group to be made aware of any potential technology challenges to be discussed earlier in the cycle.

This allowed the two groups to work closely together and solve any potential issues. Sometimes the UX folks were able to convince the developers of the critical nature of the particular design, and other times the user experience group came up with another solution that was just as usable, but much easier to implement. However, don't confuse this approach with one where technology drives what personas can and cannot do with the product, that would be a mistake. User needs have to drive the design.

Just fake it

No matter what some people might say, faking it is perfectly acceptable. Seriously, faking it allows you to get finished your task sooner. Some people think that faking is cheating, but it's not.

Ok, enough with the double entendres, what am I really talking about? Why using mock objects or stubs of course.

Stubs are more common in the types of projects that we tend to do, but we do use mocks as well. I really like these design patterns and try to use them often to decouple different teams from each other. This being said, the concept of stubbing and mocking is starting to become a bit of a lost art.

Once the interface and supporting data structures are designed, one team can start to work on developing the user interface using stubs and mocks whilst the back end team works on implementing the actual functionality.

This has several benefits:

• It removes the back end team from the critical path
• Facilitates the creation and maintenance of unit tests
• Facilitates the top-down coding methodology
• Provides an actual user of the APIs and data structures to validate their design
• Allows the team to focus on the big technical risks
• Helps facilitate the separation of teams

Shortening of the Critical Path
By the smart application of mocks and stubs, the manager can reduce the overall critical path of the project and the dependencies on the back end team. All the teams need to collaborate together to define the interfaces and use cases, but once that is done the teams can work independently, and most importantly, in parallel. Without the use of stubs and mocks, the user interface team for example, would be unable to accomplish much work until the back end was implemented.

Creation and Maintenance of Unit Tests
Many teams and projects now work in the Test Driven Development methodology, or at the very least rely on unit tests to demonstrate correctness of the code and help guard against regressions. The use of mocks and stubs can help encourage the creation and maintenance of unit tests by allowing the developers to first stub the back end and then write the unit tests to exercise the interfaces. Additionally, mocks provide the ability for the unit test writer to write the unit tests that exercise code that relies on complex objects. Additionally, since mock objects implement the interface and simulate more complex real objects they allow programmers to implement and unit-test features in one part of the application without actually having to call the more complex underlying objects. A broad, well maintained unit test suite will give you the manager a lot of confidence with regards to the overall quality of the application. In addition, a good test suite can give the manager a lot of confidence to approve the re-factoring exercise without fear of introducing regressions.

Facilitates top-down coding
Stubbing and mock objects are an essential part of the top-down coding methodology, or as some people like to call it "breadth-first coding". Read the link for a much more detailed explanation then what I have room here for.

Validation of APIs and Data structures
Often "paper" doesn't match reality, and the best designs on paper fall apart in real life applications. The use of mocks and stubs that meet the interface requirements and behaviors of the design allow the users of the interfaces and complex objects to actually use them in a real life scenario while the real implementations are still progressing. This can safe costly redesign and re-factoring exercises, both in terms of budget and schedule.

Move the big rocks first
Clever use of stubs and mocks allows the team to focus on solving the big technical hurdles without getting bogged down in the small little details of the project, the so called while stubbing "boilerplate" functionality. For example, your web application needs to implement complex domain specific functionality that requires a lot of collaboration between the development teams and the stakeholders, of course you need user management and login, but those problems have been solved a thousand times before, and the amount of work required to implement them is well known, leave the actual implementation to the end. Removing the technical hurdles upfront in the project allows the manager to more accurately estimate the end date of the project as the most riskiest items in terms of budget and schedule have been solved.

Separation of teams
With today's global teams distributed across the globe all efforts have to be made to decouple the teams and reduce time to market while at the same time keeping the project as a whole cohesive and highly productive. When the developers from your user interface team come to you and say they are blocked because they are waiting for the back end guys to finish their service layer, or that no one but the team here in the head office can work on that feature because it depends on another feature from another team, remind them of the concept of stubbing the APIs and mocking the complex pieces in the interim, this may well indeed allow another team in another location work on that feature with little to no impact in quality or time to market. Of course the teams still need to communicate constantly with each other. The ability to easily separate areas of the application will help the manager build out the team in multiple locations, potentially allowing the team to grow faster then could be hired locally.

You can’t afford not to…

With all of the economic doom and gloom being reported in the news media on a daily (….oh alright…hourly) basis, everyone is reacting by buckling down and tightening their belts. Any expenditure considered a luxury or “nice-to-have” is being cut off or put off indefinitely. Don’t get me wrong…I’m not about to argue otherwise – now is the time to cut frivolous spending and focus spending on initiatives that will have long-term and lasting benefits to the organization.

If you are a product company or online service delivery company, that means taking a closer look at your product or service value proposition. I am here to tell you that usability (be it design or user needs research) is NOT a luxury – in fact usability can help you refine your value proposition, make your product more competitive and positively impact your bottom line.

I’m always surprised to find that organizations follow the same process time and time again but continue to expect to get different results…build feature list, implement feature list (often without proper user research and testing), deploy product and then spend 200% more money fixing problems post-product release when users start using the product. This is a costly cycle! According to the Standish Group, only 28% of software projects actually succeed. By succeed they mean ship on time, within budget and with all the features. This % is likely lower when you take into consideration user satisfaction and product/service abandonment rates. Projects and products fail and become costly because of lack of contact with users or understanding of user requirements.

You may be asking… “Exactly what can companies do to stop this trend?” The answer (at least part of it): incorporate user-centered design methodologies/activities into your product development process. Think of usability as a form of risk management. Usability allows you to balance business requirements, user needs and technical constraints. Consider this – we recently conducted user research and testing which indicated that users wanted to be able to do multi-dimensional filtering on two separate databases AND they wanted the results within a 30 to 60 second time frame (not the 5 to 10 minutes it was currently taking). This was identified as THE most important aspect of our client’s product that needed to be fixed. Of course, when we took this to the client they said “no way”. Technically there were issues, time was a consideration (especially given they had other “features” they wanted to include), and even if they could figure out how to do it, they said it would be impossible to meet the 30 second requirement. So our usability experts worked with the client to overcome some and work around other technical constraints. Without giving too much information away, we helped the client prioritize their product feature list (some things got dropped) so that the developers now had more time to focus on what users were identifying as a major shortcoming in their product. In addition, we got over the 30 second hump by immediately displaying the results as the software was working away in the background. In the end, the users and client were both happy. By employing a user-centered design process, you can reduce churn (that ever-changing feature requirement list), focus on high value/high priority requirements, reduce the number of change requests, and save maintenance costs.

Still don’t believe me. Let me provide you with another example. (I’m quoting statistics from an article published in the January/February 2005 edition of ProductMarketing.com; you can read the full article here: http://www.pragmaticmarketing.com/publications/magazine/3/1/0501bh/?searchterm=McAfee).

McAfee Inc., decided to take a different approach when they developed and deployed their “Protection Pilot” software. Their main goal was to reduce antivirus management time for their system administrator users to one hour or less per week. To do this they made user-centered design a priority throughout the project. Guess what happened? They reduced their customer support calls by 90%! According to the case study, within 10 weeks, users downloaded 20, 000 copies of the software but McAfee received only 170 calls to their support lines. Now we weren’t involved in this project in any way, but we can tell that this case study is just one example of what can happen when you focus on the user experience design.

Here’s a short list of things we recommend our clients do when they are trying to save costs associated with product development (and ultimately improve sales and customer satisfaction):

• Collect user requirements (before you start building) – this means finding out who your users are, what their specific goals and needs are, and the context within which they are using your product/service. Let’s take the iPOD as an example…I am a music lover (user), and I want to access and listen to my music (goals/needs), at home, at the office and while I’m enjoying my daily run (context).
• Retain focus on the user experience design – Your user requirements should inform the overall design of the product. This includes everything from defining the “feature list”, designing the architecture, user interface and visual design right down to coding and deployment.
• Test early and test often (if possible)…and by “test” we mean conduct one-on-one usability tests with representative end users or potential customers. Don’t be afraid to put product concepts and wireframes in front of your users. This will allow you to identify issues and fix them before you get too far down the product development road.

Is Usability free? No, but the return on investment can be huge. Focusing on usability will help you increase overall usage of your product or service and save you time, money and heartache in the end. As Jakob Nielsen remarks in his latest post (http://www.useit.com/alertbox/intranet_design.html), “good user experience doesn’t require size or humoungous budgets; it requires talent and emphasis on meeting the user’s needs.”