In his SD West talk, Jeff Lopez-Stuit mentioned the book Mental Models by Indi Young. It is available both in soft cover and PDF. The book gives you another tool to help figure out what your users are really thinking as they use (or attempt to use) your software.

The book defines a mental model this way.

“To create a mental model, you talk to people about what they’re doing, look for patterns, and organize those patterns from the bottom up into a model.”

As an example, here is a diagram showing a mental model of how most people start their workday:

Mental model with features aligned beneath it.
(Features borrowed from the product category list from Procter & Gamble’s site www.pg.com.) Young, Indi. 2008. Mental Models: Aligning Design Strategy with Human Behavior. New York: Rosenfeld Media. www.rosenfeldmedia.com/books/mental-models/

The diagram shows the steps people take to get ready for work in the morning, or at least how they think about them. The product designer (Proctor & Gamble in this example) can then design products that are consistent with the world-view indicated by the diagram.

“You use the model to understand how your current offerings do and do not support people and devise your strategy going forward. You do this through multiple workshops with team members and stakeholders in your organization, which develops understanding and innovation.”

And in more detail:

“First, reach out to actual users and have a conversation with them, collecting their perspective and vocabulary. Analyze all of those conversations and composite them into a diagram called “the mental model diagram.” Then compare all of the things your solution is supposed to do with the different parts of that mental model diagram. Align them with the concepts that they support. You can do this with functionality just as it exists, or functionality being planned, or you can play around with brainstorming new ideas. When you step back and look at the whole picture with teammates and stakeholders in the organization, you can develop a design strategy—a vision—to follow”

You may not have time for “multiple workshops with team members and stakeholders” and the book offers several short cuts to using mental models:

“If you are designing for software, you can use the complete diagram to derive the toplevel organization of the application, such as navigation or toolbars. Additionally, you can use the mental model as a starting point for interaction design and as a guide for feature definition.”

See Five Disciplines of User Experience Design for a description of Interaction Design.

Indeed, creating a mental model is just one of several techniques you can use to define your user interface and software application in general. This diagram from the book does an excellent job of showing how mental models relate to the other techniques.

Constellation of some user-centered design steps.
(No wonder it seems so hard to figure out where to start!)
Young, Indi. 2008. Mental Models: Aligning Design Strategy with Human Behavior. New York: Rosenfeld Media. www.rosenfeldmedia.com/books/mental-models/

Will you have time for any of these? The author admits that she often lacks the times for scenarios and storyboards:

“I don’t write scenarios because I ordinarily work in quick-paced environments. I explore scenarios verbally with my team. To communicate these scenarios to other team members, we could use comics, storyboards, or videos, but typically we don’t have time. We go straight to prototypes, working directly and verbally with engineers.”

I think going straight to prototypes works if you have direct access to the engineers and you can communicate effectively. That is often lacking with a global engineers operating in a different culture. Therefore documenting a mental model of your user’s thought process can help communicate the goals of your software to your development team.

The bottom line is Mental Models is another tool you can consider using in your situation to discover and capture what your users are thinking. It can help you design a more user interface that has a better chance of delighting those users. However, it is not a replacement for minimal use cases and user interface specifications you need to provide a global software development team.

Bookmark to:
          

User-centered design (UCD) requires some upfront work to discover what your target users do now so the new software you develop will fit with their natural working environment and ways of doing things. Performing significant amounts of upfront work is counter to strict Agile procedures.

The article Agile User Interface Development by Dave Churchville on the InfoQ website does a good job of describing the tradeoffs between UCD and Agile development.

The bottom line is an initial iteration to focus on user interface design is perfectly acceptable. The article mentions several techniques you can use to define your user interface such as paper prototyping, wireframing, HTML and even Visual Studio (when the end result is a .NET application).

A weakness of wireframing is it gives you sketches of your application screens but misses the sequence of how those screens are used to achieve a goal with your application (like in use cases).

Of these techniques, I like using an HTML editor the best. It enables you to define the screens and then link them together to create what I call am illustrated use case. That will show your prospective users (and global software developers) not just what each screen looks like, but also how they interact to form the complete application.

Bookmark to:
          

Jeff Lopez-Stuit mentioned these five User Experience (UX) disciplines in his talk at SD West:

1. Information Architecture – the information elements and objects and business rules defining their relationships
2. Interaction Design – layout, flow of information and feedback provided to users
3. Usability Engineering – to ensure your software behaves as users will expect
4. Visual Design – graphics, color, look, feel and visual quality and consistency
5. Human-Computer Interaction – identifying the user interface elements available for use including new Web 2.0 features

I was curious about the details and found this recent article, The Five Competencies of User Experience Design online. It describes these five UX disciplines in more detail and renames discipline (5) Prototype Engineering. I like that name because it focuses on the front end of the software development process where a little bit of prototyping can help you try out UI ideas. These days it is easy to create confusing UI with Web 2.0 or Flash frameworks and some prototyping helps avoid confusing software coming back from offshore.

Use of these UX disciplines in creating your software should be considered. It is unwise to expect your programmers to successfully engineer your user’s experience as well as your software, especially if they are offshore.

On the other hand, you can usually apply these disciplines during each iteration of development and improve your user interface over time. And some of them can be handled by your offshore team. For example, many offshore firms have graphics designers with experience to handle the Visual Design discipline.

One Accelerance client recently used an offshore team to create UI screen mock-ups in Visual Studio. The client collaborated with the offshore team on all five disciplines. When the screens were completed the team started adding the code to deliver the functionality.

Improving the user experience provided by your application can mean the difference between success and failure. Don’t be shy about asking for help. Many offshore teams will be able to tackle some or all of these five UX disciplines.

Bookmark to:
          

I attended the Agile Usability session at SD West. It was presented by Mickey Phoenix and  Jeff Lopez-Stuit, both from SolutionsIQ. The central idea of their talk was how to create a superior user interface when short and quick Agile iterations budget zero time for upfront analysis of the user experience. Indeed the entire discipline of User Experience (UX) engineering does not seem to fit with rapid application development methods like Agile.

In the talk, Jeff mentioned the Ten Usability Heuristics defined by usability guru Jakob Nielsen:

1. Visibility of system status
2. Match between system and the real world
3. User control and freedom
4. Consistency and standards
5. Error prevention
6. Recognition rather than recall
7. Flexibility and efficiency of use
8. Aesthetic and minimalist design
9. Help users recognize, diagnose, and recover from errors
10. Help and documentation

They are not specific recommendations for the layout of your user interface but are higher level principles to consider and abide by to create a product that is easy to use. The goal is for your user to “become one with tasks” that the software implements.

These heuristics are a valuable tool to use when reviewing the user interface of your software between development iterations and before release to your customers and users. Make sure your global software development team is aware of them as well so they can make good decisions when creating your software.

Bookmark to:
          

I picked up the book Made to Stick by Dan and Chip Heath as a guide to create easy-to-remember messages to use as a resource for the new design of my company website.  They say the most memorable or sticky messages have six characteristics – Simplicity, Unexpectedness, Concreteness, Credibility, Emotional and Stories. You can remember these by using the memorable acronym SUCCESs.

For years I have been intrigued by the concept of a meme – an idea that self-replicates by spreading through a human population because of some set of compelling properties. Urban legends, advertising jingles and other cultural particles somehow spread and then never leave us completely. What if you could create a message for your own product or service that is a memorable as “I wish I were and Oscar Meyer wiener” or spreads as quickly as a story about McDonald’s using earthworm meat in their hamburgers? The book analyzes these phenomenal examples to uncover the six common traits of stickiness. This is the first book I have read that presents a formula to construct sticky messages for your self. It still may not be easy, but at least you can judge the quality of your message in each of these six areas.                                                                                                                    

One reason you may have trouble crafting a memorable message is because we suffer from what the book calls the “Curse of Knowledge”. This curse is an inability to understand why others don’t get what we are talking about. That is, we have so much knowledge about some particular area that we cannot imagine how someone else doesn’t understand what we know. 

A brilliant example of this is from a study as Stanford called the Tapper and Listener game. It is described in Made to Stick this way: 

Tappers receive a list of twenty-five songs, such as “Happy Birthday to You” and “The Star-Spangled Banner.” Each tapper was asked to pick a song and tap out the rhythm to the listener (by knocking on the table). The listener’s job was to guess the song based on the rhythm being tapped… 

The tappers got their message across 1 time in 40, but they thought they were getting their message across 1 time in 2. Why? 

When a tapper taps, she is hearing the song in her head… Meanwhile the listeners can’t hear that tune – all they can hear is a bunch of disconnected taps, like a kind of bizarre Morse Code. 

In the experiment, tappers are flabbergasted at how hard the listeners seem to be working to pick up the tune.  Isn’t the song obvious? The tapper’s expressions when the listeners guess “Happy Birthday to You” for the “The Star-Spangled Banner” are priceless: How could you be so stupid? 

Indeed, the stupidity conclusion is often applied to customers that don’t understand the power of our products.   It is also applied to an outsourced software development team that has limited insight into what you need in your software. Add in the cultural differences and physical distances of offshore outsourcing and the rush to judgment is inevitable.  I started reading this book to help improve my website but then got insight into the software specification process. It’s not that you want to write software specifications that your offshore team will never forget. It’s that you want them to really understand what is needs. The key to this is telling stories.  

The book presents evidence that “mental simulations” improves performance. If you practice something in your mind then you have a better chance of carrying out the activity successfully. When your message is a story, it is a type of mental simulation.  

When you specification includes stories on how your software will be used then the developers have a better chance of developing it correctly.     

Bookmark to:
          

A major step for me when writing Software without Borders was sending out chapters for peer review. This is not the usual review for spelling and grammatical errors, but a review of the accuracy and relevancy of the content. I braced my ego and sent out the individual chapters to over 40 reviewers.

The chapters that created the most controversy with peers were Chapters 5 and 6 on Describing Your Software and Controlling Your Outsourcing for Outsourcing. I was chided for not taking a firmer stand in favor of the Agile approach.

There was no question that at the time these chapters needed improvement. But I was not going to be drafted as an Agile Evangelist. As you will read in the book, I strongly recommend Agile, especially for new software development. But there is still a place for other software development approaches too.

My experience during peer review was similar to feelings expressed by John Parkinson in the “Hands Off My Code” article in CIO Insight. Have you faced Agile peer pressure when making inquiries of the experts about your software development approach?

Bookmark to:
          

I was quoted in a wide-ranging article about software quality published in Global Services last week. The starting premise of the article is that Indian programmers are faster and cheaper but deliver software very low in quality. 

What a crock!  

I told the author (politely) that I disagreed with this stereotypical theory. Even if you have some “evidence” of poor quality software developed in India, then it is just anecdotal and does not prove there is a general or systemic problem.  

“Hold on”, the author calmed me down, “I am finding that most people agree with you.” Indeed, the title he selected for the article is Fallacies About Failure.

The conclusion drawn by the article is that the work you put in on specifying your software pays off in the end. Without a specification – a definition of what your software should do, then you have no objective measure of what quality is. Similarly, not having a software development process to manage and guide the programmers will lead to delays and problems with software quality.

I agree that working on your software requirements and specifications is very important, especially when there is a large penalty (like loss of revenue or even lives) if you get it wrong. Chapter 5 of my book Software without Borders (this chapter is available for download on the book website) discusses the software requirements and specification issue. The problem is that for many new software applications it is rare to know exactly what you want. Writing a long specification can seem like a huge waste of time.  

And it probably is.  

Instead, many companies are using more “agile” software development methods to gradually and iteratively deliver the software functionality needed. You don’t need a complete specification – just enough detail to get your programmers started.  

Sounds great!  But can it work with offshore outsourcing?  

The answer is yes. But you need the right kind of offshore team with professional engineers that can collaborate with you to develop the software you need. Don’t just outsource to the cheapest programmers. Hire the better programmers that have a track record of creating high quality software – no matter what country they are in.

Bookmark to: