Building Conceptual Models and Gathering Requirements for Successful User Experience Design (9/13)

The Roots of the “Conceptual Model”

In the before time, in the long long ago, giant clunky mainframes and a distributed model of computing reigned supreme. The GUI (Graphical User Interface) was a natural progression of computing, particularly as the move towards individual personal computing afforded more capabilities and actions from users. Enter the Xerox Star in 1981, a still clunky but beautiful advancement in to the future of direct manipulation. Developed at Xerox PARC, the Star was an impressive quantum leap forward in human-computer interaction.

Words AND Pictures? A cheesy 80s ad sells the direct manipulation features of the Xerox Star. It wasn’t pretty but many modern conventions such as folders, windows, and icons were introduced at this time and remain with us today. (source: Wikimedia commons)

The Star introduced the desktop metaphor, which included abstractions of common office objects like files, folders, and trash bins — Skeuomorphism as it is known today. This made operating the system reasonably intuitive for the layman. WYSIWYG (What you see is what you get) editors allowed users to avoid the abstractions of low-level programming languages and directly manipulate documents, drawings, graphs, etc allowing for a far better user experience. For it’s time, and even still today, the Star was quite sophisticated.

How was it that this breakthrough was accomplished? In an interview with David Liddle, the lead of the Star development team, he attributed much of the success to the user’s “conceptual model”. In his words, a user’s conceptual model “represents what the user is likely to think, and how the user is likely to respond” [2] By paying attention to this, the system could be designed to make interaction as intuitive as possible. I found this perspective particularly ahead of its time, as there would continue to be poorly designed software for decades to come. Liddle even criticized the Star’s successors, Windows and Macintosh most notably, as failing to capture the same attention to detail and respect for the user experience as the Star. I particularly liked this quote by Liddle -

“Software design is the act of determining the user’s experience with a piece of software. It has nothing to do with how the code works inside, or how big or small the code is. The designer’s task is to specify completely and unambiguously the user’s whole experience.”

It seems this perspective has only been truly respected in recent years, with the rise of the “UX” design profession and much more focus on design in technology companies.

Gathering Requirements for Successful UX Design

Gathering requirements is a key factor in determining the scope of a project, and ensuring that the software meets user needs. It is the basis of how a conceptual model is determined. There are two types of requirements, functional requirements, which capture what the product should primarily do, and non-functional requirements which involve various other aspects of the software.

Surveys, interviews, focus groups, and ethnography are just a few of the methods for gaining qualitative and quantitative data that will lead to functional requirements. They all have advantages and disadvantages. For example, surveys are very general and can be helpful to gain a lot of superficial data at once, however more in-depth studies like focus groups and ethnography may be necessary to really determine the use cases and build detailed requirements.

Use cases / user scenarios are important and ensuring that all of your bases are covered when designing sofware. What are the possible tasks that a potential user will need to accomplish? It can range from a few tasks, to literally thousands, depending on the complexity of the software. Good example of a use cases would be -

User needs to be able to add file attachments to messages

User needs to be able to add and remove channels

User needs to be able to direct message team members.

This screenshot is from the very popular web application Slack, which allows teams to be more productive and avoid emails.

By acknowledging all of the use cases, the design of the software can capture all of the desired tasks and outcomes that may rise up in its use. Sometimes, however, there are more complex actions and strings of actions that a user may be wanting to accomplish. This requires a user scenario which may involve a number of tasks and would be more specific. An example might be:

Brian needs to search for an old presentation he uploaded a few weeks back on the “Design” channel. He needs to download it, work on it some and then private message his manager Scott and upload it so that only he can see it.

This involves a series of tasks and because it is a fairly common scenario, special care must be taken in ensuring that these tasks are able to be completed quickly and easily. When there are issues in a user a completing task(s) it may be helpful to conduct a hierarchical task analysis — a more in depth study of how a task is a comprised of a series of decisions and subtasks. By doing a task analysis, it can become more clear what the user is struggling with or what flaw in the system is preventing them from accomplishing their goals.

In summary, building a strong user conceptual model is key in developing an excellent user experience — and that conceptual model is largely based on research and gathering requirements from users. To truly practice “human-centered design” there should be just as much, if not more attention payed to this phase of a project as the actual development of it. With the maturity of the computer industry and emerging disciplines like UX, this is finally being understood and respected. It will hopefully usher in a golden era of well-designed applications and tools that improve people’s lives.

References

  1. Terry Winograd, The Alto and the Star, in Winograd, T., Gordon, P., eds, Bringing Design to Software, New York: Pearson, 1996.

2. David Liddle, Design of the Conceptual Model, in Winograd, T., Gordon, P., eds, Bringing Design to Software, New York: Pearson, 1996.

3. Yvonne Rogers, Helen Sharp, Jenny Preece (RSP), Interaction Design: Beyond Human-Computer Interaction, 3rd ed, Wiley. 2007, Chapter 10, Identifying needs and establishing requirements.