The Usability Architect

UI Prototyping Series Part 3: Why Prototype?

2011-07-21T13:05:00.007+02:00

The forceful employment of prototypes would lead to situations, in which the development team could continuously present their interpretation of stakeholder needs and the corresponding design solutions to the client. People can much more easily articulate what they need by playing with prototypes. Prototypes can turn stakeholders into partners in a collaborative software-development process. Prototypes externalize conflicts and require stakeholders to handle trade-offs. The sooner individuals can access simulations of their requirements, the earlier they can recognize the need for modification and decision-making. This, in turn, decreases the risk of costly late-cycle changes.

The medium of prototyping is a means of communication that has been recognized by stakeholders of various disciplines related to the design of modern software systems. In software engineering, prototypes are used to verify functional specifications and models, as well as for understanding problems by carrying out user inspections and testing. In usability engineering, prototypes are recognized as an artefact for iterative UI design. They are employed for requirements analysis, producing alternative designs and for gathering user feedback. Here, the role of prototypes is therefore a particularly deep-seated method for propelling user-friendly development and is primarily related to the UI of a software product (Preece et al. 2002). In today's software market, usable products are desirable products. Providing task-adequate functionalities is mandatory, but there is great competition to deliver them with a high grade of usability. Ease of use therefore differentiates software products in a highly competitive market place. Ease of use brings an added value that culminates in a higher degree of customer satisfaction, continuing business and higher revenues. In addition, customer satisfaction provides market differentiation (Jones & Sasser 1995).

Literature:

Preece, J., Rogers, Y. and Sharp, H. (2002), Interaction Design: Beyond Human-Computer Interaction, John Wiley & Sons.
Jones, T. O. and Sasser, W. E. (1995), 'Why satisfied customers defect', Harvard Business Review, vol. 6, no. 1, pp. 88-99.
Memmel, Thomas (2009): User Interface Specification for Interactive Software Systems. Schriften zur Informationswissenschaft, Bd. 54, ISBN 978-3-940317-53-7, VWH Verlag

UI Prototyping Series Part 2: Prototypology

2011-07-21T13:01:00.007+02:00

In order to better incorporate prototyping efforts into software-development practice, several fundamental issues have to be addressed in order to identify the right prototypology, for example:

Appropriate fidelity. Discuss different fidelities of prototyping and their con-tribution to the software-development process with regards to the externaliza-tion of functional and non-functional requirements.
Pressure of time and budget. Determine prototypes that can be developed within time and budget constraints in order to overcome objections to early-stage prototyping.
UI development fragmentation. Identify the kind of prototypology (Schrage 1999) that can take client and supplier relationships into account and become part of contract-forming.
UI specification support. Consider forms of prototyping that can become rec-ognized as well-engineered models that evolve into specifications and final products.
Adequate traceability. Externalize the interdependency of models and design, turning the UI development into a transparent engineering process.

Literature:

Schrage, M. (1999), Serious Play: How the World's Best Companies Simulate to InnovateHarvard Business School Press.
Memmel, Thomas (2009): User Interface Specification for Interactive Software Systems. Schriften zur Informationswissenschaft, Bd. 54, ISBN 978-3-940317-53-7, VWH Verlag

UI Prototyping Series Part 1: User Interface Prototyping Disregarded

2011-07-21T12:42:00.004+02:00

Although prototyping is useful in any situation where a requirement is not clear, there are several reasons why prototypes are often disregarded as a valuable methodology in many software-development projects, for example:

Cost-saving measures. Requirements prototypes are usually throw-away products and are not expected to evolve into the finished product (Robertson & Robertson 1999). It is therefore likely that project managers save on their development, especially when the role of look and feel and usability is underestimated or misunderstood, and stakeholders are used to textual descriptions of requirements.
Form of contract. If an external IT supplier is assigned to design and code the software system, the production of prototypes is usually deferred until the specification sheet has been produced (Schrage 1999). The consolidated specification is usually necessary for forming a contract between client and supplier. It is unlikely that the supplier will start working before the specification is finalized.
Delaying influence. Even if prototypes are created during early stages, the chance of them having significant impact on the consolidation of written requirements is very low. Depending on the complexity of the software that has to be built and factors such as time and budget, building a first prototype can take (the IT supplier) several weeks, or even up to a month (Schrage 1999). This is mainly due to poor responsibility assignment and excessive up-front processes. Results are not likely to be received until there is no longer any opportunity for extensive changes.

Consequently, software developers tend to produce first prototypes very late in the overall process, if at all, although well-established lifecycle models do recommend it for the earlier stages.

Literature:

Robertson, S. and Robertson, J. C. (1999), Mastering the Requirements Process, Addison-Wesley Professional.
Schrage, M. (1999), Serious Play: How the World's Best Companies Simulate to Innovate Harvard Business School Press.
Memmel, Thomas (2009): User Interface Specification for Interactive Software Systems. Schriften zur Informationswissenschaft, Bd. 54, ISBN 978-3-940317-53-7, VWH Verlag

Agile Usability Engineering

2011-06-26T10:14:00.003+02:00

Increasingly, software engineering (SE) and UID have to cope with a shorter time-to-market, whereas the quality of the delivered software must not suffer. This continuous shortening of development lifecycles is a great challenge to both project management and the applied methods and tools. Therefore, many usability engineering (UE), UID and agile method experts have developed light-weight approaches or so-called Agile Usability Engineering.

The Spectrum of User Experience - UX Stress Fields

2011-06-23T15:02:00.012+02:00

I ran over an very interesting blog post from Oliver Reichenstein, published on http://www.informationarchitects.jp/en/the-spectrum-of-user-experience-1/.

Source: http://www.informationarchitects.jp

User Interface Prototyping - Low- and High-Fidelity Prototyping Today

2011-06-02T10:56:00.002+02:00

User Interface Prototyping - Low- and High-Fidelity Prototyping Today

View more presentations from Thomas Memmel

Rapid Mobile Prototyping with the iPad & iMockups

2011-05-22T08:51:00.005+02:00

A cool prototyping tool for wireframing of web- and mobile applications is iMockups for the iPad. Especially if you have one of the available sketching pens for the iPad, iMockups is a fast and easy way to express concepts and rough ideas. You can use it while you sit in a meeting with your client or you can capture interaction design concepts while you travel - thanks to the iPad.

The wireframes that you develop can be exported to image files or in the BMML-format of Balsamiq Mockups. This allows a further refinement of your mockups on the Desktop - without any media disruption.

I can recommend iMockups for the iPad to usability professionals who need to have a mobile application for prototyping or those who have fun in using the iPad on their job.

Link to iTunes: http://itunes.apple.com/de/app/imockups-for-ipad/id364885913?mt=8

Overview on Client Technologies for Usability Professionals

2011-05-21T09:21:00.001+02:00

I talked at SwissCHI/SwissUPA in April about client technologies (Thin, Rich, RIA) and the impact on the user experience. The talk and slides are in German.

Client Technologien - Ein Überblick für Usability Professionals

View more presentations from Thomas Memmel

User Interface Engineering Talk at FHWN in Switzerland

2011-05-20T08:57:00.003+02:00

I have had the chance to talk in front of students of the new iCompetence course of studies at FHNW in Brugg-Windisch, Switzerland. I like to share the talk with you (German).

User Interface Engineering Praxis

View more presentations from Thomas Memmel

Whitepaper on Client Technologies (in German)

2011-04-30T10:55:00.003+02:00

Based on a German UPA tutorial I held in 2010, I wrote a whitepaper for Zühlke comparing different client technologies in terms of functionality, usability and design.

Zühlke Whitepaper Client Technologien

View more documents from Thomas Memmel

UX and other disciplines

2010-11-18T17:21:00.003+01:00

In many situations you might need to explain what is the difference between UX, usability, interaction design and the many other terms that are around nowadays to describe what we do or don`t do.

This is why I decided to remember me, and maybe you as well, of the drawings from Dan Saffer.

Source:
http://www.kickerstudio.com/blog/2008/12/the-disciplines-of-user-experience/

New UX book about to be published: UX Best Practices How to Achieve More Impact with User Experience

2010-11-15T15:17:00.003+01:00

Abstract
Significantly increase your impact on product development with tested and validated User Experience (UX) techniques. About the book: "UX Best Practices, Processes, & Techniques" is a compendium of proven UX strategies, based on the real experiences of a global set of UX gurus. Each chapter focuses on specific or collections of UX practices implemented in real-world scenarios within global companies such as SAP, Siemens (Germany), Lenovo, Ping An, Tencent, Changhong (China), Intuit (US), Swiss Federal Railways (Switzerland). This definitive guide is filled with tested, validated, authentic best practices, processes, and methods for successfully implementing and integrating UX in any development initiative. "UX Best Practices, Processes, & Techniques" features more than 20 global contributors who present cutting-edge approaches. It focuses on a unique practice or set of practices in each chapter implemented in an actual organization. It includes real-world examples that demonstrate how moving UX up front in the development cycle can improve quality in measurable ways and positively impact the bottom line. It contains techniques you can easily apply to your own development initiatives. In-depth coverage includes: Integrated & Established UX Process; Utilizing IBM's IPD Process; Becoming More User Experience Focused; UX Process with UI Widgets & Systematic Localization Capabilities; UX for Product Innovation for Medical Devices; Maintaining the Vision from Start to Finish - Front-End Solution Process; User Experience & Agile Development; Design Thinking; UX Targets & UX Priorities; UX Brief; UX Prototyping; UX Patterns; UX KPIs for Product Improvements; and, Setting Up & Sustaining User Experience's Impact.

Buy on Amazon:
http://www.amazon.de/Best-Practices-Achieve-Impact-Experience/dp/007175251X/

UX Storytellers published

2010-11-04T06:40:00.003+01:00

In this free eBook, ‘UX Storytellers - Connecting the Dots’, 42 UX masterminds tell personal stories of their exciting lives as User Experience professionals.

The book brings together authors from around the world who paint a very entertaining picture of our multifaceted community.

Whether you’re a usability pro or a student of interaction design, whether you’re a senior information architect or a junior UX designer, you will find 42 entertaining stories in this book told by leading experts from all over the globe.

Get the book:
http://uxstorytellers.blogspot.com/2009/01/ux-storytellers-connecting-dots.html

Agile & Security

2010-10-31T21:33:00.001+01:00

Jonas Trindler wrote a very interesting article about the integration of security into agile software development (Computerworld, Number 19/2010). Security is a non-functional requirement, which is especially important since many companies provide services on the internet or run highly networked business applications.

But as with many non-functional requirements, many projects are executed with an eye on security. One of the main reasons is that the costs for missing security mechanisms are not realized until it is too late and a system was successfully attacked. In other words, the added value of security is often not evident because the benefit is not immediately obvious. Adding security functionality to a software application therefore is like spending money for a insurance policy. It makes you being prepared for a worst case scenario or in the words of Mr. Trindler, an “abuser story “ (i.e. a user story with bad faith).

Security requirements are therefore very similar to usability requirements. As long as you do not show your application under development to the end-users, you do not see the need for usability testing and user-centered design. And, spending money for usability experts and their mumbo-jumbo will not prove to be beneficial until your application is tested by the target user group. Hence, usability methodology also is like insurance for increased efficiency, effectiveness and user-satisfaction.

As I already outlined in previous articles, agile software development can be exactly the right environment to iteratively take care about non-functional requirements such as usability. You can setup parallel track development to integrate usability methods into the sprints. Releases of the software can be tested after every sprint and usability defects can be repaired quickly.
As with usability requirements, security requirements can be included in the backlog and get implanted as prioritized by the product owner. For both kinds of non-functional requirements it is much cheaper to consider their impact as early as possible. They are typically more complex and cannot be implemented during just one sprint. Here, the sustainable implementation of security functionality can for example be compared to the implementation of a usability concept or interaction design that is relevant for the whole application.

In Scrum, the definition of done can be extended by both usability and security criteria. But the extension does also mean that you need to have the right people, who take care of the criteria, on the project. That is easier said than done. If you need experts for security and usability, you either have to have additional team members or you have to hire software engineers that understand both concepts (e.g. because of professional training). This will make the staffing for an agile team very demanding.

Secure and user-friendly software is neither a bargain nor does it come as an incidental by-product.

GUI Development with Eclipse RCP

2010-10-31T15:45:00.001+01:00

Eclipse RCP is a frequently used alternative to Java Swing for GUI development. Eclipse RCP offers its own standard widget toolkit (SWT), which already contains a lot of functionality as a GUI sandbox.

The GUI elements you develop with SWT are rendered natively by the OS, which consequently determines the look and feel of the application. The native GUI rendering is very helpful when performance is an issue.

From development with Java Swing, I can remember several GUI editors, of which most are already outdated: IBM Visual Age for Java or Borland JBuilder. Both were widely replaced by Eclipse, which is among the main reasons why Eclipse RCP also became popular as a GUI framework. As with other GUI editors, the code generated by the GUI builder is not a 100% perfect and needs some refactoring. But it is very helpful to place and arrange GUI elements. With GUI frameworks such as Nebula (http://www.eclipse.org/nebula/), you can easily extend your application with modern and interactive GUI elements. Naturally, you can also develop your own custom widgets from the scratch or based on those from open source GUI frameworks.

Eclipse RCP does not yet offer support for the integration of design artefacts as you might know it from the Microsoft Expression Suite or the JavaxFX Production Suite.

Altogether, Eclipse RCP is an attractive technology to develop modern rich client applications. Technical pitfalls and issues are not part of this post, but the visual appearance of what the applications can develop with it. From this point of view, Eclipse RCP applications are powerful and offer much interactivity. Nevertheless, most Eclipse RCP applications I have seen rather have a technical and unemotional look & feel.

For the future of GUI development with Java technology, Eclipse RCP will stay important and an alternative to Java Swing in many ways. The framework already offers much GUI functionality out of the box. With regards to aesthetics and UX, I expect Java Swing will soon take advantage over Eclipse RCP through Oracle’s plans for JavaFX 2.0 and the associated integration with the Java API.

Not a Recommended Reading: User Experience Re-mastered

2010-04-27T10:05:00.004+02:00

Full Title: User Experience Re-mastered: A Finely Tuned Guide to Creating the Best Design Every Time: Your Guide to Getting the Right Design

This is an edited book with chapters contributed by different usability engineering and user experience experts. The chapters are extracts from the authors’ own books and therefore many parts of the book will sound familiar to you.

In many ways, it’s just old stuff in a new wrapping. This is for example true with regards to the title: the book rather provides an overview on today’s usability engineering tool-box and design just plays a very little role in this book. Maybe the editors decided to title the book with user experience because it’s the more modern term for creating usable and user-centered software systems. As “design” is something many people think about when they read the term “user experience”, this people would be very disappointed with this book. It is definitely not about designing the user experience. Nevertheless, under the surface you can still find a good book, if you buy it with the right expectations. The combination of good content from different experts in the field makes it a valuable piece of basic HCI literature, especially for UX newbies or HCI students. But it is not a book with breaking news about new methods and tools. The presented methods are all water under the bridge now. And of course, if you know the different chapters from the original books already, then you will most probably not be among the buyers of this work.

Contents

The first chapter seemed to be a little bit outdated on the first view. Its from Jakob Nielsen’s book “Usability Engineering” and the content therefore is about 17 years. But after all, I was pretty surprised how much of his words are still very true and state-of-the-art. If you regard it as a congenial repetition on the corner pillars of usability, then you will have fun in reading this introduction chapter. Otherwise, you will be bored from the very beginning.

The second chapter is about user needs analysis. The authors provide an overview on fundamental methods for user analysis. They have a focus on hierarchical task analysis, which is why they tend to lose sight of use cases (and other important means for modeling). They are only shortly mentioned and this gives in my opinion a wrong impression about their weight in software design. The content of the second chapter underlines that the authors might not have realized that usability and software engineering have to become more and more integrated and that methods of both worlds have to be combined in designing a total user experience. Again, this chapter is somehow old-fashioned and accordingly the second chapter is not really more than a basic schoolbook introduction.

The following chapters present some important means for usability modeling and generating ideas in more detail. Chapter three is about card sorting, which already made me expect that I will see more typical website usability stuff in the following chapters. Chapter four is about brainstorming, which is an important methods and it is there nice to find it in the book. The fifth chapter is in my opinion the best chapter of the book. It is contributed by Bill Buxton and it’s an excerpt from his book on “Sketching the User Experience”. This part definitely has to belong into a modern user experience book – unfortunately I already know the book and therefore this chapter could not knock my socks off, too. Then follows a chapter on personas and finally the reader will learn more about prototyping. The prototyping chapter also is pretty short compared to the importance of prototyping and the different dimensions of prototyping (for example refer to http://hci.arc.nasa.gov/pages/2007/08/breaking_the_fi.html for a very good publication on the dimensions of prototyping).

Chapter eight is about designing for the web. This is a very poor chapter, because it focuses on designing websites, although this focus cannot be expected with regards to the title of the book. Moreover, in times of rich internet applications and modern UI mark-up languages for rich clients as well, having a focus on classic web design is a very bad “user experience” for the reader.

Chapter nine to twelve are about usability testing methods. Together with the overview on analysis and modeling, these chapters make the overview on usability methods “complete”.

Summary

I bought the book to have some kind of repetition of basic usability and user experience methods. For this purpose, this book was a satisfying match. For finding out about new or updated methods, this book was disappointing and the content poor. I could really not find something new in there. Some content seemed very outdated for me, which might even be misleading for many people who are new to usability and user experience - apart from the fact the title definitely IS misleading. I also expected to find some more content about user experience design. As mentioned above, I also got caught in the trap of the misleading book title. The only chapter that can be assigned to user experience design is the one by Bill Buxton.

Interactive User Interface Specifications

2010-04-24T17:55:00.023+02:00

In UI design there is recurrent jumping between the concrete and the abstract, as well as between the details and the whole. Switching between artefacts of a different grade of abstraction is among the most import tasks of designers. The process of UI specification therefore has loose boundaries between abstract, detailed and final design stages.

The right format of UI specification must be determined with regards to the formality of its notation. Informal, text-based notations are a good starting point for many projects, but are an insufficient means of communication and UI design during later stages due to ambiguity and a lack of precision, for example. Formal notations are very precise, but most stakeholders are unable to employ them correctly due to their strict and often complex terminology. Ultimately, semi-formal diagrammatic notations are a good compromise and provide an easy-to-use access to UI modelling, while still maintaining enough formalism to guide UI specification.

Through the identification of interdisciplinary interfaces and semi-formal modelling and UI prototyping, a new means for UI specification can be inferred. The concept of interactive UI specifications incorporates the richness and expressivity of UI style guides and incorporates aspects of design rationale with agile, semi-formal diagrammatic models plus their visual externalizations presented through UI prototypes. On the whole, the unification of important artefacts within a new form of UI specification, being interactive in terms of presenting its contents, contributes very positively to the demands of UI specification.

In order to define the ingredients of a sound interactive UI specification in detail, different kinds of semi-formal models must be determined. Moreover, adequate kinds of UI prototypes must be chosen from the variety of prototypologies. The identification of both the right set of models and the right set of UI prototyping methods leads directly to the development of a common interdisciplinary denominator for UI-related modelling and design. To a great extent this constitutes interactive UI specifications and fills a ‘white spot’ in IxD literature.

Interactive UI specifications extend the value of UI prototypes in terms of increased expressivity and transparency of design rationale. Because switching between the concrete and the detail is what drives design, the prototypes function as an extension of the mind and visualize the requirements in a way that is more tangible than text. The prototypes are therefore driving the specification process. For this purpose, they are permanently dependent on the created models, which incorporate the nneeds and requirements that have to be translated into the UI design.

Interactive UI specifications are based on the concept of detailed UI prototypes, which can function as UI specifications, but they include additional information that is ‘below’ the design layer. Through a visual drill-down, for example, subsidiary artefacts such as dialogue notations or story-like descriptions can be accessed.

Interactive UI Prototypes	Prototyping-Driven Interactive UI Specifications
Vehicle for requirements analysis	Vehicle for requirements specification
Exclusively models the UI layer; may be inconsistent with specification and graphical notations	Allows drill down from UI to models; relates UI to requirements and vice versa
Either low fidelity or high fidelity	Abstract first, specification design later
Supplements text-based specification	Widely replaces text-based specification
(Mostly) driven by specification	Driven by UI prototypes (prototyping-driven UI spec.)
Design rationale saved in other documents	Incorporates design knowledge and rationale

A tool that fully supports the idea behind interactive UI specifications is INSPECTOR.

Read more about UI specification here.

(Un-)Agility of Agile Usability Practices

2010-04-22T21:38:00.011+02:00

Jurgen Appelo conducted a survey on agile practices, which can be accessed at http://www.noop.nl/2009/04/the-big-agile-practices-survey.html. The detailed results are listed at http://www.infomixer.com/big-agile-practices-survey/.

Some visualizations of the survey results can be found at http://www.surveybob.com/surveybob/s/366bc1b5-af81-47ac-a41b-c423e1bea8a6.html. The charts highlight that some requirements methods such as use cases, usage scenarios and personas - all three would be especially important for adressing usability requirements - are not really recognized as agile practices or are not rated as important activities in the process.
The results are very interesting and as well surprising, because they thwart the method-set of many agile experts. For example, developing usage scenarios is a technique still promoted by Scott Ambler. I also recommend them as a very helpful method for putting user stories and use cases into an expressive context. Their form can be easily understood by all stakeholders. Personas are also part of agile usage-centered methods such as Software for Use by Constantine & Lockwood.

I have, however, not found any hint on the nature of projects in which survey participants are involved in. It is therefore difficult to say whether the negative answers for those methods are alarming from the perspective of agile usability engineering.

Apart from that, additional survey results which focus on agile design, show that some user-centered methods are also recognized as important means of modelling in agile projects. The charts at http://www.surveybob.com/surveybob/s/f565f3b7-685d-4436-a2ee-bffa2f570099.html outline that user interface prototyping is recognized as useful method, although there was no clear agreement on the method's agility.

The results show that it might be easier to integrate even less agile methods, such as prototyping, into agile development processes if those methods help to increase the quality of the final product. The impact of iterative UI prototyping on the product is usually more obvious for the team than the one of personas or scenarios. The latter rather have an impact on the creation of a product vision and they inwardly support the requirements analysis. UI prototypes are certainly more tangible, they directly support and guide developers and they are in many ways a marketing tool.

A fully integrated agile user-centered development therefore still seems to be a difficult marriage of two different worlds. Usability experts do still have their problems in convincing their agile partners of the benefits of personas or scenarios. However, more and more spouses will recognize that in many projects a divorce is even more expensive than following some outmoded, close-minded concepts, and that combined approacches are a very promising road to success.

Customer Experience defined

2010-04-22T21:15:00.004+02:00

I found a very good definition for Customer Experience in Richard Tait's blog "Winning Customer Experiences". The definiton was posted by Colin Shawn and I like to share it with you:
"A Customer Experience is an interaction between an organisation and a Customer. It is a blend of an organisations physical performance, the senses stimulated and emotions evoked, each intuitively measured against Customer Expectations across all moments of contact."
The definition can also be found on the website of Colin Shwan's company Beyond Philosophy, online at http://www.beyondphilosophy.com/customer-experience/what-is-customer-experience.php

State Models and Interaction Design

2010-04-21T20:52:00.003+02:00

In a recent interaction design project, I again realized the added value of state diagrams. I use state diagrams for modelling the modes in which a UI can be in. State diagrams especially help me a lot, if I design hardware user interfaces.

As soon as the interaction with the system changes dependant on the mode of the UI, the overall design becomes increasingly complex and textual descriptions are no longer sufficient to gain an overview on the overall interaction design.

Then, state diagrams help to get an overview on all possible states of the UI. Modelling the diagram quickly highlights white spots in the design concept, for example by missing transitions. The diagram also forces you to really consider what exactly a state of the system is and how different states are traversed based on the interaction of the user.

Modelling state diagrams typically motivates me to develop a domain model, too. Domain modelling is a very well-known technique in requirements engineering, which is why the time spent for developing the model also is a good investment. If it supports my understanding of events, triggers, guards or transitions, I add some pseudo code to the domain model. For example, considering the operations happening onEntry or onExit of a state do significantly help me in developing a consistent understanding of a system and the UI.

State diagrams are also a very good model to link usability engineering to requirements engineering and software development. Therefore, it is very helpful if you are able to draw UML state diagrams, for example with a tool such as Sparx Enterprise Architect.

However, state diagrams are just an add-on to other important usability models. State diagrams should always be accompanied by scenarios or use cases. If you develop all three kinds of artefacts, you are able to cross-check the flow of events of scenarios and use cases with the state diagrams. This helps you in making the models consistent and complete. Moreover, the existence of all three kinds of artefacts allows for an easier access of stakeholders to the modelled information. Even if they are no UML experts, they will be able to understand the state diagram much easier if there the diagram is escorted by less formal artefacts.

Become Usability Engineer @ Zuehlke Engineering AG

2010-04-21T20:14:00.002+02:00

My employer, Zuehlke Engineering AG in Switzerland, is still searching for a Usability Engineer to join our Business Unit.
The job description is available here:
http://www.zuehlke.com/de/jobs/stellenangebote/detailansicht/job/150/jobbpid/142/
Please get in touch with me if you are interested!

The User Experience, Customer Experience and Innovation Triangle

2010-04-11T11:53:00.004+02:00

...or how Usability Experts and User Experience Designers can innovate great interactions between companies and their customers.

With user experience, usability experts refer to the experience of users with products and services. Customer experience includes not only experiences with products but also with the company or with a brand (brand experience). Both “dimensions of experience” are closely related in many innovative projects, whereas innovative thinking is the third dimension in which I have to travel a lot as a usability expert. In this article I want to roughly outline all three dimensions and disclose how I put it all together in my projects.

Usability and User Experience

Following ISO 9241-210, user experience describes a person's perceptions and responses that result from the use or anticipated use of a product, system or service. User experience includes all the users’ emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviors and accomplishments. User experience is a consequence of the presentation, functionality, system performance, interactive behavior, and assistive capabilities of the interactive system. It is also a consequence of the user’s prior experiences, attitudes, skills and personality.

With usability engineering and user experience design we aim to make products better in many ways. Ultimately, we support our customers to develop better products with less effort (for example, due to reduced trial-and-error design and less late changes) and we help them to make more profit from user-oriented products, which please end-users with outstanding interactive behavior and ease of use. Popular methods that support us in reaching these goals are contextual inquiry, sketching and prototyping, as well as user and task modeling.

Customer Experience

Customer experience refers to experiences of a customer with a supplier of goods or services, over the duration of their relationship with the supplying company. One of the important laws of customer experience is that every interaction creates a personal reaction (Temkin, 2008). Therefore, customer feedback needs to be the key metric for the design of great customer experiences. Internal measurements do not tell us something about how people understand a product, service or the company behind. That’s why companies need to listen to their customers, which is called a voice of the customer program in customer experience management. As usability experts, we would call such programs user studies. Such programs allow designing experiences that match the needs of customers in certain segments. An important tool to identify individuals in such customer segments are Personas. Sounds familiar, doesn`t it? In the end, customers are expected to pay more for an experience that is not only functionally but emotionally rewarding. This is what customer experience management calls “premium pricing”. Companies that are successful in addressing emotions of their customers and building products and services around them can increase their profits. Likewise, usability professionals would argue that products, which are efficient to use, effective to use, satisfying and aesthetically pleasing will cost less (e.g. also with regards to total costs of ownership) and increase revenue because buyers will for example reward attractiveness, simpleness or ubiquity. After all, both user experience and customer experience professionals want to design “wow-moments” (moments of truth).

Innovation Processes

Both user experience and customer experience design usually require a certain amount of innovative thinking, including the associated methods and techniques that propel creativity. Innovation processes should involve players from multiple disciplines. When we innovate, we move from theoretical and practical realms in order to translate what we have learned in the world of practice into abstract models. (Beckman & Barry, 2007) describe a 4-step innovation process that travels through phases of experiencing, reflecting, thinking and acting in an iterative fashion. These four steps are very related to usability engineering and user experience design lifecycles, because both innovation and usability engineering processes are grounded in a deep understanding of context of use, i.e. understanding user needs and the customer. In both fields, observations and participatory design are very powerful methods in involving those who will use the outcome of the process and to make the innovation team care about needs and desires of customers, respectively end-users. Methods such as contextual inquiry are at the core of doing good observational research. It helps us to understand user needs and usability issues and moreover, it helps us to understand the meanings behind behavior, i.e. to understand feelings and user intentions. Innovation processes do also know methods such as interviews, diary studies or intercepts (hanging out with users for a short time). When it comes to concept generation, innovation processes apply intuitive techniques such as brainstorming or sketching. With prototypes, innovators collect feedback from users and then create new solutions, which might be a mix of previous solutions tested with users.

Designing Great Interactions

This is just a very small outline of three different processes, each of it very complex on its own. Nevertheless, one should be able to recognize that usability experts are basically able to bridge the concerns of usability design, customer experience and innovation in many demanding projects. One of the most significant reasons for this is that usability people know many of the methods, which are applied in all three worlds. They should be able to feel very comfortable in the iterative processes of experience design and innovative thinking. In all three worlds, the customer or user is in the center of all activities.
This is why I argue that user-oriented thinkers should be involved in all projects that impact on the interaction between customers and products, especially when it is all about new and innovative commercial products, and when the supplying company has to preserve a good reputation and brand image.

References:

Sara L. Beckman, Michael Barry (2007): Innovation as a Learning Process: Embedding Design Thinking. In: California Management Review, Fall 2007, Vol. 50, No. 1
ISO 9241-210. Ergonomics of human-system interaction — Part 210: Human-centered design for interactive systems.
Jeneanne Rae (2006): “The Importance Of Great Customer Experiences...And The Best Ways To Deliver Them.” Online at http://www.businessweek.com/magazine/content/06_48/b4011429.htm, last accessed April, 11th 2010
Bruce Temkin (2008): “The 6 Laws Of Customer Experience: The Fundamental Truths That Define How Organizations Treat Customers.” Online at http://experiencematters.wordpress.com/2008/07/22/free-book-the-6-laws-of-customer-experience/, last accessed April, 11th 2010

The right mindset of UX experts in Agile Teams

2010-04-08T17:07:00.001+02:00

A colleague of mine brought my attentention to the following webpage, which summarized a chapter of Mike Cohens book "Sucseeding with Agile":

http://www.infoq.com/articles/cohn-chapter8.

If you read through the excerpt, you will find a very important principle about the integration of UX people into Agile Development Teams.

Under the umbrella of User Experience - Usability Engineering and Interaction Design in 2010

2009-12-28T10:20:00.003+01:00

The last years of usability engineering practice where shaped by a war of terms, among them interaction design, user experience design, information architecture and many more. This phenomenon could also be witnessed by reading through job descriptions in Europe and the U.S.

I also had my difficulties in finding my own place in this pool of notions. This is why I wrote about the topic earlier this year: http://www.usability-architect.com/2009/06/who-am-i-from-interface-designers-to.html

In the meantime, I have the impression that in 2010 and in the subsequent years, too, there will be a consolidation of terms. I believe that information architecture (IA) will disappear from the scene, because the web becomes increasingly interactive. IA was especially associated with an expertise in building content and navigation structures that rather had a static form. Today, technologies like Silverlight, AJAX and Flash turn the web into a highly interactive media. Because the design of interactive systems is headlined with the term interaction design (IxD), it will absporb IA as a discipline. Naturally, this comes with an increasing need for IAs to enhance their knowledge and design capabilities beyond static forms of content representation.

In addition, user experience (UX) will molt to be the umbrella term for the design of software systems people will like to use and buy. This will underline the relationship of software design and customer experience management. But first of all, UX relates to the goal companies want to reach. Hence, UX does only describe a few methods and tools that provide guidance in actually designing UX.

This is why both usability engineering and interaction design will be the more concrete terms and discplines below the umbrella of UX. Both fields are relevant for designing interactive software systems in the future and there will be an ongoing discussion about the interfaces between both populations, including the role of industrial and graphic design.

I believe this is a very positive outlook for 2010 and it will help to promote the ROI of usability and design activities. I think it is always difficult to convince a client of investing into your profession, if you are unable to explain your discipline in a few words.

The Usability Architect

UI Prototyping Series Part 3: Why Prototype?

UI Prototyping Series Part 2: Prototypology

UI Prototyping Series Part 1: User Interface Prototyping Disregarded

Agile Usability Engineering

The Spectrum of User Experience - UX Stress Fields

User Interface Prototyping - Low- and High-Fidelity Prototyping Today

Rapid Mobile Prototyping with the iPad & iMockups

Overview on Client Technologies for Usability Professionals

User Interface Engineering Talk at FHWN in Switzerland

Whitepaper on Client Technologies (in German)

UX and other disciplines

New UX book about to be published: UX Best Practices How to Achieve More Impact with User Experience

UX Storytellers published

Agile & Security

GUI Development with Eclipse RCP

Not a Recommended Reading: User Experience Re-mastered

Interactive User Interface Specifications

Recommended Reading: NNG Agile Usability Report

(Un-)Agility of Agile Usability Practices

Customer Experience defined

State Models and Interaction Design

Become Usability Engineer @ Zuehlke Engineering AG

The User Experience, Customer Experience and Innovation Triangle

The right mindset of UX experts in Agile Teams

Under the umbrella of User Experience - Usability Engineering and Interaction Design in 2010