Navigation

Apple desingers knew how important navigation is. Let’s take iPod as an example. They came up with idea than favorite mp3 should not be more than 3 clicks away. So in just 3 clicks user is able to navigate through system to his/her favorite music. This is quite powerful feature and proof of importance of well designed navigation.

From my personal experience no effort at all is put into designing a navigation. Maybe because in case of business applications with lots of forms it is just minor concern. Navigation is just a product of grouping requirements together and interface mockups. Maybe projects I’ve worked on had no budget and time for it. Whatever the answer is the navigation is there and maybe because it is accidentally fine it is not noticable.

It is surprising that good navigation can be achieved using really simple and really cheap techniques like card sorting.

Card sorting technique goes like this:

1. Determine list of topics
2. Make cards
3. Select participants
4. Run session
5. Analyse groupings

During the session participants have to rank cards according to their intuition. When finished, participants are asked to put labels on each group. Grouped topics show potential structure for the navigation.

The only tricky part about this technique is the requirement for the participants. They should be representative users. I think this technique could be used even without perfectly representative users internally in the company and still yield useful results or at least more useful than coincidental arrangement of topics.

Product style guide

Product style guide is the document compiling all the information concerning a software product UI. It consists of information how elements like controls, dialogs, statuses, notifications and pretty much everything else should look like.

To me it seems like very useful document especially when I look at my past experience. Even though we had some design done by graphic still some of the missing parts like notifications differed between screens. Sometimes notification were at the top of the form, sometimes below. Sometimes action button was labeled just “Save” and sometimes “Save changes” even though it was used in same context. We had to spent some time fixing these inconsistencies. Having style guide would be much help. It would be good to know how to present list of things, how to present descriptions of items and many more.

I am sure that time spent developing product style guide would be less costly than time required for developers to fix minor incosistencies. Think about your product. It is surprising how much time you spend after all works but still does not look good enough. It takes a lot of time to make all UI sound when there are no clear guidelines or when they arrive really late after most of the work is already done. Having product style guide beforehand would reduce greatly simplify whole process and also decision making of developers.

Now that I am thinking about it over the time we arrived at implicit style guide. Mostly because some useful components like paginated lists with detailed view were developed and incorporated by the rest of the team members. It would be much better to have explicit document.

However there are some problems. Requirements are changing, sometimes it requires change to presentation of things. For example from radio button group to dual multiselection list. It is not pragmatic to develop style for every possible GUI element. Also not all elements are known. That means that development of product style guide should be iterative. It could start with some common base of elements when mockups are done and then it would require adjustments when new elements pop up.

You probably already have some mental model of this posts just by reading its title. You might think that you are going to read something about software design, good practices, patterns and such because you know that this is developer’s blog. If you don’t know what mental model is, don’t worry, you will soon.

Today’s post is about design of the whole product (whatever it may be) not just software stuff. Concretely I am going to discuss importance of mental and conceptual models in the design process. Let’s start by getting on the same page with two definitions of design.

[design is a] combination of aesthetics,
economics, usability and manufacturability

Design is the creative process in which we
use our intuition and analytical ability to
understand the opportunities and
constraints business goals, competitive
markets, customer needs, and technologies
present, then envision, communicate, and
realize practical solutions that meet
customer needs and create business value.

During design phase desingers think of what product should do and how it should be interacted with. They think how elements of the product are manipulated in order to perform some task. This all together is called product concept.

Mental model

Starting with definiton, following with example.

A mental model represents a person’s thought process for how something works (i.e., a person’s understanding of the surrounding world). Mental models are based on incomplete facts, past experiences, and even intuitive perceptions. They help shape actions and behavior, influence what people pay attention to in complicated situations, and define how people approach and solve problems.

Definition of mental model is rather simple, but it can be even simpler given concrete example. Let’s say that I tell you that I’ve made scrambled eggs. Based on that information you probably can think of the process of making scrambled eggs. Based on your own kitchen experiences you know that I had to take eggs from the fridge, put some butter on the pan then break eggs and stir a little bit so it will not stick to the pan. Instead of butter you might think about olive oil or something else. The most important thing in that example is that you have some model, some expectations, some thought process about cooking scrambled eggs. You don’t have complete information so you have some assumptions – maybe even more of them than I described if you like fancy eggs. That mental image of the process is what we call mental model.

Conceptual model can be derived from product concept. Conceptual model is the actual thing given to the user. It is what has been designed and then produced and showed to the user. Now that we know about two models we can discuss how these two relate to each other.

Some say that a well designed product should have conceptual model which conforms to the user’s mental model. I see one problem right there. If designers strictly follow user’s mental model then there might be no room for any innovations. I would argue that mental model is constraint on innovation because if you want to create a product which will revolutionize market and greatly improve current users’ experience, but interaction with it is completely outside of bounds of users’ mental model then you have a problem of changing users’ mental model so that it fits your new product.

Sometimes users are just used to poor experience and do not expect anything much better. Their expectations will not rise to the completely different level. Henry Ford knows something about it.

If I had asked people what they wanted, they would have said faster horses.

Users of means of transport had mental model of using horses. For them, a better product would be stagecoach with more horses. They would not think of something like a car, but designer had. New product which was outside of user’s mental model changed its users. That’s why design should not always be about going exactly for the mental model of its users because users do not know what is good for them until they see a next best thing.

On the other hand sometimes mental image can be just too strong and changing it seems impossible. I know at least one example from real world.

Mental model of Windows user

Windows 8 introduced change to the start button – it has been removed. Windows users have mental model of using it. Everyone know Start button.

In this example we can see older Windows user who has mental model about the start button. End result? Take a look.

Video shows how strong and deeply rooted in one’s brain mental models can be. Dramatic change to the product might cause trouble to some portion of users who will not be able to breach to gap between their mental model and conceptual model.

What can be done about it?

Such sudden change in the product is not a good idea without proper transition process. I could think of some introductory videos or maybe quick interactive tutorial like in games. When Google changed gmail then there was some help and tips about what changed first time you logged into it. There was information about what is new and how to do what. It looks like a very good approach to the problem. I think of myself as be more of advanced user so I could probably adjust my mental model on my own but having a quick overview of the changes presented nicely was a pleasent experience.

Summary

Mental model of the user is important but let’s not get crazy about it. There is no single truth about what designers should and should not do. In some cases sudden shift might work and in others it might not. One thing to remember – you should know what is the mental model of you users. Based on that knowledge you should design your product to either meet that model or plan how to change it so it satisfies your product’s conceptual model.

“Metaphor, myth and mimicry: The bases of software engineering”

For most of the first half of article author discusses “software engineering” metaphor, and whether some of the concepts from engineering field have sense in software development discipline. Author states that language used has impact. Metaphors come with some linguistic baggage but can lead to perceiving things differently which itself can advance theory and practices of software development.

In my opinion it does not matter whether someone disapproves calling software developers engineers. That word indeed comes with a lot of baggage. I am an engineer and if I say only that then people might think that I know how to make a shed. They get back on track when I add that I am software engineer. Obviously some things have changed in perception of software engineers since author published article, but even still the word ‘engineer’ alone comes with connotations. In the end it does not matter, all that matters is working software. In order to get to that point one has to face problem of software requirements which is being discussed in second half of the article.

At this point it is worth noting article was published more than decade ago which in this area seems more like a century. At the very beginning Bryant uses expression “requirements phase” and after that discusses multiple nouns that can be added before or after word “requirements”. I am more interested in the word phase. Nowadays it is obsolete to talk about phase. From my experience requirements are being gathered and changed during whole development process. It is hard to talk about any time-boxed phase. Let’s keep that in mind and go on further with analysis.

Bryant brings up two communication schemes presented by Reddy. One called toolmakers paradigm and the other conduit metaphor. Bryant says that “The terminology in current use is heavily slanted towards the conduit metaphor”. Then he says

“How much more effective might the requirements process become if viewed in terms of a dialogue between distinct parties, each with their own assumptions and cognitive processes; where achievement of mutual understanding is a prime objective, but one which will not be reached without communicative effort from all participants” and follows with “perhaps a change in the metaphor about communication during the requirements process can have a similar impact.”

I think that a lot changed in that matter. I would say that both parties understand the problem of communication and requirements. Nowadays it is more like “toolmakers paradigm”. There are movements like DDD which put special emphasis on understanding domain of the problem. It comes with new terminology like “knowledge crunching” which might be more suitable to toolmakers paradigm. However even though DDD is well known it is not very well understood by majority of developers. Moving to other example, agile methodologies help with requirements in a way similar to showing blueprints like in toolmaker’s story, but here blueprint is a working software according to some requirements which will change. Change of requirements is anticipated from the start. If the communication was wrong, if there were misunderstandings then it is nothing unexpected. It is the norm. Requirements change along with deeper understanding of domain by developers as well as clearer vision of what client really wants. However it is not always the case that agile methodology is used because it requires client to actively participate. These clients have mindset focused on “achieving mutual understanding” because this is what is most economically reasonable. What about others? Some of them live in world where communication is done only in one direction and only through written documents. In conclusion it is getting better but there is still a long distance to go.

Bryant says:

“The prototypical engineer is a myth; an influential and important myth, but nevertheless a myth. We must be careful not to mimic the myth; taking engineering as something ‘natural,’ but devoid of explanation.”

Once again, for me it’s just a fancy word which labels me as technical person and professional. Sometimes software developments seems like an art which has very little with engineering. I do not feel any constraints implied by that word. The best I can do is to just improve my skills which help with getting my job done. It does not matter if these are technical skills or not.

“We do not have to preclude any of the positive aspects of the engineering metaphor, but we do have to move forward recognizing its constraints and deficiencies.” “The introduction of the engineering metaphor moved us forward in the critical activity of developing a discipline for software development; we now have to move this critical activity forward to the next stage.”

I agree and I think that we have already moved beyond that metaphor to something more substantial than engineer.

In summary I think we moved to that point where developers are pragmatic enough to not care about labels pinned to them. If I had to choose the current metaphor I would say that “Software craftsmanship” is the most adequate. Maybe that’s the next stage Bryant wrote about.