Mental Models

One of the companies I'm associated with is going through a major website redesign project. My responsibilities, as an architect, are divided between back-end duties (e.g.: design reviews of enterprise components) and participating in review sessions of many artifacts of Information Architecture and Content Strategy delivered by an external vendor. I realized then that it might be worth to write a brief for project members about the origin of these artifacts and some of the decisions around user experience; a Mental Model.
Two books were used as primary sources of this brief which I definitely recommend to every information architect, web designer or project manager; Mental Models by Indi Young and The Elements of User Experience by Jesse James Garrett.

"The deepest form of understanding another person is empathy which involves a shift from observing how people seem on the outside to imagining what it feels like to be them on the inside".¹

Empathy with a person is distinct from studying how a person uses something. In the context of application design, empathy extends to knowing what the person wants to accomplish regardless of whether he/she is aware of the solution.
Mental model gives one a deep understanding of people's motivations and thought-processes, along with the emotional and philosophical landscape in which they operate. It's simply an "affinity diagram"² of behaviors made from data gathered from audience representatives.
Most research techniques can be categories into three groups (Table 1). Mental model is a generative research technique that allows researcher to create a framework based on data from participant. This framework can be used to guide information architecture and interaction design. Aligning functionalities in a proposed solution with mental model will depict gaps and how well features and functions support users to achieve their goals.

Research Method	Techniques used	What is it good for?
Preference Opinions, likes, desires	Survey Focus Group Mood Boards Preference Interviews Card Sort Customer Feedback	Visual Design Branding Market Analysis Advertising Campaigns
Evaluative What is understood or accomplished with a tool	Usability Test Log Analysis Search Analytics Card Sort Customer Feedback	Interaction Functionality Screen layout Nomenclature Information Architecture
Generative Mental environment in which things get done	Non-directed Interviews Contextual Inquiry Mental Model Ethnography Diary	Navigation and Flow Interaction Design Alignment and Gap analysis Contextual Information Contextual Marketing

Table 1 - Research Types matrix

To create a mental model, one needs to collect actual users' perspective and vocabulary. Essentially, you interview users and analyze the conversations to create a diagram called Mental Model Diagram; a process of Interview-Comb-Group in which audience representatives³ are interviewed, interviews are combed for tasks⁴, and eventually grouped⁵ to form a diagram.

Why use mental models?
Three main reasons: Confidence in your design, Clarity in direction, and Continuity of strategy (3 Cs).

Confidence in your design
Mental model gives your team the confidence that what they design is founded on research. Management knows that product of that design will be a success. And since it respect some of users' philosophies and emotions it'll makes sense to them.
Mental model can be used to validate ideas and requests for change. If a change request doesn't match a behavior in mental model it can be adjusted or respectfully rejected. A mental models also helps in avoiding politics. It can be used as an impartial evaluator when it comes to discussions over design decisions; solid data replacing one's circumstantial interpretation of problems.
Moreover, mental models represent the entirety of each audience segment's environment. That is, mental model becomes a mean to distinguish among solutions that are required to provide good enough coverage and support to those segments. If there are a lot in common among audience segments, a single solution might suffice. On the other hand, distinctively different segment demands its own solution.

Clarity in direction
While designing a solution or product, not only you should care about user experience but also align design decisions with organization's business strategies. Another word, a potential design idea can't evolve in isolation. Thus, decisions about user experience ought to be part of a bigger scheme; the "Whole Experience". Essentially, a design decision should be assessed for its impact on all the ways an organization interacts with its users. Jesse James Garrett describes the phrase Experience Strategy accordingly: Experience Strategy = Business Strategy + User Experience⁶. Mental model helps you discover the gaps in existing user experience considering your business strategy and, vice versa, find out what your business strategy looks like with existing user experience.

Continuity of strategy
Since mental model provides a clear direction, it naturally becomes a mean to prioritise solutions. Now that you know how your business strategy should look like to support users better and sustain⁷ (or what the gaps are in users' whole experience with your organization) new ideas will begin to emerge and some solutions no longer make sense or pushed further down the solution stack. In summary, a mental model with which solutions are aligned becomes a strategy roadmap.
Furthermore, a mental model becomes a place where decision history and rational is recorded. It helps you to preserve internal knowledge and becomes a foundation of decisions to come.

---

<sup>1. "Difficult Conversations" by Douglas Stone, Bruce Patton, and Sheila Heen ↩
2. http://en.wikipedia.org/wiki/Affinity_diagram ↩
3. You'll have to start with finding what's called "Task-Based Audience Segments". The process involves finding groups of people in your audience who do similar things. From each group, depending on research project's scope and stakeholder's priorities, a few types of personalities are chosen to represent it. That follows a series of recruitments to find actual people who meet the criteria and are elaborate enough for interviews.↩
4. Finding tasks is not as simple as finding verbs in sentences. People aren't always specific in conversation and use things like tone of voice and gesture to depict a meaning. In this context, "task" refers to everything that comes up when a person accomplishes something; actions, thoughts, feelings, philosophies, and motivations.↩
5. Tasks are then grouped to towers and towers are grouped to mental segments of a mental model diagram.↩
6. http://blog.jjg.net ↩
7. Sustainability may not always be a very important criterion. However, the cost of support for an organization without clear experience strategy could bring it to its knees. In the context of application development and maintenance the cost of support includes frustration and job satisfaction rate of staff at all levels and consequently innovation rate. For example, in public sector related businesses, lack of innovation and use of modern technology is recognized as an important issue (Citizen Experience: Designing a New Relationship with Government).↩</sup>

Fact checking of an Agile development exercise

Recently I have been working with a development team on various sub-projects of a bigger project. New features were being introduced in form of new sub-projects and the team was eager to adopt Agile development. So we decided to do so in one of those sub-projects in order to get them familiar with the concept and hopefully apply it to all the future development projects.
I’ll briefly elaborate the conditions in which the development of the agile sub-project and a similar non-Agile project have been carried out, list their outcomes and leave the judgment to you. 

Project A:

• Scope is small.

• Requirements are captured in form of detail writing; provided by the Product Management team. (Took them one week to finish). This was the usual practice in the entire company. That is, no development starts without a written spec.

• The development team goes through the document (which is at least 50 pages) to find out the areas that are not very clear and clarify them with the PM team. They also estimate the development time for the features requested in the sub-project and negotiate the features with the stakeholders (A lot of buffer is used in estimates to mitigate risks).

• The development team shares the requirement with the Q.A team and starts development. Whenever a major feature is developed (iteratively) development team releases the unit-tested code to the Q.A team. This goes until the sub-project is complete. No change request is accepted while development is ongoing.

Project B:

• Scope is small.

• Requirements are captured in form of Sketches and Domain Models along with a list of identified functions (the preliminary copy was ready in three days). The development team and Q.A team have a couple of meetings with the Product Management team afterward to make sure they understand the models and the priority of the features. They start then designing the overall architecture with the help of Architecture team, finding the reusable components and developing the required base code while the Product Management works on the detail of some of the high priority features. Q.A team develops test plan and required test cases. These three teams constantly update each other during this process.

• Product managers evaluate the prototype and come up with a list of adjustments. In the meantime, Dev and Q.A teams study the detail document of the high priority features provided by the PM team to come up with more accurate estimate for high priority features.

• Teams discuss the changes, the detail document and the estimates.

• Dev team continues the development to solidify the architecture and frequently releases the developed and unit-tested code to the Q.A team to integrate and test. When all the bugs are resolved for each build, it will be released to the product managers for evaluation and assessment.

• Product managers can ask for change before the architecture is frozen which usually happens after the second release. In contrast, the Dev team has the opportunity to negotiate features.

Outcome of Project A:

• Some features could not make it to the deadline and some were not accepted by product managers as they were misunderstood by the Dev team.

Outcomes of Project B:

• Estimates were ready earlier and more accurate, too, as they were provided based on the actual development work that the Dev team had done.

• More angles of requirements were clear to Dev and PM teams because of the presence of the Q.A team in all the discussions from the beginning. Amazingly in some cases Q.A team members knew more about requirements than even PMs. That’s mainly because they have been testing other sub projects and are as familiar with overall requirements. Besides, they always ask the best questions. I believe that’s because they think about test cases and scenarios in advance.
• PM team was very happy about the outcome since all the important and high priority features that could finish in the given time and were agreed upon, were present and entirely tested. They were also happy about the fact that clients could start adoption of new features earlier.

I don’t think I need to explain which project was more successful. 

Before closing this post, I'd like to highlight a few of the pitfalls of agile development that I see or hear frequently.

• Pure modeling and sketching is not always a suitable way of requirement gathering. If you have distributed teams, challenging stakeholders or very complex requirements then you might want to spend a bit more time digging and documenting.

• If you are using TDD (Test Driven Development), it doesn’t mean that you don’t need a Q.A team or downstream black box testing; no matter how much developers may write unit tests and run white box testing.

• Change Adoption doesn’t mean that after every release stakeholders can come up with change requests. Change can be accepted and handled before the Architecture is stable. So it’s the development team’s responsibility to release the code as frequent as possible in form of an executable application to the stakeholders and it's stakeholders’ responsibility to assess the released application and come up with change requests as early as possible. That means, if you have a stakeholder that has no idea what he wants (and believe me, there are such stakeholders) you need to spend more time building prototypes and exploring requirements before you stabilize the Architecture.

• The project that was chosen for the team to exercise Agile development was relatively small. That’s because it was their first time doing iterative development in Agile manner and I wanted to mitigate potential risks imposed by failure of the project. Also, they had an agile practitioner in their team; me! Don't do this without a coach.

IT Architect Regional Conference ends

I wanted to write a quick one about the IT Architect Regional Conference SEA which was over yesterday. One of the questions I got a few times was that how one becomes a software architect.
Well, the quick answer would be that you need to realize that architecture design imposes different kinds of challenges compared to software development. If you become a senior developer it doesn't necessarily mean that you can get promoted to become an Architect. Today that forms one the IASA's missions; to tell everyone in the IT industry that Architecture is a profession of its own.
I, personally, started by reading a lot of books about software architecture or the industry in which I was working. That is, if I worked for a company in supply chain industry, I not only read a lot about SOA (widely used in that industry) but also about SCOR. This was happening when I was doing development works as well. While I was developing applications, I thought about various aspects of the architectural work behind it; its component design, development processes in place, risk mitigation, chosen technology(ies) to develop that application with, the roadmap that was set in place to realize the benefits of that application, user experience, etc.
If you are a developer and want to become a Software Architect, invest in it. As I mentioned being a senior developer doesn't make you a Software Architect.
This doesn't mean that being a Software Architect should keep you away from the details of development works. In fact one of the important things that a software architect should do in "Proper" iterative and incremental development approaches (which are perceived to be the right approach in developing software applications) is to build application's architecture in early stages of development in form of an executable application (sometimes a throw away). A software architect can build an application only if he/she possess development expertise and is familiar with technologies.

W.C.I.T 2008

Hi

I'll be a delegate in W.C.I.T 2008 (World Congress on Information and Technology) which is being held in Kuala Lumpur, Malaysia this coming May.

See you all there.

IT Archiect Regional Conference begins

Hi folks,

I'll be speaking in one of the sessions at the IT Architect Regional Conference of South East Asia in Malaysia. Here is the link to the conference home page:http://www.iasahome.org/web/itarc/KL

The topic's title in the website is "Managing Changes and Mitigating Risks in Software Development" which is not correct. The topic that I intend to talk about is "Planning Iterative Software Development Projects". I believe Planning is one of the areas that is not broadly explored in Agile development community and that's why I chose to talk about it.

See you there.

How to deliver real value using Iterative and Incremental Development

The benefits of Agile development approaches in which developing software applications iteratively and incrementally is an important and inevitable principal are questionable if deliverables produced during the project do not introduce any business value.
If a development project doesn’t deliver business values incrementally iteration by iteration then it’s executed in a value-neutral setting in which

• requirements are treated as equally important
• code delivery is as important as the delivery of an usable system
• implementing largest number of requirements possible become more important than delivering desired outcome of the project

In another word, the development team iteratively implements the requirements rather than iteratively solve problems. Although project members feel that they are iterating successfully, they never make the transition from iteratively addressing the technical risks to iteratively delivering usable versions of the system that provide realizable business benefit.
This will raise the question that how we exactly have to develop requirements iteratively to secure delivery of the actual desired outcome of the project. To answer this question we need to define the best possible deliverable which assures the stakeholders that development is progressing toward creating a system that is aligned with their actual requirements. That deliverable is nothing but an executable that its features represent a collection of end-to-end behavioral threads of system usage. In a simpler word, the output of each iteration should be an executable that possesses three very important characteristics:

• Should cover a set of the actual “behaviors” of the system that are most important to the stakeholders at that point of time
• Should keep the confirmed “behaviors” that are implemented in the previous iterations
• All its implemented features composing desired “behaviors” should be working integrated smoothly

You might’ve noticed that I put the world behavior in the quotes. What I am trying to emphasize here is that it’s not important how many features you implement. What’s important is that the implemented features form desired behaviors of the system and do something useful for the business. Another word, only those features that are really needed have to be implemented. Statistics data such as CHAOS report, as I’ve pointed out in another article at http://www.iasahome.org/c/portal/layout?p_l_id=PUB.1008.62, show that a high percentage of implemented features in many projects are never used, even in those projects that are declared successful.
Now that we have set the ground rules and defined what it is that our projects iteratively have to deliver, let’s take a look at the ways of doing that.
To achieve the value delivery, we need to have a way to work around the end-to-end behavioral threads (independent threads of system usage) or what is called scenarios. “Credit Check” and “User Registration” are examples of scenarios. They are independent threads of system usage that tell stories about how for example a user registers and what other things might happen along the way.
The obvious question here would be “How to find the best scenarios and in what order they have to be implemented?”
As I mentioned above, scenarios are stories and finding scenarios is about the requirement gathering skills that is far beyond the scope of our discussion here. But as the principals of Iterative development state, scenarios do not have same level of priority. With that in mind, at every iteration we need to find those scenarios that have the following characteristics:

• They are addressing the most important goals of stakeholders at that point of time
• They are addressing the most pernicious risks in the project

Project risks threaten the project's ability to deliver the desired outcomes in a timely and cost-effective manner. Technical risks can be mitigated by choosing scenarios that force the confrontation of the risks. By mapping the risks to scenarios that mitigate them, iterations can be planned to ensure that every iteration reduces project risk and increases the business value realized from the solution.

Relationship between Risks, Scenarios, and Desired Outcomes

So, for example if in our earlier example of user registration, the user information needs to be registered in a LDAP database, the development team need to find risks that are mapped to this scenario, for example limited knowledge of technical team in working with LDAP databases, and rate those risk. If the level of their threat is high then they have to be implemented before other less important risks.
I must mention that addressing risks is not less important than implementing important scenarios for stakeholders. What if a scenario which imposes a big risk is not important when you are in the third iteration and when it comes close to the end of the development a change in business strategy makes it an important scenario? This is a rare case of course. But it can become a counterproductive situation in a project. A smart architect keeps his/her eyes on those scenarios and related business scenarios and as the iterations pass by he/she tries to decide whether the stakeholders’ attention is turning toward those scenarios. Some architects assign a very small team (with One or Two members) to work around some of those risks simultaneously so if their related business scenarios become more important they don’t impose a big danger.
The widest used technique for modeling scenarios is Use Case Modeling. Use cases structure and group requirements by user goals and business value. A use case contains a set of flows, which describe the interaction between the system and its actors. The set of flows provide a map of how the system can be used to meet the goals of the use case and a structured way of describing the set of end-to-end scenarios needed to drive the iteration planning and the development of the software.
A use case captures a set of scenarios, each of which is described by one or more of its flows. All use cases contain a basic flow, which describes the set of normal, "happy day" scenarios. They also contain a number of alternative flows to describe variations, extensions, and exceptions to the basic flow. These can be combined with the basic flow to describe all the other possible scenarios. So, a scenario can be considered to be defined by a use case's basic flow plus zero or more of its alternative flows.
Besides, almost all of the case tools that I have seen out there have a tool for drawing and managing use cases. It seems that it has become a unified way of defining and managing scenarios.

Summary

Nothing but an executable code depicts the actual progress of a development project. But not every executable does that unless it implements end-to-end behavioral threads that deliver most important requirements of business. This doesn’t mean that there shouldn’t be any documentation. It has to be, but as much as it’s required.


-- This post has been published as an article on the ITtoolbox web site as well.

Choosing the Appropriate Software Development Process Framework

Hi folks,

Here is another published article of mine on IASA's web site. I hope can keep it up.
This is the direct link and this is a link through IASA's content repository.

I also figured out that you can not post any comment on the IASA's forum unless you are a member. So please do it here whatever it is.